feat(platform)!: identifier comparisons in propertyConstraints rules (PV14)

[QuantumExplorer]

Basic explanation

What this does: A propertyConstraints rule can now compare identifier properties (32-byte ids of identities, contracts, tokens or documents). They can be compared with fixed ids written in base58, with each other, or against an allowlist: { "in": ["paymentToken", ["<base58>", "<base58>"]] }. #5042 and #5045 added the same comparisons for strings.

Value: Contracts can now state rules like "payment is only in one of these tokens", "a refund goes back to the payer" or "this reference points at that contract", which were impossible before. Until now, a rule naming an identifier property was refused at registration.

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

Last of the follow-ups listed with the string comparisons (#5042, #5045, #5046).

What was done?

Grammar

These are the same three forms as for strings, with an identifier property's type deciding what a const string means:

• { "equal": ["paymentToken", { "const": "<base58>" }] } or notEqual, with the constant on either side. The constant must decode to exactly 32 bytes, checked at registration.
• { "notEqual": ["buyerId", "sellerId"] }, two bare paths that both name identifier properties.
• { "in": ["paymentToken", ["<base58>", "<base58>"]] }, two or more distinct identifiers.

Before, these were refused on registration with ... reads "paymentToken", which has type identifier, not integer or boolean. Now they register:

"paidInAcceptedToken": {
  "anyOf": [{ "absent": "paymentToken" }, { "in": ["paymentToken", ["<token A>", "<token B>"]] }]
},
"refundGoesToPayer": {
  "anyOf": [{ "absent": "refundTo" }, { "equal": ["refundTo", "payerId"] }]
}

Document	Result
{ "paymentToken": <token B>, "payerId": P, "refundTo": P }	accepted
{ "paymentToken": <token C> }	refused, 10422 paidInAcceptedToken NotMet
{ "payerId": P, "refundTo": Q }	refused, 10422 refundGoesToPayer NotMet

Semantics and checks

• Byte comparison: identifiers compare by their 32 bytes, whatever form the document gives them in (Identifier, Bytes32 or 32 Bytes, the same to_identifier that distinctFrom uses).
• Missing identifiers: an identifier the document leaves out equals no identifier, not even another one it leaves out.
• Equality only: ordering is refused (compares identifiers, which only equal and notEqual do), as is comparing an identifier property with a string property.
• No defaults: an ifAbsent default for an identifier is refused (gives an identifier property a default, which identifiers do not take).
• Wrong type or path: each path must be an identifier property that is not transient. An identifier read as a number gets a hint toward the forms above.
• Node cost: the same as the string forms. A base58 constant has no enum to check against.
• $ownerId is not an operand: the writer's id isn't part of the data the rules read, and distinctFrom already keeps an identifier property apart from the owner. It could be added later by passing the owner id into validate_document_properties.

Code

• property_constraints/mod.rs:
  • IdentifierCompare { comparison, path, value: Identifier }, IdentifierCompareProperties { comparison, left, right } and IdentifierIn { path, values: BTreeSet<Identifier> };
  • PropertyRead::Identifier;
  • the parser's is_string_property predicate becomes property_kind: &dyn Fn(&str) -> Option<EqualityKind> (Text or Identifier), so the property a bare path names decides whether a const or a listed string is text or a base58 identifier;
  • new identifier_comparison, identifier_side, identifier_constant, in_identifier_values and identifier_value.
• try_from_schema/mod.rs: builds property_kind from the parsed types, adds the identifier type check, and adds the hint for an identifier read as a number.
• Meta-schema v3: descriptions only, since base58 constants and listed strings were already valid JSON.
• Docs: v14 note 39, the book, the js-evo-sdk README, and the module, DocumentTypeV2, PROPERTY_CONSTRAINTS and SystemLimits docs.

How Has This Been Tested?

• property_constraints/tests.rs:
  • parsing all three forms, the constant on either side and a nested path;
  • an identifier beside an integer staying an integer comparison;
  • every refusal with its location: ordering, identifier against string, a non-base58 or short constant, a non-string constant, a default, too few, bad or duplicate in values;
  • evaluation across the Identifier, Bytes32 and Bytes forms, other ids, null, a non-identifier value and missing properties;
  • node counts and read kinds.
• try_from_schema/v3/property_constraints_tests.rs (the order schema gains buyerId and sellerId), on both paths:
  • the three forms register;
  • ordering, identifier against string, an identifier read as a number and a bad constant are refused;
  • a transient identifier is refused.
• drive-abci batch/tests/document/property_constraints.rs: the offer fixture gains payerId, refundTo and paymentToken with paidInAcceptedToken and refundGoesToPayer, and should_compare_identifier_properties runs real creates (two refused with 10422, one accepted).
• cargo test -p dpp --lib (4871 passed), cargo test -p drive-abci --lib property_constraints (16 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 comparing identifier properties, which earlier 4.2 builds refuse. 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. A comparison becomes an identifier comparison only when a path it names is an identifier property, and a rule reading one was refused before. A const beside a string property still compares strings.

Rust API: parse_property_constraints's third argument is now property_kind: &dyn Fn(&str) -> Option<EqualityKind> (was is_string_property), and PropertyConstraint gains three variants and PropertyRead one.

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

• 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 56 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: 9b2ab4a2-3485-4b71-a90b-eff5bfe5b9f8

📥 Commits

Reviewing files that changed from the base of the PR and between 3840c2f and d8352a8.

📒 Files selected for processing (12)

• 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/mod.rs
• 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-27T09:36:49.484Z

[thepastaclaw]

🕓 Queued for automated review — 2nd in line, estimated start in ~15 min (commit d8352a8)
Estimated review time once started: ~1.2 h (two-phase automated review; median of recent runs).

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