chore: merge v5.0-dev into v5.1-dev

[PastaPastaPasta]

Basic explanation

What this does: Brings v5.1-dev up to date with v5.0-dev by merging the 11 PRs that landed on v5.0-dev since the last forward merge (218cb89).

Value: Among those 11 PRs, #5257 fixes the Swift SDK CI job on v5.1-dev. Xcode 27 and the iOS 27 simulator landed on the self-hosted Mac runner on 2026-10-02. Since then, run_tests.sh picks a simulator by name only (iPhone 16 Pro, which exists only on iOS 18.6). xcodebuild then looks for that name on the newest OS (iOS 27), finds no match, and fails with Unable to find a device matching the provided destination specifier. #5257 selects the simulator by UDID instead. Example failure: https://github.com/dashpay/platform/actions/runs/37319971317 (PR #5287).

Risks: Low to moderate. The merge applied without conflicts, but it carries PV14 consensus changes into v5.1-dev. PLATFORM_V15 uses exactly the same sub-version tables as PLATFORM_V14 (I compared every non-comment field assignment in v14.rs and v15.rs), so v15 picks up every change. The GroveDB structure snapshot combines v5.0-dev's shielded-pool trees with v5.1-dev's latest-protocol-version pinning (#5154). The rs-drive structure tests in CI are the check for that.

Issue being fixed or feature implemented

v5.1-dev was 11 PRs behind v5.0-dev, including the simulator-selection fix every Swift SDK job on v5.1-dev currently needs.

What was done?

Merged origin/v5.0-dev (8061667) into origin/v5.1-dev (231dcbb) with no conflicts. Incoming PRs:

• fix(platform)!: refuse a by-id refersTo to an indexOnly document type at registration (PV14) #5284 fix(platform)!: refuse a by-id refersTo to an indexOnly document type at registration (PV14)
• fix(platform-wallet): report an identity balance refusal on withdrawal as insufficient credits #5206 fix(platform-wallet): report an identity balance refusal on withdrawal as insufficient credits
• fix(ci): resolve Swift simulator test destinations by UDID #5257 fix(ci): resolve Swift simulator test destinations by UDID
• feat(platform)!: only members added before a document approve its settled deletion (PV14) #5260 feat(platform)!: only members added before a document approve its settled deletion (PV14)
• fix(dpp): read $entropy as base64, not base58, in the create-transition map parser #5072 fix(dpp): read $entropy as base64, not base58, in the create-transition map parser
• feat(platform)!: token shielded pools #4760 feat(platform)!: token shielded pools
• feat(platform)!: let a banned or suspended author retract with a declared replace (PV14) #5253 feat(platform)!: let a banned or suspended author retract with a declared replace (PV14)
• ci: run PR Hygiene's engine from master #5247 ci: run PR Hygiene's engine from master
• test(dashmate): assert the migrated config format version, not a literal #5241 test(dashmate): assert the migrated config format version, not a literal
• feat(platform)!: bound the summed values of a contested document type (PV14) #5240 feat(platform)!: bound the summed values of a contested document type (PV14)
• ci(release): build dashmate packages from the release's own npm tarballs #5235 ci(release): build dashmate packages from the release's own npm tarballs

Please merge with a merge commit (not squash) so the v5.0-dev history stays shared with v5.1-dev.

How Has This Been Tested?

• git merge applied with no conflicts.
• Compared the version-table assignments of PLATFORM_V14 and PLATFORM_V15 after the merge: they are identical.
• I did not run a full local build. CI on this PR is the check.

Breaking Changes

None of its own. It carries the already-reviewed PV14 breaking changes listed above (#5284, #5260, #4760, #5253, #5240) into v5.1-dev.

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have added "!" to the title and described breaking changes in the corresponding section if my code contains any
• I have made corresponding changes to the documentation if needed
• If I added or changed GroveDB structure, I described it in the area's structure.rs, regenerated grovedb-structure.json, and checked the structure viewer link posted on this pull request

For repository code-owners and collaborators only

• I have assigned this pull request to a milestone

🤖 Generated with Claude Code

PR Hygiene · faf2ad1

• Bots — coderabbitai not yet · thepastaclaw requested changes — dismiss the review or push a fix — /skip-bots proceeds without the ones not yet reported
• Self-review — post /self-reviewed
• Within your 5 open PRs — this one is beyond the limit; it waits until one merges
• Build running
• Approvals
  • github (.github/workflows/release.yml) — ktechmidas or shumkov
  • files with no dedicated owner (book/src/SUMMARY.md, book/src/addresses/platform-addresses.md, book/src/contract-keywords.md and 113 more) — QuantumExplorer or shumkov
  • dashmate (packages/dashmate/test/unit/config/configFile/tenderdashImageMigration.spec.js) — ktechmidas or shumkov
  • js-wasm-sdk (packages/js-evo-sdk/src/contracts/facade.ts, packages/wasm-sdk/src/state_transitions/contract.rs) — shumkov
  • dpp (packages/rs-dpp/schema/meta_schemas/document/v3/document-meta.json, packages/rs-dpp/src/balances/total_tokens_balance/mod.rs, packages/rs-dpp/src/data_contract/associated_token/token_configuration/accessors/mod.rs and 197 more) — QuantumExplorer or shumkov
  • rs-drive-abci (packages/rs-drive-abci/Cargo.toml, packages/rs-drive-abci/src/execution/check_tx/v0/mod.rs, packages/rs-drive-abci/src/execution/engine/run_block_proposal/v0/mod.rs and 128 more) — QuantumExplorer or shumkov
  • rs-drive (packages/rs-drive/grovedb-structure.json, packages/rs-drive/src/drive/contract/insert/insert_contract/v2/mod.rs, packages/rs-drive/src/drive/contract/moderation/team_action_tests.rs and 146 more) — QuantumExplorer or shumkov
  • rs-platform-wallet-ffi (packages/rs-platform-wallet-ffi/src/error.rs) — HashEngineering or ZocoLini or llbartekll or romchornyi
  • rs-platform-wallet (packages/rs-platform-wallet/src/error.rs, packages/rs-platform-wallet/src/wallet/identity/network/transfer_to_addresses.rs, packages/rs-platform-wallet/src/wallet/identity/network/withdrawal.rs and 3 more) — HashEngineering or ZocoLini or llbartekll or romchornyi
  • rust-sdk (packages/rs-sdk/src/platform/documents/transitions/create.rs, packages/rs-sdk/src/platform/documents/transitions/delete.rs, packages/rs-sdk/src/platform/documents/transitions/purchase.rs and 6 more) — lklimek or shumkov
  • swift-sdk (packages/swift-sdk/run_tests.sh, packages/swift-sdk/scripts/fixtures/simulators-ios-18-6-and-27.json, packages/swift-sdk/scripts/select_simulator.py and 2 more) — llbartekll or romchornyi

When every box is checked the PR Hygiene check passes and this can merge.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

• Configuration used: Repository: dashpay/platform/.coderabbit.yaml
• Review profile: CHILL
• Plan: Advanced
• Run ID: 55e26f46-a982-4c31-a6ea-00edaccbf2c3

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

🌳 GroveDB structure

This pull request changes the described GroveDB structure. Open it in the structure viewer: new nodes glow, removed ones stay as ghosts, and the tour walks through each change.

Added (10 nodes)

• tokens.shielded_pools

Changed (1 node)

• tokens

Compared 231dcbbc77 with faf2ad1325. Updated at 2026-10-05T17:37:10.729Z

[github-actions]

📖 Book Preview built successfully.

Download the preview from the workflow artifacts.
To view locally: download the artifact, unzip, and open index.html.

Updated at 2026-10-05T17:37:32.528Z

[github-actions]

Waiting for bot review — coderabbitai not yet · thepastaclaw not yet. Wait for the missing reviews, or a writer can post /skip-bots to proceed without them; blocking findings still need addressing.
Full checklist in the description.

[thepastaclaw]

⛔ Final review complete — 1 blocking finding(s) (commit faf2ad1) · triage: critical

[github-actions]

Waiting for bot review — coderabbitai not yet · thepastaclaw requested changes — dismiss the review or push a fix. Wait for the missing reviews, or a writer can post /skip-bots to proceed without them; blocking findings still need addressing.
Full checklist in the description.

[thepastaclaw]

Final validation — Phase 1 + Phase 2

Confirmed one blocking double-spend vulnerability and three suggestions in the incoming token shielded-pool changes: two missing WASM API capabilities and a calibrated fee parameter outside the versioned schedule. Verification was static; no builds or tests were run locally. At the supplied CI snapshot, completed build and test checks were passing, while Rust workspace tests, the main Test Suite, browser shard 1, and PR Hygiene remained pending.

🔴 1 blocking | 🟡 3 suggestion(s)

4 finding(s) not shown inline (GitHub refused the PR diff as too large)

🔴 Blocking: Reject nullifiers reused across pool operations in the same batch
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/action_validation/token/token_shielded_pool_common/mod.rs:143-149

The seen set is local to each bundle, and the subsequent storage reads only check pre-batch state. Batch state validation validates every sub-transition before their combined operations are applied. Neither basic structure validation nor the additional CheckTx nullifier probe rejects reuse across sub-transitions. Consequently, an identity with sufficient credit fees can submit two independently valid TokenShieldedTransfer bundles with distinct valid contract nonces that spend the same note against the same recorded anchor and produce different replacement notes.

Storage application does not reject this batch under the shipped configuration. token_balance_writes excludes TokenShieldedTransfer, and batching_consistency_verification defaults to false. The repeated nullifier inserts collapse to one keyed operation, while the pinned GroveDB commitment-tree preprocessing appends both bundles' outputs. The ordinary item writes in this transfer batch do not activate GroveDB's separate backward-reference conflict checks. Neither the pool total nor the token supply changes, so balance conservation does not detect the duplicated spendable value. The replacements can subsequently be unshielded in separate transitions, consuming tokens backing other holders' notes.

Track nullifiers across accepted batch pool operations using a set keyed by (token_id, nullifier), including shielded document payments, and reject a conflicting sub-transition before lowering its actions. Add a regression test with two separately valid transfer bundles spending the same note within one batch under the shipped consistency-check configuration.

_{source: gpt-6.1-sol (phase2-reviewer: security-auditor)}

🟡 Suggestion: Marshal the pool threshold's change-control rules into V1
packages/wasm-dpp2/src/tokens/configuration/token_configuration.rs:201-209

The constructor accepts minimumPoolNotesForOutgoing but provides no option or setter for minimumPoolNotesForOutgoingChangeRules. Enabling the pool upgrades through TokenConfigurationV1::from_v0, whose dedicated threshold rules authorize NoOne for both changes and administration. An extra JavaScript property is ignored by the options deserializer, and tokens_configuration_from_js_value copies only the Rust inner configuration into the contract, so attaching that property to the wrapper does not preserve it either.

Tokens created through this constructor therefore have an immutable threshold, despite the new API documentation describing subsequent issuer updates. Native authorization checks use these dedicated rules rather than the token's other change rules. Expose an optional ChangeControlRules option and marshal it into the V1 configuration, preserving the restrictive default when omitted. Add a regression test that checks the rules retained in the constructed data contract.

_{source: gpt-6.1-sol (phase2-reviewer: ffi-engineer)}

🟡 Suggestion: Expose JavaScript factories for the three new threshold change items
packages/wasm-dpp2/src/tokens/configuration_change_item/token_configuration_change_item.rs:136-144

The new match arms expose the threshold variants through getters, but JavaScript cannot construct them through the typed API. The configuration_change_item/items modules provide factories for existing variants such as MaxSupplyItem, but none for MinimumPoolNotesForOutgoing, its control group, or its admin group. TokenConfigurationChangeItem also has no constructor or object/JSON parser.

TokenConfigUpdateTransition::constructor extracts updateTokenConfigurationItem through try_from_options, which requires an actual WASM wrapper rather than a plain object. Thus, even a token created elsewhere with rules authorizing threshold updates cannot receive these updates through the JavaScript factories. Add the three exported factories using the existing value, control-group, and admin-group patterns, and test that each resulting item survives construction of a TokenConfigUpdateTransition.

_{source: gpt-6.1-sol (phase2-reviewer: ffi-engineer)}

🟡 Suggestion: Store the calibrated token-unshield allowance in the fee schedule
packages/rs-dpp/src/shielded/mod.rs:214

This 230-byte figure is calibrated pricing with discretionary headroom, not an encoded-field width: the comment derives it from measured storage credits and rounds it upward. compute_token_unshield_with_shielded_fee_fee uses the shared constant to determine the exact credit amount required by minimum-fee validation, but the allowance itself is independent of PlatformVersion::fee_version.

The current activation is replay-safe, but changing this calibration later would also change the accepted fee for historical PV14/PV15 transitions unless a separate behavior generation were introduced. The repository's fee conventions place pricing parameters in named schedules. Add the allowance to the owning fee parameters, configure it in the unreleased FEE_VERSION3 schedule used by PV14/PV15, and read it through platform_version in the shared helper used by builders and validation. Preserve the frozen historical fee-serialization structures.

_{source: gpt-6.1-sol (phase2-reviewer: general, architecture-layering, ffi-engineer, platform-versioning, rust-quality, security-auditor)}

Review provenance

Source: reviewer 1: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 2: muse-spark-1.3-contributor (agent: phase1-reviewer, role: general); reviewer 3: gpt-6.1-sol (agent: phase2-reviewer, role: architecture-layering); reviewer 4: muse-spark-1.3-contributor (agent: phase1-reviewer, role: rust-quality); reviewer 5: gpt-6.1-sol (agent: phase2-reviewer, role: ffi-engineer); reviewer 6: gpt-6.1-sol (agent: phase2-reviewer, role: platform-versioning); reviewer 7: gpt-6.1-sol (agent: phase2-reviewer, role: rust-quality); reviewer 8: gpt-6.1-sol (agent: phase2-reviewer, role: security-auditor); final verifier: gpt-6.1-sol (agent: sol-verifier, role: final-verifier)

• Triage: critical by gpt-6.1-sol (effort low) — The large, intricate diff adds token shielded-pool funds movement and consensus validation, including cryptographic signing changes in packages/rs-dpp/src/shielded/sighash.rs and new token shield/unshield transition implementations.
• Phase 1 reviewers: muse-spark-1.3-contributor — general (completed, effort xhigh); agent phase1-reviewer, muse-spark-1.3-contributor — rust-quality (completed, effort xhigh); agent phase1-reviewer
• Phase 1 model: muse-spark-1.3-contributor — not quota-gated; passed over gemini-3.8-flash-high (antigravity below 15% reserve: weekly 15% left, 5h 100% left), glm-5.3-flash (not used above high effort; tier asks max)
• Single stage: Phase 1 and Phase 2 reviewed this head side by side, with no blocker gate between them (triage tier)
• Fresh verifier: gpt-6.1-sol — final-verifier; agent sol-verifier
• Phase 2 reviewers: gpt-6.1-sol — general (completed, effort xhigh); agent phase2-reviewer, gpt-6.1-sol — architecture-layering (completed, effort xhigh); agent phase2-reviewer, gpt-6.1-sol — ffi-engineer (completed, effort xhigh); agent phase2-reviewer, gpt-6.1-sol — platform-versioning (completed, effort xhigh); agent phase2-reviewer, gpt-6.1-sol — rust-quality (completed, effort xhigh); agent phase2-reviewer, gpt-6.1-sol — security-auditor (completed, effort xhigh); agent phase2-reviewer

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/action_validation/token/token_shielded_pool_common/mod.rs`:
- [BLOCKING] packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/action_validation/token/token_shielded_pool_common/mod.rs:143-149: Reject nullifiers reused across pool operations in the same batch
  The `seen` set is local to each bundle, and the subsequent storage reads only check pre-batch state. Batch state validation validates every sub-transition before their combined operations are applied. Neither basic structure validation nor the additional CheckTx nullifier probe rejects reuse across sub-transitions. Consequently, an identity with sufficient credit fees can submit two independently valid `TokenShieldedTransfer` bundles with distinct valid contract nonces that spend the same note against the same recorded anchor and produce different replacement notes.

  Storage application does not reject this batch under the shipped configuration. `token_balance_writes` excludes `TokenShieldedTransfer`, and `batching_consistency_verification` defaults to false. The repeated nullifier inserts collapse to one keyed operation, while the pinned GroveDB commitment-tree preprocessing appends both bundles' outputs. The ordinary item writes in this transfer batch do not activate GroveDB's separate backward-reference conflict checks. Neither the pool total nor the token supply changes, so balance conservation does not detect the duplicated spendable value. The replacements can subsequently be unshielded in separate transitions, consuming tokens backing other holders' notes.

  Track nullifiers across accepted batch pool operations using a set keyed by `(token_id, nullifier)`, including shielded document payments, and reject a conflicting sub-transition before lowering its actions. Add a regression test with two separately valid transfer bundles spending the same note within one batch under the shipped consistency-check configuration.

In `packages/wasm-dpp2/src/tokens/configuration/token_configuration.rs`:
- [SUGGESTION] packages/wasm-dpp2/src/tokens/configuration/token_configuration.rs:201-209: Marshal the pool threshold's change-control rules into V1
  The constructor accepts `minimumPoolNotesForOutgoing` but provides no option or setter for `minimumPoolNotesForOutgoingChangeRules`. Enabling the pool upgrades through `TokenConfigurationV1::from_v0`, whose dedicated threshold rules authorize `NoOne` for both changes and administration. An extra JavaScript property is ignored by the options deserializer, and `tokens_configuration_from_js_value` copies only the Rust inner configuration into the contract, so attaching that property to the wrapper does not preserve it either.

  Tokens created through this constructor therefore have an immutable threshold, despite the new API documentation describing subsequent issuer updates. Native authorization checks use these dedicated rules rather than the token's other change rules. Expose an optional `ChangeControlRules` option and marshal it into the V1 configuration, preserving the restrictive default when omitted. Add a regression test that checks the rules retained in the constructed data contract.

In `packages/wasm-dpp2/src/tokens/configuration_change_item/token_configuration_change_item.rs`:
- [SUGGESTION] packages/wasm-dpp2/src/tokens/configuration_change_item/token_configuration_change_item.rs:136-144: Expose JavaScript factories for the three new threshold change items
  The new match arms expose the threshold variants through getters, but JavaScript cannot construct them through the typed API. The `configuration_change_item/items` modules provide factories for existing variants such as `MaxSupplyItem`, but none for `MinimumPoolNotesForOutgoing`, its control group, or its admin group. `TokenConfigurationChangeItem` also has no constructor or object/JSON parser.

  `TokenConfigUpdateTransition::constructor` extracts `updateTokenConfigurationItem` through `try_from_options`, which requires an actual WASM wrapper rather than a plain object. Thus, even a token created elsewhere with rules authorizing threshold updates cannot receive these updates through the JavaScript factories. Add the three exported factories using the existing value, control-group, and admin-group patterns, and test that each resulting item survives construction of a `TokenConfigUpdateTransition`.

In `packages/rs-dpp/src/shielded/mod.rs`:
- [SUGGESTION] packages/rs-dpp/src/shielded/mod.rs:214: Store the calibrated token-unshield allowance in the fee schedule
  This 230-byte figure is calibrated pricing with discretionary headroom, not an encoded-field width: the comment derives it from measured storage credits and rounds it upward. `compute_token_unshield_with_shielded_fee_fee` uses the shared constant to determine the exact credit amount required by minimum-fee validation, but the allowance itself is independent of `PlatformVersion::fee_version`.

  The current activation is replay-safe, but changing this calibration later would also change the accepted fee for historical PV14/PV15 transitions unless a separate behavior generation were introduced. The repository's fee conventions place pricing parameters in named schedules. Add the allowance to the owning fee parameters, configure it in the unreleased `FEE_VERSION3` schedule used by PV14/PV15, and read it through `platform_version` in the shared helper used by builders and validation. Preserve the frozen historical fee-serialization structures.

[PastaPastaPasta]

@thepastaclaw thanks. Replies to the final review on faf2ad1:

🔴 Reject nullifiers reused across pool operations in the same batch: not reachable. The scenario needs two pool operations (two TokenShieldedTransfer bundles) in one batch. A batch can't carry two transitions of any kind on any shipped protocol version:

• BatchTransition::validate_base_structure_v0 (packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/validation/validate_basic_structure/v0/mod.rs:69-86) rejects transitions_len() > system_limits.max_transitions_in_documents_batch with MaxDocumentsTransitionsExceededError.
• transitions_len() counts every BatchedTransition, documents and tokens alike (accessors/mod.rs:60, v1/v0_methods.rs:68).
• max_transitions_in_documents_batch is 1 in SYSTEM_LIMITS_V1 through V4, and V4 is what PV14/PV15 use.

Two separate state transitions in one block are applied in sequence on the block transaction, so the second one's has_token_pool_nullifier read already sees the first one's nullifier. The per-bundle seen set plus that stored-state check covers every shape a batch can take today.

The cross-sibling gap is real if the cap is ever raised. It belongs with the other "needs cross-sibling tracking before lifting the cap" items already documented on max_transitions_in_documents_batch (system_limits/v1.rs:15-39). This PR isn't the place for it either way: it is a forward merge of v5.0-dev into v5.1-dev, and this code came from #4760, which was already reviewed and merged on v5.0-dev.

🟡 The three suggestions (WASM threshold change-control rules, WASM factories for the threshold change items, the token-unshield allowance in the fee schedule) are also on #4760's code. They're out of scope for a merge-only PR. Any follow-up should land on v5.0-dev and come forward with the next merge.

The only change this PR makes on top of the merge is faf2ad1, which regenerates grovedb-structure.json (the token shielded-pool fixture is recorded at protocol version 15 on this branch instead of 14).

---

🤖 Posted autonomously by Claude on behalf of pasta.