fix(sdk): verify no-limit proposer, distribution and group queries against the page Drive proves

[QuantumExplorer]

Basic explanation

What this does: Some Platform queries return their answers in pages. When an app asks one of them without saying how many answers it wants, Platform sends back at most 100 answers together with a cryptographic proof of those 100. For four of these queries the SDK then checked that proof as if it should cover every answer, not just the first 100, so whenever there were more than 100 it rejected a correct answer as an invalid proof. This PR makes the SDK check the proof against the page Platform actually proved: first as the standard 100-answer page, and if that does not fit, as every answer, which is what a node whose operator configured a larger page sends. It is the same bug #5483 fixes for the five vote queries.

Value: These four queries now work with no limit named once more than 100 results exist:

• block counts of the evonodes that proposed blocks in an epoch (ProposerBlockCounts): mainnet's current epoch already has more than 200 proposers, so this fails there today;
• a token's pre-programmed distributions;
• the groups of a contract;
• the actions of a group.

It is fixed in the Rust SDK's proof verifier, which the C FFI and the wasm SDK build on.

Risks: Low. Only client-side proof checking changes; nothing a node runs or stores changes, and requests are sent exactly as before. Every answer that verified before still verifies: a no-limit request is checked first as the standard page of 100 (DEFAULT_QUERY_LIMIT, what every node set up with dashmate uses) and, if that is refused, as the complete answer it was checked as before. Each reading only accepts results the proof proves. The cost is a second proof check, only for no-limit requests whose proof is not a standard page. A node with a non-standard default that sends a full page of its own size with more answers left still fails, as it does today. The new drive-abci tests together run in under a second.

Issue being fixed or feature implemented

Follow-up to #5483, which listed these four verifiers as having the same code pattern and left them for later.

Each of these Drive handlers replaces a missing limit with config.default_query_limit (100) and proves the query with limit: Some(100):

Query	Drive handler (packages/rs-drive-abci/src/query/)	Verifier (packages/rs-drive-proof-verifier/src/)
GetEvonodesProposedEpochBlocksByRangeRequest	validator_queries/proposed_block_counts_by_range/v0	proof.rs, ProposerBlockCounts
GetTokenPreProgrammedDistributionsRequest	token_queries/token_pre_programmed_distributions/v0	proof/token_pre_programmed_distributions.rs
GetGroupInfosRequest	group_queries/group_infos/v0	proof/groups.rs, Groups
GetGroupActionsRequest	group_queries/group_actions/v0	proof/groups.rs, GroupActions

The matching FromProof impls passed the request's missing limit (None) to the Drive verify function, so GroveDB verified the proof of a 100-item page against an unlimited range and failed with "Proof is missing data for query range". Results of 100 or fewer were unaffected, which is why the existing tests and SDK test vectors never hit it.

The default page is node configuration (DriveConfig.default_query_limit), not protocol. Verifying a missing limit only as 100 would turn a node with a larger default, say 200, into a new failure: its complete proof of 150 results verified as no limit before, but checked against 100 it reads as "Proof returns more data than limit". So the verifier accepts either reading.

All four can pass 100 results, so all four are fixed:

• Epoch proposers: one entry per evonode that proposed a block in the epoch. Mainnet has 362 evonodes; on 2026-10-18 an unproved no-limit query of the current epoch returned a full page of 100, and the next page (startAfter the last one) another full 100. Testnet has 73 evonodes, so it cannot reach a full page there yet.
• Pre-programmed distributions: a token's schedule has no entry cap; each entry is about 40 bytes of a contract create transition (20 KiB max), so several hundred fit.
• Groups: a contract's groups have no count cap (validate_groups only checks the positions are contiguous); a group of two members is under 100 bytes, so more than 100 fit in one contract.
• Group actions: one per proposed action of a group, active or closed; nothing caps them.

