[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) and #5604 (generatedFrom sys.tokens.decimals, which this branch merges; review #5604 first, its commits show here until it merges). 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 as one description covering both (merge_estimated_layer: the depth of the deeper by estimate_levels and, at that depth, the nodes GroveDB's own average_case_merk_propagate prices dearer, in credits at the version's fees, the shallower description being priced at the deeper one's depth; then a fixed tie-break; Drive keeps no size model of its own). GroveDB gives every operation at a path the one description the batch keeps, so no operation is priced below its own description, no operation's registration lowers another's, and the batch's estimate is the same whatever their order. This raises the estimated fee of any batch whose operations describe a shared layer differently, not only the marketplace's: an ordinary document transition's nonce update describes the root a level deeper than the document does, so its root is now estimated at the nonce's depth (the sponsored token payment of nullifier_batch_guard: +171,440 estimated processing credits; the fee paid does not change). 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, 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. decimals is declared "generatedFrom": { "function": "sys.tokens.decimals", "params": ["tokenId"] } (feat(platform)!: generatedFrom sys.tokens.decimals generates a token's decimals (PV15) #5604): generated when the order is created and kept after. Orders carry no minimum fill: the token's trade mode sets it (feat(platform)!: token marketplace listings (PV15) #5529).
• 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 applied fees of the same tests still match; their estimated processing fees move +171,440 from apply_drive_operations 2, as above.

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

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 and a prefunded balance write (root 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 of narrower nodes merges with a shallower one of dearer nodes into the deeper depth with the dearer nodes, priced at least as high as each, while a deeper description of dearer nodes is kept as is, 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 keeps its depth with the dearer of the two nodes, 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: decimals is required, 0 and 255 pass, 256 is refused (run before minFill was dropped; the spec now has no minFill cases and has not been rerun).
• After minFill was dropped and decimals declared generated: cargo test -p token-market-contract, cargo test -p drive --lib order_escrow, cargo test -p drive-abci --lib -- token_market create_genesis_state (19 + 8 passed).
• 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, and a contract preloaded under its id is refused before 15 in every build, with or without the contract's feature (should_refuse_a_preloaded_token_market_id_before_protocol_15_in_any_build).

In-place changes to shipped generations

The new behaviour comes through new generations: the voting balance, contract fee pot, token balance and identity balance estimations and apply_drive_operations (2, 1, 1, 1 and 2) are selected only by DRIVE_VERSION_V10 (protocol version 15), and the escrow fields of DRIVE_TOKEN_METHOD_VERSIONS_V1 are new and None. Code that earlier protocol versions run is edited in four places, each inert there, with a comment at the edit saying why:

• calculate_total_tokens_balance 0 (protocol versions 1 to 13) and 1 (14): TotalTokensBalance gains total_token_order_escrow_balances, and both set it to 0, so the totals they report are unchanged.
• TotalTokensBalance::ok() and total_balances() (dpp, unversioned), run at every protocol version by the block-end supply check (validate_token_aggregated_balance 0): they also refuse a negative escrow total and add it to the balance side. Below 15 the escrow total is always 0, so the refusal cannot fire and the sum is unchanged; only the overflow error's text differs, on an invariant that has already failed. The block-end check's comment now counts the escrow too.
• apply_drive_operations 1 (14): forfeit_storage_refunds becomes pub(super) so generation 2 reuses it. Its body is unchanged, so protocol version 14 forfeits exactly as before.
• apply_drive_operations 1's tests run at protocol version 14 and at the latest version (generation 2), so each generation keeps its coverage. Tests only.
• From feat(platform)!: generatedFrom sys.tokens.decimals generates a token's decimals (PV15) #5604 (generatedFrom sys.tokens.decimals), which this branch merges: the Drive document create and replace transformers (selected at every protocol version) call generate_state_read_properties; validate_generated_from_properties_v0 (14) skips the value comparison for a function that reads state; validate_generated_from_declarations (parser generation 3, 14) checks an identifier param, indexOnly and contested indexes for a token function; verify_state_transition_was_executed_with_proof v0 copies a state-generated value from the proved document (adopt_state_generated_properties); the create transformer adds its contest fee to the generation fee instead of assigning it. Each is inert before protocol version 15 by construction: only apply_generated_from 1 (15) admits a sys.tokens function, meta-schema v3 and generation 0 refuse it, so no type parsed earlier declares one, the generation returns at once with a zero fee, and nothing is skipped or copied. feat(platform)!: generatedFrom sys.tokens.decimals generates a token's decimals (PV15) #5604's description lists them too.

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 · 3f80b80

• Bots — thepastaclaw ✓
• Self-review — post /self-reviewed
• Build green
• 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 — 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 — 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]

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

