[shumkov]

Basic explanation

What this does: Brings v5.1-dev up to date with v5.0-dev at 79693ec1f3: the 5.0.0-rc.5, rc.6 and rc.7 releases, 20 PRs in all. The last forward merge was #5481, whose merge base f282f29999 is this merge's base too.

Value: v5.1-dev gets the rc.5–rc.7 fixes:

• ChainLocks go to Core with the block hash in display order (fix(drive-abci): send ChainLocks to Core with the block hash in display order #5490).
• A transition whose version is not active is a coded consensus refusal, not a decode failure (fix(drive-abci): a transition whose version is not active is not a decode failure #4993).
• The SDK verifies no-limit vote, proposer, distribution and group queries against the page Drive proves (fix(sdk): verify no-limit vote queries against the page Drive proves #5483, fix(sdk): verify no-limit proposer, distribution and group queries against the page Drive proves #5485) and reads contested DPNS names as bare labels (fix(sdk): read contested DPNS names as the bare labels Drive returns #5482).
• The wallet keeps the owner balance a document write's proof carries (feat(sdk): persist the owner balance a document write's proof carries #5409).
• The wallet builds version-3 ProUpServTx for Core v24 masternodes (fix(platform-wallet): build version-3 ProUpServTx for Core v24 masternodes #5408, fix(platform-wallet): build version-3 evonode ProUpServTx once the SPV coinbase shows V24 #5497).
• dpp compiles without default features (fix(dpp): compile without default features #5498).
• rs-dapi keeps the Core RPC permit until the call returns (fix(rs-dapi): keep the Core RPC permit until the call returns #5507).
• GroveDB 6.1.1 and the RUSTSEC crate bumps (chore: bump GroveDB to 6.1.1, h2, rustls, quinn-proto, crossbeam-epoch and rust_decimal for RUSTSEC advisories #5499), and the npm audit fixes (chore(deps): fix critical and high npm audit advisories #5500).

Risks: Low to moderate.

• rust-dashcore stays on v5.1-dev's dev pin (aca02026). v5.0-dev moved to v0.45.0 (d631aaca) in chore(platform)!: update rust-dashcore to v0.45.0 #5517; that pin is not taken.
• fix(platform-wallet): build version-3 evonode ProUpServTx once the SPV coinbase shows V24 #5497's V24 check needs latest_coinbase(), which only the integration/v5.0-core-v24 branch has. On v5.1-dev the evonode payload version is decided from the masternode list alone, as fix(platform-wallet): build version-3 ProUpServTx for Core v24 masternodes #5408 did, until rust-dashcore#1202 lands on dev. See "Temporary divergence from v5.0-dev" below.
• feat(sdk): persist the owner balance a document write's proof carries #5409's balance persistence for DashPay profile writes did not apply to v5.1-dev's profile path (feat(sdk): move DashPay profile create, update and fetch into rs-sdk #5470). A separate commit in this PR carries it over.

Issue being fixed or feature implemented

v5.1-dev was 20 PRs behind v5.0-dev.

What was done?

Merged origin/v5.0-dev (79693ec1f3) into origin/v5.1-dev (3a731bfcf6) as a merge commit (1c0dc74ef5), followed by two commits.

Incoming PRs:

• chore(release): update changelog and bump version to 5.0.0-rc.7 #5522 chore(release): update changelog and bump version to 5.0.0-rc.7
• chore(platform)!: update rust-dashcore to v0.45.0 #5517 chore(platform)!: update rust-dashcore to v0.45.0
• chore(release): update changelog and bump version to 5.0.0-rc.6 #5509 chore(release): update changelog and bump version to 5.0.0-rc.6
• fix(rs-dapi): keep the Core RPC permit until the call returns #5507 fix(rs-dapi): keep the Core RPC permit until the call returns
• fix(platform-wallet): build version-3 evonode ProUpServTx once the SPV coinbase shows V24 #5497 fix(platform-wallet): build version-3 evonode ProUpServTx once the SPV coinbase shows V24
• test(drive-abci): expect the not-active consensus error in the remaining pre-activation tests #5508 test(drive-abci): expect the not-active consensus error in the remaining pre-activation tests
• chore: bump GroveDB to 6.1.1, h2, rustls, quinn-proto, crossbeam-epoch and rust_decimal for RUSTSEC advisories #5499 chore: bump GroveDB to 6.1.1, h2, rustls, quinn-proto, crossbeam-epoch and rust_decimal for RUSTSEC advisories
• fix(dpp): compile without default features #5498 fix(dpp): compile without default features
• test(drive-abci): expect the not-active consensus error in every pre-activation test #5502 test(drive-abci): expect the not-active consensus error for a batch with a version 2 base at protocol version 13
• chore(deps): fix critical and high npm audit advisories #5500 chore(deps): fix critical and high npm audit advisories
• feat(sdk): persist the owner balance a document write's proof carries #5409 feat(sdk): persist the owner balance a document write's proof carries
• ci(swift-sdk): refresh open schema freeze PRs after Swift SDK changes #5413 ci(swift-sdk): refresh open schema freeze PRs after Swift SDK changes
• fix(drive-abci): a transition whose version is not active is not a decode failure #4993 fix(drive-abci): a transition whose version is not active is not a decode failure
• chore(skills): show each reviewer their part in /prs #5242 chore(skills): show each reviewer their part in /prs
• chore(release): update changelog and bump version to 5.0.0-rc.5 #5492 chore(release): update changelog and bump version to 5.0.0-rc.5
• fix(drive-abci): send ChainLocks to Core with the block hash in display order #5490 fix(drive-abci): send ChainLocks to Core with the block hash in display order
• fix(sdk): verify no-limit vote queries against the page Drive proves #5483 fix(sdk): verify no-limit vote queries against the page Drive proves
• fix(sdk): read contested DPNS names as the bare labels Drive returns #5482 fix(sdk): read contested DPNS names as the bare labels Drive returns
• fix(sdk): verify no-limit proposer, distribution and group queries against the page Drive proves #5485 fix(sdk): verify no-limit proposer, distribution and group queries against the page Drive proves
• fix(platform-wallet): build version-3 ProUpServTx for Core v24 masternodes #5408 fix(platform-wallet): build version-3 ProUpServTx for Core v24 masternodes

Pins and Cargo.lock

• rust-dashcore: v5.1-dev keeps dev at aca02026. Nothing from integration/v5.0-core-v24 is carried. Every rust-dashcore PR that v0.45.0 backported (test(drive): verify proof signatures in strategy tests #1147, fix(dashmate): download certificate retry logic #1187, fix(dashmate): status command fails with errors #1059, fix(drive): core RPC retry all errors #1140, chore(release): update changelog and bump version to 0.24.0-dev.31 #1014, fix(dashmate): waitForQuorumConnections deadline of 300000 exceeded #1015, feat: platform signable on enums #1009, feat(dapi): update coinbase payload accroding to changes in Core v20 #1035, fix(dashmate): set permissions for dashcore log file #1037, feat(sdk): retry policy for newly created platform entities #1143) is an ancestor of aca02026. So is refactor: update dapi proto file to use either proofs or result #1148, the ChainLock hash order behind fix(drive-abci): send ChainLocks to Core with the block hash in display order #5490. unrecorded_spend_heights / note_chain_lock_height were already forwarded on v5.1-dev (see below).
• GroveDB: fc7028d8 (6.1.0) → 2128ea18 (6.1.1), as on v5.0-dev. 6.1.1 is two commits ahead of 6.1.0. The only source change is the grovedbg debugger's zip extraction, so no GroveVersion, storage or proof behaviour changes.
• Cargo.lock: v5.1-dev's lockfile, re-resolved for GroveDB 6.1.1. chore: bump GroveDB to 6.1.1, h2, rustls, quinn-proto, crossbeam-epoch and rust_decimal for RUSTSEC advisories #5499's crate bumps were then replayed with cargo update -p <crate> --precise <v5.0-dev's version>: h2 0.4.20, rustls 0.23.46 (with aws-lc-rs 1.18.2, aws-lc-sys 0.46.0, rustls-webpki 0.103.15), quinn-proto 0.11.19, crossbeam-epoch 0.9.21, rust_decimal 1.43.0, anyhow 1.0.104, event-listener 5.4.2, chacha20 0.10.2 and spin 0.9.9. The removals follow from these (rkyv 0.7, zip 6 / zip-extensions and their dependencies). Every non-rust-dashcore package now has the version v5.0-dev has, except crates v5.1-dev had moved itself. All builds and tests ran with --locked.
• Workspace and package versions: 5.0.0-rc.4 → 5.0.0-rc.7, following chore: merge v5.0-dev into v5.1-dev #5481 (rc.3 → rc.4).

Conflicts resolved by hand

• CHANGELOG.md: kept [Unreleased] on top, followed by the rc.7, rc.6 and rc.5 entries, as in chore: merge v5.0-dev into v5.1-dev #5481.
• Cargo.toml: GroveDB from v5.0-dev, rust-dashcore from v5.1-dev.
• rs-dpp/src/serialization/mod.rs: kept v5.1-dev's dashcore module gate (serde-conversion or bls-signatures) and took fix(dpp): compile without default features #5498's serde-conversion gate for the json module. json-conversion enables serde-conversion, so nothing that compiled before stops compiling.
• rs-sdk dpns_usernames/mod.rs, transition/put_document.rs: feat(sdk): persist the owner balance a document write's proof carries #5409's ResponseMetadata import next to v5.1-dev's dpp::secp256k1 rand imports (refactor!: migrate Platform cryptography to rust-dashcore dev (aca02026) #5514).
• rs-platform-wallet/src/masternode/update_service.rs (fix(platform-wallet): build version-3 ProUpServTx for Core v24 masternodes #5408, fix(platform-wallet): build version-3 evonode ProUpServTx once the SPV coinbase shows V24 #5497): v5.0-dev's file, ported to dpp::bls, since v5.1-dev no longer ships blsful (refactor: share rust-dashcore BLS backend through dpp::bls #5320, refactor!: migrate Platform cryptography to rust-dashcore dev (aca02026) #5514). It signs the same SpecialTransactionPayloadHash with the same basic-scheme DST and writes the same 96-byte compressed signature. The coinbase source is optional; see the next section.
• rs-platform-wallet/src/spv/runtime.rs: masternode_list_entries (fix(platform-wallet): build version-3 ProUpServTx for Core v24 masternodes #5408) reads through DashSpvClient::latest_masternode_list(), as v5.1-dev's masternode_list_summaries does, because the masternode list engine is crate-private on dev. SpvRuntime::latest_coinbase (fix(platform-wallet): build version-3 evonode ProUpServTx once the SPV coinbase shows V24 #5497) is not carried.
• rs-platform-wallet/src/wallet/platform_wallet_traits.rs: both branches forward unrecorded_spend_heights and note_chain_lock_height to the inner ManagedWalletInfo (v5.1-dev since chore(platform)!: update rust-dashcore to dev 280b3f2c #5493, v5.0-dev since chore(platform)!: update rust-dashcore to v0.45.0 #5517). The merge keeps one forward of each; note_chain_lock_height is forwarded, not left to the no-op default. I checked WalletInfoInterface at aca02026: every defaulted method that ManagedWalletInfo overrides is forwarded. The tests of both branches are kept: two from v5.1-dev (direct noted-height pruning, truncation) and two from v5.0-dev (pruning and block re-application through WalletManager).
• rs-platform-wallet/src/wallet/identity/network/profile.rs: v5.1-dev's side (profile create and update through Sdk::create_profile / Sdk::update_profile, feat(sdk): move DashPay profile create, update and fetch into rs-sdk #5470). feat(sdk): persist the owner balance a document write's proof carries #5409's part for this file follows in 084c7e5c25; see "Semantic conflicts resolved".

Temporary divergence from v5.0-dev: V24 detection for evonode ProUpServTx

On v5.0-dev, #5497 builds an evonode's ProUpServTx at version 3 once the list shows V24 (any version-3 entry) or the SPV client's latest masternode-list-diff coinbase is version 4 or later. With no coinbase yet, it refuses with a retryable error.

rust-dashcore dev at aca02026 has no latest_coinbase(); it arrives with rust-dashcore#1202 / #1200, both still open. On v5.1-dev the coinbase source of update_service_placeholder is therefore optional, and production passes none:

// prepare_masternode_update_service, update_service.rs
None::<std::future::Ready<_>>,

With no source, the list's view is final. That is #5408's rc.5 behaviour: a legacy evonode gets version 2 until some entry is version 3. The coinbase signal is not faked. The build also does not fail closed: that would refuse every legacy evonode update, including all of them before V24. The cost is #5497's original bug, on v5.1-dev only: right after V24 activates, until a version-3 provider transaction is mined, a legacy evonode's version-2 payload is refused by Core. It is not active on testnet or mainnet yet. All of #5497's coinbase logic and tests are kept (the tests pass Some(..)). A new test, should_keep_the_lists_view_of_v24_without_a_coinbase_source, pins the no-source path.

What to change when rust-dashcore#1202 is on the pinned dev:

1. Add back v5.0-dev's SpvRuntime::latest_coinbase() (spv/runtime.rs), reading DashSpvClient::latest_coinbase() through the client, as masternode_list_entries reads latest_masternode_list().
2. In prepare_masternode_update_service (masternode/update_service.rs), replace None::<std::future::Ready<_>> with Some(spv.latest_coinbase()).
3. Optionally, drop the Option around update_service_placeholder's latest_coinbase parameter, and with it the Some(..) in its tests.

Semantic conflicts resolved

• feat(sdk): persist the owner balance a document write's proof carries #5409 × feat(sdk): move DashPay profile create, update and fetch into rs-sdk #5470, DashPay profile writes (084c7e5c25). feat(sdk): persist the owner balance a document write's proof carries #5409 persists the owner balance a profile create or update proves, through SdkWriter::put_document. On v5.1-dev, feat(sdk): move DashPay profile create, update and fetch into rs-sdk #5470 moved those writes into rs-sdk's Sdk::create_profile / Sdk::update_profile, which return only the document. Taking either side alone would have dropped feat(sdk): persist the owner balance a document write's proof carries #5409 for profiles on v5.1-dev. The follow-up commit:

  • adds Sdk::create_profile_with_owner_balance_and_metadata and Sdk::update_profile_with_owner_balance_and_metadata. They are additive: create_profile / update_profile delegate to them and keep their signatures. They sign with the same document builders, then broadcast and verify through feat(sdk): persist the owner balance a document write's proof carries #5409's wait_for_document_and_owner_balance_with_metadata, with an execution proof required (profile is not indexOnly).
  • wires the wallet's create_profile_with_external_signer / update_profile_with_external_signer to them. record_own_profile_write persists the proven balance, then caches the profile, in the order feat(sdk): persist the owner balance a document write's proof carries #5409 used.
  • test should_keep_the_proven_owner_balance_of_a_profile_write: it fails with the persist call removed (left: 2818262560, right: 2743797100) and passes with it. The network half (sign, broadcast, proof) cannot be unit-tested without a proof-producing mock; it reuses feat(sdk): persist the owner balance a document write's proof carries #5409's tested document_and_owner_balance.
  • mentions the two calls in the book's put-operations chapter.

  With this, the proven balance is kept on every path feat(sdk): persist the owner balance a document write's proof carries #5409 covers: DPNS registration, create_document_with_signer, contactInfo publish, and profile create and update.

• b60452c9f9 folds in review: the update_service_placeholder docs now describe the no-source case separately and accurately, and put_profile_write no longer looks up the document type after the builder has reserved the nonce.

Protocol versions

• None of the 20 PRs touches rs-platform-version. PLATFORM_V15 differs from PLATFORM_V14 only in DRIVE_ABCI_METHOD_VERSIONS_V11 and DRIVE_ABCI_VALIDATION_VERSIONS_V11. Both are built from their V10 tables, so every incoming change selected through a V10 table reaches PV15.
• fix(drive-abci): a transition whose version is not active is not a decode failure #4993 changes decode_raw_state_transitions v0 (PV1–13). PV14 and PV15 select v1, which already had this handling and is the same on both branches.
• fix(drive-abci): send ChainLocks to Core with the block hash in display order #5490's code change is in rust-dashcore. In Platform it changes only a comment.
• test(drive-abci): expect the not-active consensus error in every pre-activation test #5502 / test(drive-abci): expect the not-active consensus error in the remaining pre-activation tests #5508 pin protocol version 13 explicitly, not latest().

Files changed on both branches and merged automatically (worth a look in review)

rs-drive-proof-verifier/src/verify.rs, rs-platform-wallet/src/masternode/list.rs, changeset/changeset.rs, wallet/identity/network/{contact_info,document,dpns,sdk_writer}.rs, rs-platform-wallet-storage/SCHEMA.md, swift-sdk/.../PlatformWalletPersistenceHandler.swift, yarn.lock, .pnp.cjs and the package.json version bumps. Each adds exactly v5.0-dev's lines.

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?

Run locally on macOS (arm64), on the merged tree:

• cargo check --workspace --all-targets --locked: passes.
• cargo clippy --workspace --all-targets --all-features --locked -- --no-deps -D warnings (CI's invocation): passes on 084c7e5c25, and again on the final commit b60452c9f9.
• cargo fmt --all -- --check: passes.
• CI's non-shielded phase, mirrored with cargo test because cargo-nextest is not installed here. That is CI's full package list with --all-features --locked --lib --bins --tests --no-fail-fast -- --skip shield and CI's RUST_MIN_STACK=4194304 CARGO_PROFILE_DEV_DEBUG=0 CARGO_PROFILE_DEV_CODEGEN_UNITS=256. It runs the full strategy_tests binary, not only the comprehensive simulation a PR run takes. Result: 20,033 passed, 0 failed, 61 ignored. Of these:
  • dpp: 5,387 passed, 0 failed (6 ignored).
  • drive-abci lib: 4,125 passed, 0 failed (14 ignored); strategy_tests 115 passed, 0 failed (4 ignored).
  • drive: 4,052 passed, 0 failed (6 ignored), including should_match_committed_grovedb_structure_json.
  • platform-wallet: 1,365 lib tests passed, 0 failed. These include all 32 update_service tests, the four platform_wallet_traits tests and the new profile-balance test.
  • platform-wallet-ffi: 423 passed; platform-wallet-storage: 435 passed; dash-sdk: 411 passed (including feat(sdk): persist the owner balance a document write's proof carries #5409's waitable tests); rs-sdk-ffi: 373 passed. All with 0 failed.
• platform-wallet-storage shield-named tests (-- shield --skip wallet::shielded::, which CI's phase keeps): 7 passed, 0 failed.
• Shielded phase (cargo test --tests -p dpp -p drive -p drive-abci -p dash-sdk --all-features --locked -- shield, same env): 962 passed, 0 failed (3 ignored).
• cargo test -p wasm-sdk --lib --locked: 189 passed, 0 failed.
• Doctests (cargo test --workspace --all-features --locked --doc -- --test-threads=4): 146 passed, 0 failed (64 ignored).
• After b60452c9f9: the non-shielded tests of dash-sdk, platform-wallet, platform-wallet-ffi and rs-sdk-ffi again, and cargo check -p wasm-sdk -p wasm-dpp2 -p wasm-drive-verify --target wasm32-unknown-unknown --locked. The four crates: 2,891 passed, 0 failed (29 ignored). The wasm32 check passes.
• yarn constraints and yarn install --immutable --immutable-cache: both pass, and the tree stays clean.
• CI's "Detect immutable structure changes" script, run locally against origin/v5.1-dev: no violations.
• Three independent reviews of the conflict resolutions (git show --cc), by separate agents, each with one lens. None found a must-fix issue.
  • Dropped changes: of the 275 files v5.0-dev changed, 242 are byte-identical to v5.0-dev. The other 33 contain every v5.0-dev line except the planned divergences above. No v5.1-dev change was reverted, and no v5.0-dev test is missing.
  • Consensus and versioning: see "Protocol versions".
  • The wallet, SPV and SDK ports: see the BLS port and delegation notes above.

Known limitations and notes

• The V24 divergence above, until rust-dashcore#1202 is on the pinned dev.
• rust_decimal 1.42.1 → 1.43.0 (chore: bump GroveDB to 6.1.1, h2, rustls, quinn-proto, crossbeam-epoch and rust_decimal for RUSTSEC advisories #5499) runs in consensus arithmetic at every protocol version: epoch detection in rs-drive-abci/src/platform_types/epoch_info/v0/mod.rs and storage-fee distribution in rs-dpp/src/fee/epoch/distribution.rs. 1.43.0 rewrites addition, multiplication, floor and the rescale. A source review found the results identical for the operations Platform uses, and the only precision change sits behind the maths feature, which nothing here enables. The distribution tests that pin exact values pass. chore: bump GroveDB to 6.1.1, h2, rustls, quinn-proto, crossbeam-epoch and rust_decimal for RUSTSEC advisories #5499's description says nothing in it touches consensus code. That is not quite accurate, though a divergence is unlikely. This already ships in 5.0.0-rc.6 and is not new to this merge, but a differential run of those functions under both versions would settle it.
• The doc comment on the decode_raw_state_transitions dispatcher (rs-drive-abci/.../decode_raw_state_transitions/mod.rs) still says only version 1 reports a not-active transition as a coded refusal. Since fix(drive-abci): a transition whose version is not active is not a decode failure #4993, v0 does too. This is inherited from v5.0-dev as is, so it is better fixed there.
• The changelog's rc.6 entry for fix(platform-wallet): build version-3 evonode ProUpServTx once the SPV coinbase shows V24 #5497 and rc.7 entry for chore(platform)!: update rust-dashcore to v0.45.0 #5517 describe v5.0-dev's tree. On v5.1-dev the first is not in effect yet and the second's pin is not taken.

Breaking Changes

The merge adds none of its own. #5517's breaking changes (rust-dashcore v0.45.0 API) do not apply, because the pin is not taken; v5.1-dev was already on dev with those APIs. The follow-up commit only adds rs-sdk APIs.

Checklist:

• I have performed a self-review of my own code
• My Rust, FFI, WASM, Swift or Kotlin changes follow the coding conventions
• 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 · b60452c

• Bots — coderabbitai not yet · thepastaclaw ✓ — /skip-bots proceeds without the ones not yet reported
• Self-review — post /self-reviewed
• Build green
• Approvals
  • files with no dedicated owner — you own it
  • github (.github/workflows/swift-sdk-freeze-pr-refresh.yml) — ktechmidas
  • dashmate — you own it
  • system-contracts — you own it
  • js-wasm-sdk — you own it
  • kotlin-sdk (packages/kotlin-sdk/sdk/src/main/kotlin/org/dashfoundation/dashsdk/persistence/PlatformWalletPersistenceHandler.kt, packages/kotlin-sdk/sdk/src/main/kotlin/org/dashfoundation/dashsdk/persistence/dao/DocumentDao.kt, packages/kotlin-sdk/sdk/src/main/kotlin/org/dashfoundation/dashsdk/persistence/entities/PendingInputEntity.kt) — HashEngineering
  • rust-dapi (packages/rs-dapi/src/clients/core_client.rs) — QuantumExplorer or lklimek
  • dpp — you own it
  • rs-drive-abci — you own it
  • rs-platform-wallet-ffi (packages/rs-platform-wallet-ffi/src/masternode_update_service.rs) — HashEngineering or ZocoLini or llbartekll or romchornyi
  • wallet-storage (packages/rs-platform-wallet-storage/SCHEMA.md, packages/rs-platform-wallet-storage/migrations/V007__utxo_sweep_winner_height.rs, packages/rs-platform-wallet-storage/src/sqlite/schema/core_state.rs and 1 more) — lklimek
  • rs-platform-wallet (packages/rs-platform-wallet/src/changeset/changeset.rs, packages/rs-platform-wallet/src/masternode/list.rs, packages/rs-platform-wallet/src/masternode/update_service.rs and 8 more) — HashEngineering or ZocoLini or llbartekll or romchornyi
  • rust-sdk — you own it
  • swift-sdk (packages/swift-sdk/SCHEMA_RELEASES.md, packages/swift-sdk/Sources/SwiftDashSDK/Persistence/Models/PersistentPendingInput.swift, packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/PlatformWalletManagerMasternodes.swift and 3 more) — llbartekll or romchornyi

When every merge requirement is met, the PR Hygiene check passes. Reviewer limits do not block merging; other required GitHub checks and protections still apply.

[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: 6d976edf-4a21-4514-9009-3a940075ebeb

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

• Autofix · 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]

Waiting for bot review — coderabbitai not yet · thepastaclaw ✓. 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 — no blockers (commit b60452c) · triage: critical

[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-21T20:06:55.795Z

[thepastaclaw]

Final validation — Phase 1 + Phase 2

No confirmed blocking defect remains after checking the supplied findings against the reviewed source. Four nonblocking suggestions remain concerning upstream transaction-construction ownership, effective query limits, and historical-consensus compatibility evidence. This was a static review only; current CI has no failed code checks, but Rust workspace tests, Docker image builds, and the JavaScript build remain pending.

🟡 4 suggestion(s)

Review provenance

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

• Triage: critical by gpt-6.1-sol (effort low) — This is a large, cross-cutting merge whose diff changes critical surfaces including consensus transition activation and ChainLock handling, wallet funds persistence and transaction construction, proof verification, and peer-facing Core RPC behavior.
• 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 (lane failed), 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 — 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, gpt-6.1-sol — tenderdash-consensus-security (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-platform-wallet/src/masternode/update_service.rs`:
- [SUGGESTION] packages/rs-platform-wallet/src/masternode/update_service.rs:472-485: Put version-aware ProUpServTx construction in key-wallet
  This branch selects the Core payload version and constructs its version-specific address representation. The book's ownership table assigns Core transaction construction to rust-dashcore/key-wallet, while rs-platform-wallet orchestrates. At the pinned upstream revision, ProviderUpdateServicePayload::new still constructs version 2, and TransactionBuilder provides generic payload/finalizer hooks rather than this reusable preparation logic. Extract a version-aware ProUpServTx preparation API upstream, with Platform supplying the live entry, activation observation, payout choice, and signer, or link an issue tracking that extraction. rust-dashcore#1202 covers coinbase observation, not construction ownership; #1146 concerns payload representation rather than this preparation API.

In `packages/rs-drive-proof-verifier/src/verify.rs`:
- [SUGGESTION] packages/rs-drive-proof-verifier/src/verify.rs:35-38: Resolve the effective page size at the query API boundary
  Trying DEFAULT_QUERY_LIMIT and then an unbounded query cannot recover every server-configured page size. With default_query_limit = 200 and 201 matching groups, query_group_infos_v0 proves 200 entries: verification as 100 rejects surplus proof data, while unbounded verification requires the omitted tail. The new test matrix covers a larger default only when all stored results fit inside that page. Both attempts remain cryptographically strict, so this is incomplete query support, not proof acceptance without verification. Resolve the limit at the query API boundary—by making the requested limit explicit or returning the effective limit—and pass it to Drive verification. Add a full nonstandard-page case; if deferred, link a tracking issue.

In `packages/rs-drive-abci/src/execution/platform_events/state_transition_processing/decode_raw_state_transitions/v0/mod.rs`:
- [SUGGESTION] packages/rs-drive-abci/src/execution/platform_events/state_transition_processing/decode_raw_state_transitions/v0/mod.rs:111-116: Document the consensus-inert exception for the shipped v0 decoder
  This edits the decoder generation selected by protocol versions 1–13. The consensus-inert argument is supported by the callers: FailedToDecode becomes InternalError, InvalidEncoding becomes UnpaidConsensusError, prepare_proposal removes either without returning its transaction result, and process_proposal rejects either through failed_count + invalid_unpaid_count. Neither decoding outcome applies state or charges fees. Record that invariant beside this branch and in the book-required "In-place changes to shipped generations" PR section. The current comment explains the improved client error, and the PR identifies the affected versions, but neither records why historical consensus is unchanged. This is a documentation request, not evidence that a dispatcher bump is needed.

In `Cargo.lock`:
- [SUGGESTION] Cargo.lock:6700-6703: Add explicit cross-version evidence for consensus decimal arithmetic
  The rust_decimal 1.42.1 → 1.43.0 update affects the dependency used by historical epoch calculations and storage-fee distribution/refund arithmetic, without changing their protocol-version selections. The existing exact-value tests and reported source comparison are useful evidence, but do not directly compare both dependency versions. Add a reproducible compatibility corpus covering epoch boundaries, large credit amounts, and refund rounding under both versions. No numeric divergence has been established, so this is a nonblocking validation suggestion, not a request to version an otherwise equivalent dependency update. If a comparison does expose a mismatch, preserve historical results and activate the changed arithmetic only through an unreleased protocol version.