feat(platform)!: in, value membership in propertyConstraints rules (PV14)

[QuantumExplorer]

Basic explanation

What this does: A propertyConstraints rule can now check that a number is one of a list of allowed values: { "in": ["fee", [0, 10, 25, 50]] }.

Value: This was already possible as an anyOf of equal comparisons, but that costs 3 nodes per value plus 1. The limit of 32 nodes per rule therefore capped a set at 10 values. in costs one node per value plus 2, so a set can hold up to 30 values, and the rule reads as what it means.

Risks: Low. This changes consensus validation, but only in protocol version 14, which is not on mainnet. It only widens what is accepted: every rule that registered before still registers and evaluates the same way.

Issue being fixed or feature implemented

A fixed set of allowed values is a common rule (fee tiers, lot sizes, integer enums), and the only way to write it hit the node limit at 10 values.

What was done?

Grammar

{ "in": [expression, [value, value, ...]] } is a new condition, next to the comparisons, and it nests under anyOf, allOf and not:

• The first element is any integer expression: a path, ifAbsent or arithmetic.
• The second is two or more integer literals, never paths or expressions, with no two alike. 1 and 1.0 count as alike.
• The expression must read a property, as a comparison must.
• It holds if the expression's value is one of the listed values. A fault in the expression (division by zero, overflow, ...) breaks the rule, as in a comparison.

Before, both of these were refused on registration (the meta-schema didn't know in). Now:

"tieredFee": { "in": ["fee", [0, 10, 25, 50]] },
"wholeOrHalfLots": { "in": [{ "modulo": ["quantity", 10] }, [0, 5]] }

With tieredFee, a fee of 25 is accepted and a fee of 20 is refused with 10422 tieredFee NotMet.

Node cost, before and after, for the same 30-value set:

{ "anyOf": [{ "equal": ["kind", 1] }, { "equal": ["kind", 2] }, ...] }   // 91 nodes: refused
{ "in": ["kind", [1, 2, ...]] }                                          // 32 nodes: registers

Code

• property_constraints/mod.rs: PropertyConstraint::In { operand, values: BTreeSet<i128> }. It is parsed by the new in_values, which refuses duplicate values on every parse, since a set insertion finds them. Two ins listing the same values in another order are the same condition for repeated_condition. Node count is 1 + the operand's nodes + one per value.
• Meta-schema v3: in on the propertyConstraint def (prefixItems of an expression and an integer array with minItems 2 and uniqueItems), plus description updates.
• Docs: v14 note 39, the book, the js-evo-sdk README, and the SystemLimits, DocumentTypeV2 and PROPERTY_CONSTRAINTS docs.

How Has This Been Tested?

• property_constraints/tests.rs:
  • parsing, including an arithmetic operand and float literals;
  • every refusal with its location: shape, too few values, a non-literal value, a fractional value, a duplicate value, reading no property, and an operand error;
  • membership, including an absent operand and a fault in the operand;
  • node count and read kinds, and the order-free repeated_condition match.
• try_from_schema/v3/property_constraints_tests.rs:
  • on both paths, the meta-schema and the parser refuse each malformed shape;
  • an in registers, and its operand must read integer properties;
  • 30 values fit the node limit and 31 are refused, at registration only.
• drive-abci batch/tests/document/property_constraints.rs: the offer fixture gains tieredFee, and should_judge_an_in_against_its_listed_values runs real creates (one refused with 10422, one accepted).
• cargo test -p dpp --lib (4854 passed), cargo test -p drive-abci --lib property_constraints (11 passed), cargo clippy -p dpp --all-features --all-targets -- -D warnings, cargo clippy -p drive-abci --all-targets -- -D warnings.

Breaking Changes

Consensus, protocol version 14 only: contracts may now register rules using in, which earlier 4.2 builds refuse. Meta-schema v3, parse_property_constraints 0 and validate_property_constraints 0 were introduced in protocol version 14, which is not released on mainnet, so they are extended in place. Every declaration valid before parses and evaluates identically.

Rust API: PropertyConstraint gains the In variant.

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 · a3c5d73

• Bots — coderabbitai not yet · thepastaclaw not yet — /skip-bots proceeds without the ones not yet reported
• Self-review — post /self-reviewed once the bots are done
• Within your 5 open PRs — this one is beyond the limit; it waits until one merges
• Build running
• Approvals
  • files with no dedicated owner — you own it
  • js-wasm-sdk (packages/js-evo-sdk/README.md) — shumkov
  • dpp — you own it
  • rs-drive-abci — you own it

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

[coderabbitai]

Warning

Review limit reached

Next included review available in 18 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Repository: dashpay/platform/.coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: af251b2b-4cec-48c1-8cf4-aaa409afd22c

📥 Commits

Reviewing files that changed from the base of the PR and between e8c4d1b and a3c5d73.

📒 Files selected for processing (11)

• book/src/data-model/documents.md
• packages/js-evo-sdk/README.md
• packages/rs-dpp/schema/meta_schemas/document/v3/document-meta.json
• packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v3/property_constraints_tests.rs
• packages/rs-dpp/src/data_contract/document_type/mod.rs
• packages/rs-dpp/src/data_contract/document_type/property_constraints/mod.rs
• packages/rs-dpp/src/data_contract/document_type/property_constraints/tests.rs
• packages/rs-dpp/src/data_contract/document_type/v2/mod.rs
• packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/property_constraints.rs
• packages/rs-platform-version/src/version/system_limits/mod.rs
• packages/rs-platform-version/src/version/v14.rs

---

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]

📖 Book Preview built successfully.

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

Updated at 2026-09-27T07:59:18.648Z

[thepastaclaw]

🕓 Queued for automated review — 4th in line, estimated start in ~25 min (commit a3c5d73)
Estimated review time once started: ~1.0 h (two-phase automated review; median of recent runs).

• Request priority review — click to move this review to the front of the queue.

[QuantumExplorer]

Reviewed