I found no open PR or issue for these (searched "missing data for query range", "default query limit", "ProposerBlockCounts", "pre-programmed distributions limit", "group infos limit", "group actions limit", "default_query_limit", "proof limit"; only #5483 and #5482 come up).

What was done?

• packages/rs-drive-proof-verifier/src/verify.rs: a crate helper, verify_page_drive_proves(limit, verify), runs a Drive verify function against the page Drive proved. A request's limit is verified as is. A missing limit is verified as DEFAULT_QUERY_LIMIT and, if that is refused, as no limit; when both are refused the error is the standard page's. Either reading only returns proved results: a proof verifying as no limit proves the whole range, and a proof verifying as the default page proves its first page.

• The four verifiers verify through it: ProposerBlockCounts (proof.rs), TokenPreProgrammedDistributions (proof/token_pre_programmed_distributions.rs), Groups and GroupActions (proof/groups.rs). The distributions verifier keeps its start as copyable parts so the start can be rebuilt for each reading.

• Requests the SDK sends are unchanged, so the recorded SDK test vectors still match.

• Unit tests of the helper in verify.rs (verify::tests::verify_page_drive_proves): a named limit, including one above the default, is verified once as is; a missing limit is tried as the default page first, falls back to no limit, and returns the default page's error when both are refused.

• New drive-abci tests (test-only change in drive-abci), one per query, each next to its handler's tests:

  • proposed_block_counts_by_range::v0::tests::should_verify_the_default_page_of_proposers_requested_with_no_limit
  • token_pre_programmed_distributions::v0::tests::should_verify_the_default_page_of_distributions_requested_with_no_limit
  • group_infos::v0::tests::should_verify_the_default_page_of_groups_requested_with_no_count
  • group_actions::v0::tests::should_verify_the_default_page_of_group_actions_requested_with_no_count

  Each runs two nodes (query::tests::NO_LIMIT_PROOF_CASES): one left at the default page of 100 storing 101 results, and one configured with a default of 200 storing 150. It proves the request with no limit through the real handler, checks the proof holds the node's page, then runs the real FromProof with a context provider that refuses quorum keys (NoQuorumKeysContextProvider). FromProof checks the GroveDB proof before the Tenderdash signature, so QuorumKeyUnavailable means the Drive part verified. The shared query::tests helpers gain setup_platform_with_default_query_limit; setup_platform now builds through a common setup_platform_with_config, with the same steps as before.

Relation to #5483

That PR verifies a missing limit only as DEFAULT_QUERY_LIMIT (vote_query_limit_drive_proves in proof.rs) and has the same open review finding about nodes configured with a larger default. verify_page_drive_proves answers it for both: once either PR lands, the five vote verifiers can verify through it. The two PRs touch different lines and merge in either order without conflicts.

Before and after

The same SDK call against mainnet (current epoch, more than 200 proposers):

ProposerBlockCountByRange::fetch_many(&sdk, LimitQuery {
    query: Some(current_epoch_index),
    limit: None,
    start_info: None,
}).await
// before: Err(Proof verification error: grovedb: invalid proof: ... Proof is missing data for query range ...)
// after:  Ok(ProposerBlockCounts({...}))   (100 proposers, the first page)

From a node whose operator set default_query_limit = 200, with 150 groups in a contract:

Group::fetch_many(&sdk, GroupInfosQuery { contract_id, start_group_contract_position: None, limit: None }).await
// before (v5.0-dev): Ok(150 groups)
// first commit of this PR: Err(... Proof returns more data than limit Some(100) ...)
// after:  Ok(150 groups)

Likewise for Group::fetch_many, GroupAction::fetch_many and TokenPreProgrammedDistributions::fetch with limit: None once more than 100 results exist. The C FFI's dash_sdk_evonode_get_proposed_epoch_blocks_by_range with limit = 0 (documented as "Drive's default page") sends no limit, so it failed the same way and works now. Its comment in rs-sdk-ffi/src/evonode/queries/proposed_epoch_blocks_by_range.rs still says a request without a limit fails proof verification; it is left for a separate change, since that crate needs its own code owners' review.

How Has This Been Tested?

• The four drive-abci tests pass for both nodes: cargo test -p drive-abci --lib -- should_verify_the_default_page_of: 4 passed.
• Mutation checks:
  • with the missing limit verified only as DEFAULT_QUERY_LIMIT (no fallback), all four fail at FromProof with GroveDBError on the node configured with 200 ("Proof returns more data than limit Some(100)", or for distributions "V1 proof contains extra lower layer ... not required by query");
  • with the missing limit verified only as no limit (the base branch), all four fail on the node left at 100 ("Proof is missing data for query range", or for distributions "V1 proof is missing lower layer").
• Helper unit tests and the verifier tests of the touched queries: cargo test -p drive-proof-verifier --lib -- verify group pre_programmed proposer u32_to_u16: 67 passed.
• Adjacent drive-abci tests of the four handlers: cargo test -p drive-abci --lib -- query::validator_queries::proposed_block_counts_by_range query::token_queries::token_pre_programmed_distributions query::group_queries::group_infos query::group_queries::group_actions: 75 passed.
• All drive-abci query tests, since the shared setup_platform helper changed: cargo test -p drive-abci --lib -- query::: 807 passed, 1 ignored (already #[ignore]).
• SDK offline test vectors, which replay recorded and signed responses, including no-limit requests for group infos, group actions and pre-programmed distributions: cargo test -p dash-sdk --test main -- group_actions token_pre_programmed: 9 passed. (There is no recorded vector for proposers by range.)
• cargo clippy -p drive-proof-verifier -p drive-abci --lib --tests clean; cargo fmt --all -- --check clean.
• git merge-tree of this branch with fix(sdk): verify no-limit vote queries against the page Drive proves #5483's branch: clean.
• Live mainnet check, 2026-10-18 (read-only, unproved getEvonodesProposedEpochBlocksByRange with grpcurl against two evonodes): no limit returns a full page of 100, and the next page another 100, so the proved no-limit query exceeds Drive's page there. I did not run the proved query against mainnet; the drive-abci test covers the verification.

Breaking Changes

None. No public API or request changes; only how the client checks the proofs of these four no-limit queries.

Checklist:

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

For repository code-owners and collaborators only

• I have assigned this pull request to a milestone

🤖 Generated with Claude Code

PR Hygiene · a9c5fe3

• Bots — coderabbitai not yet · thepastaclaw not yet — /skip-bots proceeds without the ones not yet reported
• Self-review — post /self-reviewed
• Build running
• Approvals — you own every area touched; none needed

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.

Summary by CodeRabbit

• Bug Fixes

  • Proof verification now applies Drive’s default page size when a request omits a limit, keeping verification consistent with the results returned for group, token distribution, and proposer-range queries.
  • Added regression coverage for default-sized pages and proof verification across these queries.

• Documentation

  • Clarified how query limits affect page sizes and proof verification.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Repository: dashpay/platform/.coderabbit.yaml
• Review profile: CHILL
• Plan: Advanced
• Run ID: 301e1e95-f0cc-41cb-af05-882c08ff9323

📥 Commits

Reviewing files that changed from the base of the PR and between ea16eb9 and adfbd38.

📒 Files selected for processing: 10

• packages/rs-drive-abci/src/query/group_queries/group_actions/v0/mod.rs
• packages/rs-drive-abci/src/query/group_queries/group_infos/v0/mod.rs
• packages/rs-drive-abci/src/query/mod.rs
• packages/rs-drive-abci/src/query/token_queries/token_pre_programmed_distributions/v0/mod.rs
• packages/rs-drive-abci/src/query/validator_queries/proposed_block_counts_by_range/v0/mod.rs
• packages/rs-drive-proof-verifier/src/proof.rs
• packages/rs-drive-proof-verifier/src/proof/groups.rs
• packages/rs-drive-proof-verifier/src/proof/token_pre_programmed_distributions.rs
• packages/rs-drive-proof-verifier/src/verify.rs
• packages/rs-sdk-ffi/src/evonode/queries/proposed_epoch_blocks_by_range.rs

Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review.

📝 Walkthrough

Proof verifiers now use Drive’s default query limit when a proved query omits a limit. New Drive ABCI regression tests cover group actions, group info, token distributions, and proposer counts. SDK comments clarify how the requested limit relates to Drive’s page size.

Changes: Query proof limits

Layer / File(s)	Summary
Default-limit proof verification packages/rs-drive-proof-verifier/src/verify.rs, packages/rs-drive-proof-verifier/src/proof.rs, packages/rs-drive-proof-verifier/src/proof/groups.rs, packages/rs-drive-proof-verifier/src/proof/token_pre_programmed_distributions.rs, packages/rs-sdk-ffi/src/evonode/queries/proposed_epoch_blocks_by_range.rs	limit_drive_proves returns the supplied limit or DEFAULT_QUERY_LIMIT when no limit is supplied. Group, distribution, and proposer proof verification use that result. SDK comments describe that the request carries the limit and that 0 selects Drive’s default page.
Default-page regression tests packages/rs-drive-abci/src/query/mod.rs, packages/rs-drive-abci/src/query/group_queries/group_actions/v0/mod.rs, packages/rs-drive-abci/src/query/group_queries/group_infos/v0/mod.rs, packages/rs-drive-abci/src/query/token_queries/token_pre_programmed_distributions/v0/mod.rs, packages/rs-drive-abci/src/query/validator_queries/proposed_block_counts_by_range/v0/mod.rs	Tests create more results than the default page size. They check that proofs verify with DEFAULT_QUERY_LIMIT and fail when checked without a limit. They also check Drive proof processing through the expected missing-quorum-key error.

Priority: ➖ Normal

Estimated code review effort: 3 (Moderate) | ~25 minutes

Change: Bug fix · Severity of issue fixed: Medium

Suggested reviewers: shumkov

Merge Risk: ⚪ Minimal · up to adfbd

No merge-blocking issue was established. Proof verification should now match the standard default page; nodes using a different page size may still need an explicit limit.

Pre-merge checks: 2 · 3

Failed checks: 3 warnings

Check name	Status	Explanation	Resolution
Linked Issues check		Direct issue #5483 requires the five proved vote-query verifiers to use DEFAULT_QUERY_LIMIT when the request has no limit. The reviewed changes add limit_drive_proves and apply it to proposer bloc…	Implement the #5483 changes for all five vote-query verifiers, including regression coverage for a full default page, or link this PR to an issue whose coding requirements cover these four follow-up query families.
Out of Scope Changes check		The direct linked issue #5483 scopes its work to five vote queries and explicitly leaves proposer block counts, token pre-programmed distributions, group infos, and group actions for a follow-up. This…	Remove the four follow-up query changes from this PR and submit them under an appropriate linked issue, or update the linked issue and scope so these changes are explicitly included.
Docstring Coverage		Docstring coverage is 56.52% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 23 functions across 10 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

Passed checks: 2 passed

Check name	Status	Explanation
Description Check		Check skipped - CodeRabbit’s high-level summary is enabled.
Title check		The title clearly summarizes the main change: SDK verification now checks no-limit proposer, distribution, and group queries against the page that Drive proves.

Full details: Linked Issues check

Explanation

Direct issue #5483 requires the five proved vote-query verifiers to use DEFAULT_QUERY_LIMIT when the request has no limit. The reviewed changes add limit_drive_proves and apply it to proposer block counts, token pre-programmed distributions, groups, and group actions. The diff does not implement the five vote-query changes required by #5483. The issue itself identifies these four query families as follow-up work.

Resolution

Implement the #5483 changes for all five vote-query verifiers, including regression coverage for a full default page, or link this PR to an issue whose coding requirements cover these four follow-up query families.

Full details: Out of Scope Changes check

Explanation

The direct linked issue #5483 scopes its work to five vote queries and explicitly leaves proposer block counts, token pre-programmed distributions, group infos, and group actions for a follow-up. This PR changes those four excluded families, as shown by the verifier changes in proof.rs, proof/groups.rs, proof/token_pre_programmed_distributions.rs, and the new limit_drive_proves helper.

Resolution

Remove the four follow-up query changes from this PR and submit them under an appropriate linked issue, or update the linked issue and scope so these changes are explicitly included.

• Fix all pre-merge checks with AI

✨ Finishing Touches: 💡 1

📝 Generate docstrings: 💡

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

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

⏹️ Not reviewed — PR is closed (merged) (commit a9c5fe3)

[thepastaclaw]

Final validation — Phase 1 + Phase 2

The changes align all four verifiers with standard 100-result server pages, but introduce a compatibility regression for previously valid complete responses from nodes configured with larger defaults. Static verification against the exact head and pinned GroveDB source confirms one blocker; focused helper-level test coverage is also missing. Current CI reports successful Rust workspace tests and SDK builds, with only PR Hygiene pending; no builds or tests were run locally.

🔴 1 blocking | 🟡 1 suggestion(s)

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

🟡 Suggestion: Add direct unit test coverage for limit_drive_proves in rs-drive-proof-verifier
packages/rs-drive-proof-verifier/src/verify.rs:739-740

The four new handler-to-FromProof regressions exercise omitted limits, but do not exercise this helper's explicit-limit passthrough behavior. Add a focused test in the existing verify.rs unit-test module covering None and representative explicit limits, including a value above DEFAULT_QUERY_LIMIT. This gives the verifier crate's standalone tests coverage of both branches and protects explicitly requested page sizes from being normalized accidentally.

_{source: gemini-3.8-flash-high (phase1-reviewer: rust-quality)}

Review provenance

Source: reviewer 1: gemini-3.8-flash-high (agent: phase1-reviewer, role: general); reviewer 2: gemini-3.8-flash-high (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); final verifier: gpt-6.1-sol (agent: sol-verifier, role: final-verifier)

• Triage: low by gpt-6.1-sol (effort low) — The behavioral change is a small, shared default-limit substitution in four client-side proof verifiers, with most of the diff devoted to regression tests and no consensus or FFI behavior changes.
• Phase 1 reviewers: gemini-3.8-flash-high — general (completed, effort high); agent phase1-reviewer, gemini-3.8-flash-high — rust-quality (completed, effort high); agent phase1-reviewer
• Phase 1 model: gemini-3.8-flash-high — antigravity quota: weekly 71% left, 5h 100% left
• Fresh verifier: gpt-6.1-sol — final-verifier; agent sol-verifier
• Phase 2 reviewers: gpt-6.1-sol — general (completed, effort medium); agent phase2-reviewer, gpt-6.1-sol — architecture-layering (completed, effort medium); agent phase2-reviewer, gpt-6.1-sol — platform-versioning (completed, effort medium); agent phase2-reviewer, gpt-6.1-sol — rust-quality (completed, effort medium); agent phase2-reviewer, gpt-6.1-sol — security-auditor (completed, effort medium); 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-proof-verifier/src/verify.rs`:
- [BLOCKING] packages/rs-drive-proof-verifier/src/verify.rs:17-22: Preserve complete responses from nodes with a larger default
  Unconditionally converting an omitted limit to 100 rejects responses that verified successfully before this change. For example, configure `DriveConfig.default_query_limit = 200` and store 150 epoch proposers. The handler accepts the omitted limit and generates a proof containing all 150 entries. Previously, `ProposerQueryType::ByRange(None, ...)` verified that complete range; this helper now supplies `Some(100)`, and the pinned GroveDB Merk verifier rejects the additional matching entries with `Proof returns more data than limit` (`merk/src/proofs/query/verify.rs`, lines 471–477). The handlers read the configurable default directly, so this is a supported configuration, not an invalid request. The PR's acknowledged limitation therefore does not merely preserve existing failures: complete responses containing more than 100 entries newly fail. Preserve unlimited verification for complete omitted-limit responses while also accepting the standard default page—for example, attempt strict unlimited verification first and use strict default-page verification as a fallback only for omitted limits. Add a regression with a configured default of 200 and 150 results.
- [SUGGESTION] packages/rs-drive-proof-verifier/src/verify.rs:739-740: Add direct unit test coverage for `limit_drive_proves` in `rs-drive-proof-verifier`
  The four new handler-to-FromProof regressions exercise omitted limits, but do not exercise this helper's explicit-limit passthrough behavior. Add a focused test in the existing `verify.rs` unit-test module covering `None` and representative explicit limits, including a value above `DEFAULT_QUERY_LIMIT`. This gives the verifier crate's standalone tests coverage of both branches and protects explicitly requested page sizes from being normalized accidentally.

[github-actions]

Your move: thepastaclaw requested changes on this head; dismiss the review or push a fix; thepastaclaw left review threads unresolved; resolve them.
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.