[QuantumExplorer]

Basic explanation

What this does: Prepares Platform's state for the token marketplace. It adds the two places where escrow will live: one tree for the tokens holders list for sale, and one for the credits buyers offer. It also adds a new system data contract, the token market contract, whose two document types, ask (a listing) and bid (an offer), will hold the open orders. Platform's check that no tokens appear or vanish is taught to count the escrowed tokens. Nothing can place an order yet: the transitions that use all this come in the next pull requests of the stack.

Value: The order book becomes readable with the document queries and proofs every SDK already has, including the depth at each price as one proven sum, without any new query endpoint. Each side's depth sums what it holds in escrow, so the sums can never overflow.

Risks: Medium. From protocol version 15 the genesis state and the upgrade both gain two trees and a contract, so every node must build them identically: a test checks that a chain born at 15 and a chain upgraded from 14 build byte-identical [Tokens] and [PreFundedSpecializedBalances] subtrees. Before 15 nothing changes: the trees, the contract and the new supply calculator are selected only by the protocol version 15 tables. Fee numbers in tests that start at the latest version move, because genesis has one more contract.

Issue being fixed or feature implemented

The second PR of the token marketplace stack (PV15), on top of #5524 (tradeable tokens). A listing must hold the tokens it offers and an offer the credits it offers, so a fill always delivers. This PR adds that escrow storage, the contract that records the open orders, and the supply check that keeps counting escrowed tokens.

What was done?

Escrow trees (DRIVE_VERSION_V10, PV15)

• [Tokens, TOKEN_ORDER_ESCROW_KEY (96)]: a BigSumTree with one SumTree per token, created with the token's first listing, of SumItems keyed by order id.
• [PreFundedSpecializedBalances, PREFUNDED_BALANCES_FOR_TOKEN_ORDERS (32)]: a SumTree of SumItems keyed by order id.
• Both come from one helper, Drive::insert_token_order_escrow_trees, called last by create_initial_state_structure_v5 (genesis) and by transition_to_version_15 (upgrade). Each new key becomes a leaf of its Merk, so neither root moves.
• Primitives the order transitions will use, all versioned under DriveTokenMethodVersions::order_escrow: add, set, remove and fetch for both escrows, with cost estimation. Each is an OptionalFeatureVersion: None in DRIVE_TOKEN_METHOD_VERSIONS_V1 (so in every table before 15), Some(0) in DRIVE_TOKEN_METHOD_VERSIONS_V3; called with an earlier protocol version, each returns DriveError::VersionNotActive instead of building operations for trees that do not exist there.
• Cost estimation: one batch keeps one description per layer, so every escrow description keeps a deeper one another write of the batch registered (util::estimated_layers). The offers' escrow key, 32, sits on the third level of the prefunded specialized balances Merk (128 over 64 and 192), so the credit escrow describes that layer at level 2. The voting balance and contract fee pot estimations describe it at level 1, their keys' depth; from 15 (DRIVE_VERSION_V10) their new generations, estimated_cost_for_prefunded_specialized_balance_update 2 and add_estimation_costs_for_contract_fee_pot_update 1, run the previous generation and put back a deeper description it replaced, so the order of registration no longer matters. Likewise a listing's escrow key sits on level 3 of the Tokens Merk, below the balances key the token balance estimation describes at level 0: from 15 for_token_balances 1 keeps a deeper description of the Tokens layer. Both escrows also sit deeper in the root tree than the identity balances (level 1) and token balances (level 2) keys, so from 15 for_balances 1, for_token_balances 1 and the voting balance estimation 2 keep a deeper description of the root too: an offer's batch, which debits the buyer and credits the escrow, is estimated with the root at level 3 whichever operation is built first. The other writes of a batch (a document, a nonce) register their own descriptions, so the rule is also kept at the batch's boundary: apply_drive_operations 2 (protocol 15) lowers each operation of an estimated batch with layer descriptions of its own and merges them into the batch's keeping the costlier one (merge_estimated_layer: the deeper by estimate_levels, then at one depth the one GroveDB's own average_case_merk_propagate prices dearer, in credits at the version's fees, then a fixed tie-break; Drive keeps no size model of its own), so no operation's registration lowers another's and the batch's estimate is the same whatever their order. Applying a batch is unchanged. Before 15 they all run unchanged.