The PV15 marketplace implementation is internally consistent, and the prior review findings have been addressed or withdrawn. Two non-blocking issues remain: subscription filters cannot evaluate the new state-generated token-decimals field, and the PR's in-place-generation documentation does not list all shipped transformer/helper edits. CI shows no failed code checks; changed-package determination and PR Hygiene remain pending.

🟡 2 suggestion(s)

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

🟡 Suggestion: Account for state-generated fields in document transition filters
packages/rs-drive/src/query/filter.rs:418-432

data_as_stored only invokes fill_generated_properties, whose implementation handles parameter-derived string transformations and does not resolve state-reading functions such as sys.tokens.decimals. Consequently, a create or replace subscription filter that constrains decimals sees the transition's intentionally omitted field as absent and rejects the transition, even though platform execution will generate and store the value. Either provide this filter path with the required state reader or explicitly reject/document state-generated fields in transition filters rather than silently treating them as missing.

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

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: muse-spark-1.3-contributor (agent: phase1-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 that modifies consensus-critical protocol-version activation, persisted-state genesis and upgrade migrations, token supply accounting, and escrow-related funds state 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/src/query/filter.rs`:
- [SUGGESTION] packages/rs-drive/src/query/filter.rs:418-432: Account for state-generated fields in document transition filters
  `data_as_stored` only invokes `fill_generated_properties`, whose implementation handles parameter-derived string transformations and does not resolve state-reading functions such as `sys.tokens.decimals`. Consequently, a create or replace subscription filter that constrains `decimals` sees the transition's intentionally omitted field as absent and rejects the transition, even though platform execution will generate and store the value. Either provide this filter path with the required state reader or explicitly reject/document state-generated fields in transition filters rather than silently treating them as missing.

In `packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_create_transition_action/v0/transformer.rs`:
- [SUGGESTION] packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_create_transition_action/v0/transformer.rs:91-105: Document the inert edits to shipped document-transformer generations
  The shipped v0 create and replace transformers now call `generate_state_read_properties`, and the shared DPP/proof helpers were extended to recognize state-generated token properties. The protocol-version gates make these edits inert before protocol 15 because earlier contract parsers cannot produce `TokenFunction`, but the PR's "In-place changes to shipped generations" section lists only the total-token, balance/refund, and test changes. Add these transformer/helper edits, the affected pre-15 generations, and their unreachable-by-construction rationale so the historical replay audit is complete.

[github-actions]

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

[github-actions]

Waiting for bot review — 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 — 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]

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

At the reviewed head, the protocol-15 escrow, token-market contract, activation, conservation, proof, and estimation changes are generally correctly versioned and wired. One in-scope suggestion remains: subscription transition filters reconstruct only stateless generated properties, so filters on the new state-generated token decimals field can miss valid create or replace transitions that omit decimals. CI has passed the Rust workspace and relevant package checks, while the broader suite and local-network checks were still running in the supplied snapshot.

🟡 1 suggestion(s)

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

🟡 Suggestion: Account for state-generated fields in document transition filters
packages/rs-drive/src/query/filter.rs:418-432

data_as_stored calls DocumentTypeBasicMethods::data_as_stored, which only invokes fill_generated_properties. That helper uses SystemFunction::apply, and TokenFunction::Decimals intentionally returns None because it requires a state read. The new token-market schemas declare decimals as generated by sys.tokens.decimals, and clients omit it so the Drive transformer can resolve it from token state. Therefore, a create or replace subscription filter clause on decimals evaluates against a map where the field is absent and can return Fail, even though the resulting stored document contains the generated value. Make this filter path state-aware by supplying the resolved document data, or explicitly reject filter clauses targeting state-generated properties instead of silently treating them as absent; add coverage for an omitted ask.decimals or bid.decimals field.

_{source: muse-spark-1.3-contributor (phase1-reviewer: general); gpt-6.1-sol (phase2-reviewer: general, architecture-layering, rust-quality)}

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 that modifies consensus-critical protocol-version dispatch, persistent storage initialization and upgrade migrations, and token escrow/supply accounting in the genesis and protocol-upgrade paths.
• 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/src/query/filter.rs`:
- [SUGGESTION] packages/rs-drive/src/query/filter.rs:418-432: Account for state-generated fields in document transition filters
  `data_as_stored` calls `DocumentTypeBasicMethods::data_as_stored`, which only invokes `fill_generated_properties`. That helper uses `SystemFunction::apply`, and `TokenFunction::Decimals` intentionally returns `None` because it requires a state read. The new token-market schemas declare `decimals` as generated by `sys.tokens.decimals`, and clients omit it so the Drive transformer can resolve it from token state. Therefore, a create or replace subscription filter clause on `decimals` evaluates against a map where the field is absent and can return `Fail`, even though the resulting stored document contains the generated value. Make this filter path state-aware by supplying the resolved document data, or explicitly reject filter clauses targeting state-generated properties instead of silently treating them as absent; add coverage for an omitted `ask.decimals` or `bid.decimals` field.

[github-actions]

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

[github-actions]

Waiting for bot review — 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]

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

