build: make the workspace lockfile vendorable again

[PastaPastaPasta]

Issue being fixed or feature implemented

Dash Core builds Platform offline from a vendored workspace. Its bundle script runs cargo vendor --locked. That has failed on v5.1-dev since #5307 ("chore(platform)!: update rust-dashcore (incl secp256k1 0.33)"):

found duplicate version of package `base58ck v0.5.0` vendored from two sources:
	source 1: registry `crates-io`
	source 2: https://github.com/rust-bitcoin/rust-bitcoin?rev=7ba35c7c1dd63892bfb9c9395bbd80e2ab5df516#7ba35c7c

The rust-dashcore pin from that PR (90359ed5) takes bitcoin-crypto from rust-bitcoin rev 7ba35c7c. It does so because the crates.io release of bitcoin-crypto 0.3.0 needs secp256k1 0.32, not 0.33. That rev carries base58ck 0.5.0, bitcoin_hashes 1.2.0, bitcoin-internals 0.7.0 and bitcoin-units 0.5.0. Base-sdk (dash-pkc, dash-num, dash-types) and rust-dashcore's own dashcore-crypto take the same versions from crates.io. Cargo cannot put one name and version from two sources into a single directory source, so vendoring fails. This undoes #4631, which made the lockfile vendorable on purpose.

Neither upstream has aligned yet. rust-dashcore's default branch and base-sdk's HEAD still have the split, so bumping a pin doesn't help.

What was done?

• Added a root [patch.crates-io] that points the four crates at the same rust-bitcoin rev as bitcoin-crypto, so each has one source again.
• Regenerated Cargo.lock. Entries are only removed, never added:
  • the crates.io copies of the four crates;
  • bitcoin-internals 0.5.0 and hex-conservative 0.3.2, which only the crates.io bitcoin-units used.
• The comment says the rev must stay equal to rust-dashcore's bitcoin-crypto rev. A different rev would add a second git source and bring the failure back.

The reverse patch, mapping the git copies to crates.io, doesn't compile: git bitcoin-primitives 0.103.1 loses encoding::VecDecoder and other items.

What changes in compiled code: dash-pkc and dashcore-crypto now build against the git base58ck and bitcoin_hashes. They only use these, and none of them behave differently:

• Base58CkString::encode_unbounded: same algorithm.
• decode_check: same algorithm. The error enum is restructured but has the same Display.
• sha256, sha256d, ripemd160: only lint attributes differ.
• dash-pkc's WIF zeroization relies on Base58CkString's inline layout, which is identical.
• The only bitcoin_hashes code change is in hkdf, which neither crate uses.
• The git bitcoin-internals 0.7.0 has the same source as the crates.io copy.

The crates.io bitcoin-primitives 0.103.0, behind dash-types' optional bitcoin-primitives feature, is never activated in this workspace. If someone turns that feature on later, it will probably fail to compile against the git bitcoin-units, because the two use different bitcoin-consensus-encoding versions.

[patch] only applies at the workspace root. Crates that depend on Platform by git are unchanged: they still build, and they still can't vendor. The lasting fix is a single source in rust-dashcore; this patch can go once that lands.

Platform has no vendoring check in CI, so none is added. To reproduce:

cargo vendor --locked "$(mktemp -d)/vendor"

It fails on v5.1-dev and succeeds on this branch.

How Has This Been Tested?

Cargo 1.98.1 (the pinned toolchain):

• cargo vendor --locked on the whole workspace:
  • v5.1-dev (5b5daf6): fails with the error above;
  • 6a3f081, the parent of chore(platform)!: update rust-dashcore (incl secp256k1 0.33) #5307: succeeds;
  • 3b5e4a7 (chore(platform)!: update rust-dashcore (incl secp256k1 0.33) #5307): fails;
  • this branch: succeeds.
• cargo check --locked -p dpp --all-features: passes.
• cargo check --locked -p dash-sdk -p platform-wallet -p platform-wallet-ffi -p drive-abci: passes.
• cargo test --locked -p simple-signer -p platform-wallet --lib: 1240 and 6 passed. These include the WIF, address and ECDSA key tests that go through dash-pkc's base58 and hashing.
• The unreleased dash-sdk-cxx branch rebases cleanly onto this one with no lockfile conflict. There, cargo vendor --locked succeeds and cargo check --locked -p dash-sdk-cxx passes.

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

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

• Configuration used: Repository: dashpay/platform/.coderabbit.yaml
• Review profile: CHILL
• Plan: Advanced
• Run ID: 8422297b-ed0d-4f0d-a378-8aee31f2a91a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

• 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 not yet · thepastaclaw ✓. 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]

✅ Final review complete — no blockers (commit 42a2204) · triage: low

[thepastaclaw]

Final validation — Phase 1 + Phase 2

Verified the complete two-file diff at head 42a2204 against the supplied reviewer evidence and cached upstream sources; no actionable in-scope defects were found. The patches use the existing rust-bitcoin revision, and the lockfile removes six registry packages without adding packages or retaining duplicate name/version pairs. This was static verification only: the supplied CI snapshot shows Kotlin checks passing, Rust workspace and wallet tests skipped, and PR Hygiene pending; vendoring and Rust build/test results were not independently reproduced.

Review provenance

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

• Triage: low by gpt-6.1-sol (effort low) — The diff is a small, contained build fix that unifies four dependency sources and removes duplicate lockfile entries without changing application logic.
• Phase 1 reviewers: gemini-3.8-flash-high — general (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 — security-auditor (completed, effort medium); agent phase2-reviewer

[github-actions]

@coderabbitai review

No review for 42a22044 yet, so PR Hygiene is asking once. If nothing arrives, the requirement is dropped for this commit and the pull request is labelled bot-review-skipped.