Token conservation (calculate_total_tokens_balance 2)

• TotalTokensBalance gains total_token_order_escrow_balances (0 from v0 and v1), and ok() / total_balances() add it to the balance side.

Tokens moved from a balance into escrow, 1,000 minted and 400 listed:

Before (calculate_total_tokens_balance 1): supply 1000, balances 600, pools 0        -> not balanced, the block-end check halts
After  (calculate_total_tokens_balance 2): supply 1000, balances 600, escrow 400     -> balanced

The credit check needs no change: the prefunded specialized balances root is a SumTree and already counts every child.

Token market contract (new package packages/token-market-contract, SystemDataContract::TokenMarket = 11, ID AE6yYq65VdfGCg2MSyV9vV7cWGiFWjbwBuy7THesDh4e)

• ask and bid: tokenId, price (credits per whole token), amount, remaining, minFill, optional expiresAt, decimals (0 to 255, the token's decimals when the order was placed, which every fill prices it at), and for bid the escrowed escrow.
• Indexes book (tokenId, decimals, price, $createdAt), depth (tokenId, decimals, price, summable + rangeSummable: remaining for asks, escrow for bids) and byOwner. Prices are per whole token at each order's decimals, so the book and the depth sums keep each scale apart: a query names the token and its decimals, and a sum never adds prices of two scales.
• Config sizedIntegerTypes: false: every integer is i64, as a summed property must be, and a partial fill rewrites an order without changing its size.
• creationRestrictionMode 2; the types stay mutable and deletable (as withdrawals do) so orders carry a revision and storage flags.
• Registered at genesis from PV15 (create_genesis_state v1 behind >= TOKEN_MARKETPLACE_INITIAL_PROTOCOL_VERSION), stored without storage flags by transition_to_version_15, served by the Drive system contract cache and the trusted context provider from 15.
• SYSTEM_DATA_CONTRACT_VERSIONS_V4 gains token_market: 1 (0 in V1 to V3).

Data trigger bindings 3 (DRIVE_ABCI_VALIDATION_VERSIONS_V11): v2 plus reject_data_trigger on Replace and Delete of ask and bid.

A user's document transition against an order, protocol version 15:

create ask -> refused, DocumentCreationNotAllowedError (creationRestrictionMode 2)
replace ask / delete bid -> refused, DataTriggerConditionError "Action is not allowed"

Test fixtures at the latest version: a genesis at 15 holds one more contract and two more trees, so four document fee baselines move (delete and replace -47_280, DPNS create +137_760, the two DPNS v3 rows at 15 +95_920; each comment says why) and the shielded pool characterization digests of nullifier_batch_guard that cover the state root are re-pinned (ten of them, re-pinned again when the orders gained decimals). The fee assertions of the same tests still match.

Wiring: workspace and Yarn workspace, Dockerfile stages, package filters, CI test lists, codecov, data-contracts/dpp/rs-sdk/rs-sdk-ffi/wasm-sdk/trusted context provider features, the GroveDB structure description (.since(15)) and grovedb-structure.json, the book (data-model/token-marketplace.md, architecture overview) and v15 note 6.

How Has This Been Tested?

• cargo test -p token-market-contract -p data-contracts: the published ID, the schema shape, no contract below 15.
• cargo test -p dpp --features all_features --lib -- token_market_tests total_tokens_balance: the contract loads with full validation at the latest version (mutable, deletable, no user creation, i64 integers, summed depth); the escrow term balances the check.
• cargo test -p drive --lib -- structure order_escrow should_serve_token_market calculate_total_tokens (52 passed): add/set/remove/fetch of both escrows; supply stays balanced when tokens move into escrow at 15 and reads as unbalanced with the PV14 calculator; the cache serves the contract from 15; a new structure fixture reaches every escrow node.
• cargo test -p drive --lib -- order_escrow estimated_layers fee_pot prefunded (59 passed):
  • every one of the ten escrow methods returns VersionNotActive at protocol version 14 and works at the latest;
  • characterization: for a listing's and an offer's first write and their partial-fill update, the estimated processing fee covers the applied one on the initial state (the offer's first write: 2,687,840 estimated against 415,660 applied, with the layer at level 1 or 2 alike, so the level itself is pinned by the next test);
  • the prefunded balances layer is described at level 2 after the escrow and either sibling in either order at the latest version, and at level 1 by protocol version 14's siblings;
  • the keep-the-deeper helper inserts unless a description at least as deep exists, and puts back a deeper one an estimation overwrote.
  • a token balance removal and an escrow addition built into one estimation, in either order, leave the Tokens layer at the escrow's level 3; with protocol version 14's balance estimation built last it is 0, as before;
  • an identity balance debit and a credit escrow addition built into one estimation, in either order, leave the root at level 3 and the prefunded layer at 2; with protocol version 14's balance estimation built last the root is 1, as before;
  • apply_drive_operations 2: a batch of an identity contract nonce update (root level 0) and a prefunded balance write (level 3) is estimated alike in either order at the latest version, and at least as high as either order at protocol version 14, where the two orders differ;
  • a token mint and a prefunded balance write, both describing the root at depth 3 with different key sizes and sum trees, are estimated alike in either order (they differ when equal depths keep the first);
  • merge_estimated_layer: at one depth AllItems(32, 8) beats AllSubtrees(32, AllBigSumTrees) in either order (GroveDB prices it 254,960 credits against 221,360), a deeper description wins whatever its nodes, and AllItems(32, 8) and AllReference(32, 8), priced alike, merge to the same one in either order;
  • the generation 1 dispatcher tests (processing pool returns, debt repayment order, overflow, rollback) run at protocol version 14 and at the latest version.
  • merge_estimated_layer: two descriptions at one depth merge to the one pricing the larger node in either order, a deeper one wins whatever its node, and two that price alike merge to the same one in either order;
  • three listings at one price, two at decimals 8 and one at decimals 2: the depth sum at decimals 8 is 500 and at 2 is 50, and the proven per-price sum at 8 verifies against the client's path query with one bucket of 500;
  • the order bindings through data_trigger_bindings_list at the latest version: each replace and delete of an ask and a bid matches exactly one binding, and running it refuses with DataTriggerConditionError; protocol version 14 binds none of them.
• cargo test -p drive-abci --lib -- batch::tests::token batch::tests::document::{deletion,replacement,dpns} --skip shielded (344 passed): the PV15 token balance estimation moves no pinned fee.
• yarn workspace @dashevo/token-market-contract test (27 passing): decimals is required, 0 and 255 pass, 256 is refused.
• cargo test -p drive-abci --lib -- create_genesis_state perform_events_on_first_block_of_protocol_change data_triggers batch::tests::document::{deletion,replacement,dpns,creation,index_only}:
  • the contract is in a genesis born at 15 and not at 14;
  • transition_to_version_15 inserts it, served by the cache afterwards;
  • genesis at 15 and an upgrade from 14 build byte-identical [Tokens] and [PreFundedSpecializedBalances] subtrees and root elements;
  • bindings 3 keep every v2 binding and reject the four order actions.
• cargo test -p drive-abci --lib -- batch::tests::token state_transitions::data_contract_create state_transitions::data_contract_update (569 passed before the two re-pinned shielded pool digests; both pass after).
• Trusted context provider: the contract is served from 15 and not at 14.

In-place changes to shipped generations

None. The voting balance, contract fee pot, token balance and identity balance estimations, and apply_drive_operations, change only through new generations (2, 1, 1, 1 and 2) that only DRIVE_VERSION_V10 (protocol version 15) selects; the escrow fields of DRIVE_TOKEN_METHOD_VERSIONS_V1 are new and None.

Breaking Changes

Consensus, from protocol version 15: new state trees at genesis and on the upgrade, a new system data contract, a new token conservation calculator and new data trigger bindings. Earlier protocol versions are unchanged.

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 · 436c30c

• Bots — coderabbitai not yet · thepastaclaw requested changes — dismiss the review or push a fix, 2 threads unresolved — resolve them — /skip-bots proceeds without the ones not yet reported
• Self-review — post /self-reviewed
• Build failed
• Approvals
  • files with no dedicated owner — you own it
  • github (.github/package-filters/js-packages-direct.yml, .github/package-filters/js-packages-no-workflows.yml, .github/package-filters/js-packages.yml and 6 more) — ktechmidas or shumkov
  • system-contracts — you own it
  • dpp — you own it
  • rs-drive-abci — you own it
  • rs-drive — you own it
  • rust-sdk-ffi (packages/rs-sdk-ffi/Cargo.toml) — lklimek or shumkov
  • rust-sdk (packages/rs-sdk/Cargo.toml) — lklimek or shumkov
  • js-wasm-sdk (packages/wasm-sdk/Cargo.toml) — shumkov

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.

[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.

[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.

[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.

[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.

[github-actions]

📜 System contracts

This pull request adds or changes system contract document schemas. The contract viewer diagrams each one, and a comparison marks what is added, changed and removed, with the update rule each change meets.

• packages/token-market-contract/schema/v1/token-market-contract-documents.json: new contract. Open it in the contract viewer

Compared 88c31c2bc1 with 436c30cab7. Updated at 2026-10-25T15:03:01.810Z

[thepastaclaw]

Re-review — Final validation — Phase 1 + Phase 2

Static review of exact head 860dac3 found two non-blocking issues in newly added estimation and regression-test code: layer descriptions are priced eagerly even when depth already determines the result, and the genesis/upgrade equivalence guard does not compare authenticated Merk subtree hashes. All 19 prior findings are fixed; code-related CI checks pass, with only PR Hygiene still pending.

🟡 2 suggestion(s)

Review provenance

Source: reviewer 1: muse-spark-1.3-contributor (agent: phase1-reviewer, role: general); reviewer 2: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 3: gpt-6.1-sol (agent: phase2-reviewer, role: architecture-layering); reviewer 4: gpt-6.1-sol (agent: phase2-reviewer, role: platform-versioning); reviewer 5: gpt-6.1-sol (agent: phase2-reviewer, role: rust-quality); reviewer 6: gpt-6.1-sol (agent: phase2-reviewer, role: security-auditor); reviewer 7: gpt-6.1-sol (agent: phase2-reviewer, role: tenderdash-consensus-security); reviewer 8: muse-spark-1.3-contributor (agent: phase1-reviewer, role: rust-quality); reviewer 9: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 10: gpt-6.1-sol (agent: phase2-reviewer, role: architecture-layering); reviewer 11: gpt-6.1-sol (agent: phase2-reviewer, role: platform-versioning); reviewer 12: gpt-6.1-sol (agent: phase2-reviewer, role: rust-quality); reviewer 13: gpt-6.1-sol (agent: phase2-reviewer, role: security-auditor); reviewer 14: 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) — The large, intricate diff changes consensus-critical persisted state through create_initial_state_structure_v5 and transition_to_version_15, adds escrow storage primitives, and changes token supply accounting in packages/rs-drive/src/drive/tokens/calculate_total_tokens_balance/v2/mod.rs.
• 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 quota lookup 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 final gate: an independent Phase-2 review ran after iterative findings were reconciled
• 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, 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-drive/src/util/estimated_layers.rs`:
- [SUGGESTION] packages/rs-drive/src/util/estimated_layers.rs:77-84: Price layer descriptions lazily after the depth comparison decides
  `Ordering::then` evaluates its argument eagerly, so both `propagation_credits` calls run even when `estimate_levels()` already determines that one description is deeper. Besides repeating GroveDB propagation estimation and fee conversion unnecessarily for every unequal-depth merge, the eager `?` can make the comparison fail because of an irrelevant pricing error. Return the depth ordering first and invoke GroveDB pricing only when the depths tie; reserve the debug tie-break for equal prices.

In `packages/rs-drive-abci/src/execution/platform_events/protocol_upgrade/perform_events_on_first_block_of_protocol_change/v0/mod.rs`:
- [SUGGESTION] packages/rs-drive-abci/src/execution/platform_events/protocol_upgrade/perform_events_on_first_block_of_protocol_change/v0/mod.rs:4025-4031: Compare authenticated subtree hashes in the genesis/upgrade guard
  The equivalence guard compares decoded `Element` values and recursively compares decoded key/value maps, but `Tree` and `SumTree` elements carry only metadata such as the root key, flags, and aggregate—not the Merk hash or internal AVL topology. Two subtrees with the same keys and values can therefore pass this assertion while having different authenticated root hashes. Since this test is intended to detect the byte-level genesis-versus-upgrade divergence introduced by the new tree construction, open each named subtree through GroveDB's transactional Merk API using `txn_b` and compare its `Merk::root_hash()` with the corresponding genesis subtree hash, while retaining the element walk for diagnostics.

[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]

Re-review — Final validation — Phase 1 + Phase 2

Reviewed the complete diff at exact head ad0d84f and found no actionable in-scope issues. The PV15 activation, escrow accounting, authenticated genesis/upgrade checks, order write protection, and order-independent fee estimation are consistently wired, while CI code checks are passing or pending rather than failing; the Rust workspace test check remains pending.

🔴 0 blocking | 🟡 0 suggestion(s) | 💬 0 nitpick(s)

Review provenance

Source: reviewer 1: muse-spark-1.3-contributor (agent: phase1-reviewer, role: general); reviewer 2: muse-spark-1.3-contributor (agent: phase1-reviewer, role: rust-quality); reviewer 3: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 4: gpt-6.1-sol (agent: phase2-reviewer, role: architecture-layering); reviewer 5: gpt-6.1-sol (agent: phase2-reviewer, role: platform-versioning); reviewer 6: gpt-6.1-sol (agent: phase2-reviewer, role: rust-quality); reviewer 7: gpt-6.1-sol (agent: phase2-reviewer, role: security-auditor); reviewer 8: gpt-6.1-sol (agent: phase2-reviewer, role: tenderdash-consensus-security); reviewer 9: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 10: gpt-6.1-sol (agent: phase2-reviewer, role: architecture-layering); reviewer 11: gpt-6.1-sol (agent: phase2-reviewer, role: platform-versioning); reviewer 12: gpt-6.1-sol (agent: phase2-reviewer, role: rust-quality); reviewer 13: gpt-6.1-sol (agent: phase2-reviewer, role: security-auditor); reviewer 14: 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 large, intricate diff changes consensus-persisted state through create_initial_state_structure_v5 and transition_to_version_15, adds escrow accounting in calculate_total_tokens_balance/v2, and changes versioned batch cost calculation.
• 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 quota lookup 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 final gate: an independent Phase-2 review ran after iterative findings were reconciled
• 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, 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 the current code and confirm that no unresolved issues remain.

No unresolved findings remain from the prior review on this head.

[github-actions]

Bots are done — your move: post /self-reviewed.
Full checklist in the description.

[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.

[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.

[github-actions]

Waiting for bot review — coderabbitai not yet · thepastaclaw requested changes — dismiss the review or push a fix, 2 threads unresolved — resolve them. 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]

Re-review — Final validation — Phase 1 + Phase 2

The change still has two blocking correctness issues: the protocol-upgrade path inserts the token-market contract through a separate batch without verifying the authenticated DataContractDocuments root against fresh v15 genesis, and the advertised optional expiresAt field is absent from both frozen order schemas. Three non-blocking issues remain around trusted-provider cache activation, the stale v15 binding annotation, and the Debug-based estimator tie-break. The Rust workspace test check is failed on this head, while several changed-package checks remain queued; the supplied snapshot does not identify the Rust failure, so it is not independently attributed here.

🔴 2 blocking | 🟡 3 suggestion(s)

2 finding(s) not shown inline (the lines are not part of this PR's diff)

🟡 Suggestion: Do not let the known-contract cache bypass protocol activation
packages/rs-sdk-trusted-context-provider/src/provider.rs:1038-1041

get_data_contract returns a contract from known_contracts before checking system-contract activation. If a TokenMarket contract is registered in that cache while serving protocol 15, a later lookup for the same ID with protocol version 14 returns it even though the contract is absent before protocol 15. Keep system-contract entries version-keyed or perform the activation check before the generic cache lookup so every request receives a contract valid for its requested protocol version.

_{source: gpt-6.1-sol (phase2-reviewer: architecture-layering)}

🟡 Suggestion: Correct the stale PLATFORM_V15 data-trigger binding changelog
packages/rs-platform-version/src/version/v15.rs:112-117

PLATFORM_V15 selects data-trigger bindings generation 3, which appends the four token-market order replace/delete bindings, but note 3 still says that the data trigger bindings stay at 2. Although the following sentence discusses the unchanged DPNS bindings, the unqualified statement contradicts the selected table and note 8 and can mislead protocol-version audits. Clarify that the existing DPNS bindings remain at v2 while the token-market bindings are added by generation 3.

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

Review provenance

Source: reviewer 1: muse-spark-1.3-contributor (agent: phase1-reviewer, role: general); reviewer 2: muse-spark-1.3-contributor (agent: phase1-reviewer, role: rust-quality); reviewer 3: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 4: gpt-6.1-sol (agent: phase2-reviewer, role: architecture-layering); reviewer 5: gpt-6.1-sol (agent: phase2-reviewer, role: platform-versioning); reviewer 6: gpt-6.1-sol (agent: phase2-reviewer, role: rust-quality); reviewer 7: gpt-6.1-sol (agent: phase2-reviewer, role: security-auditor); reviewer 8: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 9: gpt-6.1-sol (agent: phase2-reviewer, role: architecture-layering); reviewer 10: gpt-6.1-sol (agent: phase2-reviewer, role: platform-versioning); reviewer 11: gpt-6.1-sol (agent: phase2-reviewer, role: rust-quality); reviewer 12: 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) — This is a large, intricate change to consensus-critical protocol-version dispatch and persisted storage migrations, including genesis/upgrade state construction, escrow accounting, and total-token-balance validation in rs-drive and rs-drive-abci.
• 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 quota lookup 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 final gate: an independent Phase-2 review ran after iterative findings were reconciled
• 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 — 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

🤖 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/platform_events/protocol_upgrade/perform_events_on_first_block_of_protocol_change/v0/mod.rs`:
- [BLOCKING] packages/rs-drive-abci/src/execution/platform_events/protocol_upgrade/perform_events_on_first_block_of_protocol_change/v0/mod.rs:949-956: Use a consensus-equivalent insertion path for the token-market contract
  Fresh v15 genesis queues the TokenMarket contract with the other system contracts and applies the complete set through one batch, whereas the v14-to-v15 upgrade calls Drive::apply_contract separately against the already-populated DataContractDocuments Merk. Merk topology and the authenticated parent root can depend on insertion history, so the two paths can produce different application-state roots even when the token-market contract leaf is identical. The current equivalence test only compares the Tokens and PreFundedSpecializedBalances subtrees and does not compare the authenticated DataContractDocuments root. Use a shared deterministic insertion mechanism or extend the equivalence guard to prove the complete DataContractDocuments subtree and authenticated root match.

In `packages/token-market-contract/schema/v1/token-market-contract-documents.json`:
- [BLOCKING] packages/token-market-contract/schema/v1/token-market-contract-documents.json:55-107: Declare the advertised expiresAt property in both order schemas
  The PR description explicitly promises an optional expiresAt property for ask and bid orders, but neither document type declares it. Both schemas set additionalProperties to false, so the next marketplace transition that writes an expiry will be rejected as an unknown-property/schema error even though the contract is activated and frozen at protocol version 15. Add the intended optional field to both schemas before activation, or remove the expiration promise and update the associated documentation and follow-up contract design.

In `packages/rs-sdk-trusted-context-provider/src/provider.rs`:
- [SUGGESTION] packages/rs-sdk-trusted-context-provider/src/provider.rs:1038-1041: Do not let the known-contract cache bypass protocol activation
  get_data_contract returns a contract from known_contracts before checking system-contract activation. If a TokenMarket contract is registered in that cache while serving protocol 15, a later lookup for the same ID with protocol version 14 returns it even though the contract is absent before protocol 15. Keep system-contract entries version-keyed or perform the activation check before the generic cache lookup so every request receives a contract valid for its requested protocol version.

In `packages/rs-platform-version/src/version/v15.rs`:
- [SUGGESTION] packages/rs-platform-version/src/version/v15.rs:112-117: Correct the stale PLATFORM_V15 data-trigger binding changelog
  PLATFORM_V15 selects data-trigger bindings generation 3, which appends the four token-market order replace/delete bindings, but note 3 still says that the data trigger bindings stay at 2. Although the following sentence discusses the unchanged DPNS bindings, the unqualified statement contradicts the selected table and note 8 and can mislead protocol-version audits. Clarify that the existing DPNS bindings remain at v2 while the token-market bindings are added by generation 3.

In `packages/rs-drive/src/util/estimated_layers.rs`:
- [SUGGESTION] packages/rs-drive/src/util/estimated_layers.rs:84-91: Avoid Debug formatting for the layer-estimation tie-break
  When two distinct layer descriptions have equal depth and equal GroveDB propagation cost, the merge allocates and compares two Debug-formatted Strings. apply_drive_operations_v2 can execute this branch repeatedly while merging estimated operations. More importantly, Debug output is a presentation representation rather than a protocol-stable ordering; changing a Debug implementation or an upstream formatting detail could select a different descriptor and change the fee estimate for the same protocol generation. Use an explicit allocation-free structural ordering or another canonical stable key.

[thepastaclaw]

🔴 Blocking: Use a consensus-equivalent insertion path for the token-market contract

Fresh v15 genesis queues the TokenMarket contract with the other system contracts and applies the complete set through one batch, whereas the v14-to-v15 upgrade calls Drive::apply_contract separately against the already-populated DataContractDocuments Merk. Merk topology and the authenticated parent root can depend on insertion history, so the two paths can produce different application-state roots even when the token-market contract leaf is identical. The current equivalence test only compares the Tokens and PreFundedSpecializedBalances subtrees and does not compare the authenticated DataContractDocuments root. Use a shared deterministic insertion mechanism or extend the equivalence guard to prove the complete DataContractDocuments subtree and authenticated root match.

_{source: gpt-6.1-sol (phase2-reviewer: architecture-layering)}

[thepastaclaw]

🔴 Blocking: Declare the advertised expiresAt property in both order schemas

The PR description explicitly promises an optional expiresAt property for ask and bid orders, but neither document type declares it. Both schemas set additionalProperties to false, so the next marketplace transition that writes an expiry will be rejected as an unknown-property/schema error even though the contract is activated and frozen at protocol version 15. Add the intended optional field to both schemas before activation, or remove the expiration promise and update the associated documentation and follow-up contract design.

_{source: gpt-6.1-sol (phase2-reviewer: architecture-layering)}

[thepastaclaw]

🟡 Suggestion: Avoid Debug formatting for the layer-estimation tie-break

When two distinct layer descriptions have equal depth and equal GroveDB propagation cost, the merge allocates and compares two Debug-formatted Strings. apply_drive_operations_v2 can execute this branch repeatedly while merging estimated operations. More importantly, Debug output is a presentation representation rather than a protocol-stable ordering; changing a Debug implementation or an upstream formatting detail could select a different descriptor and change the fee estimate for the same protocol generation. Use an explicit allocation-free structural ordering or another canonical stable key.

_{source: gpt-6.1-sol (phase2-reviewer: rust-quality)}