The protocol-15 token-market escrow, conservation, versioning, schema, activation, and fee-estimation changes are correctly gated and the previously reported issues are addressed or no longer applicable. One in-scope correctness issue remains: subscription transition filters still cannot materialize the new state-generated token decimals property, so filters can reject valid creates or replaces. Relevant Rust, build, and several SDK checks passed in CI, while broader test and E2E checks were still queued or running at the evidence snapshot.

🟡 1 suggestion(s)

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

🟡 Suggestion: Account for state-generated fields in document transition filters
packages/rs-drive/src/query/filter.rs:418-432

data_as_stored reconstructs only the stateless generatedFrom properties through fill_generated_properties. The new token-market ask.decimals and bid.decimals properties use the state-reading sys.tokens.decimals function; those values are materialized separately by Drive's create and replace transformers using token state and fee-bearing reads. Consequently, a normal transition that correctly omits decimals is evaluated by this filter with no decimals field, even though the platform stores the generated value. A subscription clause such as decimals == 8 therefore fails for a valid create or replace. Add a state-aware filter path that resolves the property using the same Drive callback as transformation, or explicitly reject filters that depend on state-generated properties rather than treating them as absent.

_{source: muse-spark-1.3-contributor (phase1-reviewer: general); gpt-6.1-sol (phase2-reviewer: architecture-layering, rust-quality)}

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: muse-spark-1.3-contributor (agent: phase1-reviewer, role: rust-quality); 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 large, intricate diff changes consensus-critical token supply accounting and escrow state, while adding protocol-version-gated persistent trees and a genesis-to-upgrade storage migration 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/src/query/filter.rs`:
- [SUGGESTION] packages/rs-drive/src/query/filter.rs:418-432: Account for state-generated fields in document transition filters
  `data_as_stored` reconstructs only the stateless `generatedFrom` properties through `fill_generated_properties`. The new token-market `ask.decimals` and `bid.decimals` properties use the state-reading `sys.tokens.decimals` function; those values are materialized separately by Drive's create and replace transformers using token state and fee-bearing reads. Consequently, a normal transition that correctly omits `decimals` is evaluated by this filter with no `decimals` field, even though the platform stores the generated value. A subscription clause such as `decimals == 8` therefore fails for a valid create or replace. Add a state-aware filter path that resolves the property using the same Drive callback as transformation, or explicitly reject filters that depend on state-generated properties rather than treating them as absent.

[github-actions]

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