[QuantumExplorer]

Basic explanation

What this does: when a data contract with tokens is registered, the node creates some storage "folders" for each token. Protocol version 14 added a new kind of token distribution ("once per identity") that needs one more folder. That folder was added inside version 1 of the contract-insert code, which is the version the live network (protocol versions 9 to 13) already runs. Version 2, used by protocol version 14, reached it only by calling version 1. This PR moves the new folder into version 2, where new protocol version 14 behaviour belongs, and leaves version 1 as it shipped.

Value: code that already ran on the network stays as it shipped, which is what keeps a node that syncs from scratch in agreement with everyone else. The contract update path was already fixed the same way in #4834; this finishes the job for inserts.

Risks: Low. Protocol versions 9-13 cannot reach the moved code (they refuse once-per-identity rules before anything is stored), and protocol version 14 queues exactly the same storage operations, just from version 2.

Issue being fixed or feature implemented

book/src/contributing/coding-conventions.md: new behaviour belongs in a new generation selected only by the unreleased protocol version's tables. insert_contract_operations_v1 (protocol versions 9-13) gained add_once_per_identity_distribution in #4827. It is inert there, since validate_once_per_identity_distribution is None at those versions and create/update basic structure v0 refuse V1 distribution rules unpaid, but protocol version 14 capability lived in a shipped generation and the argument sat in another crate with no comment. #4834 moved the parallel edit of update_contract_operations_v1 into a new v2; the insert side was left behind.

What was done?

• insert_contract/v1: removed the once-per-identity branch and its import.
• insert_contract/v2: insert_contract_operations_v2 now adds the claims subtree for every token whose distribution rules carry a once-per-identity distribution, after the generation 1 operations and before the moderation trees.

Before / after (same outcome):

protocol version 14, register a contract whose token has a once-per-identity distribution
before: insert v2 -> insert v1 token loop -> add_once_per_identity_distribution(token)
after:  insert v2 -> insert v1 token loop; then insert v2 -> add_once_per_identity_distribution(token)
        (same subtree under the once-per-identity root, same fee)

protocol versions 9-13
before and after: such a contract is refused in basic structure; v1 never creates the subtree

In-place changes to shipped generations

• insert_contract v1, selected by protocol versions 9-13: the once-per-identity branch is removed. It was unreachable there because those versions refuse once-per-identity distribution rules before the insert runs, so removing it cannot change any outcome at those versions. The rest of v1 differs from v4.1.0 only by the output-identical contract_element_for_insert_v1 extraction from feat(platform)!: once-per-identity token distribution #4827.

How Has This Been Tested?

• cargo test -p drive --lib insert_contract (223 passed)
• cargo test -p drive-abci --lib once_per_identity (11 passed, including registration and claims through state transitions and test_transition_to_version_14_adds_once_per_identity_distributions)
• cargo clippy -p drive --all-features --all-targets -- -D warnings

Breaking Changes

None.

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

• Bots — coderabbitai skipped after its own rate limit · thepastaclaw not yet — /skip-bots proceeds without the ones not yet reported
• Self-review — posted; again after any push
• Within your 5 open PRs
• Build green
• Approvals — you own every area touched; none needed

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

[coderabbitai]

Warning

Review limit reached

Next included review available in 15 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: 5072f92c-8698-4337-be4c-e58abed40328

📥 Commits

Reviewing files that changed from the base of the PR and between 4d4f38d and dbd622c.

📒 Files selected for processing (2)

• packages/rs-drive/src/drive/contract/insert/insert_contract/v1/mod.rs
• packages/rs-drive/src/drive/contract/insert/insert_contract/v2/mod.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.}

[thepastaclaw]

🔍 Review in progress — actively reviewing now (commit dbd622c) · triage: low

[QuantumExplorer]

/self-reviewed