fix: shield asset-lock funding from all funds accounts incl. CoinJoin (#4073)

[bfoss765]

Shields asset-lock funding from all funds accounts: a multi-account funding builder (build_asset_lock_tx_from_all_funding_accounts) that unions spendable UTXOs across BIP44 + CoinJoin + DashPay funds accounts with LargestFirst coin selection, excludes watch-only DashpayExternalAccount UTXOs (a contact's coins the local mnemonic cannot sign), and maps NoUtxosAvailable to the typed asset-lock insufficient-funds error, with regression tests for the router-fix persistence path and the watch-only exclusion.

Re-opens #4074 which was auto-closed when the #3999 base branch was deleted; rebased onto v4.1-dev. The PR's own rust-dashcore router customization stays dropped — v4.1-dev's rust-dashcore pin already carries that fix upstream (rust-dashcore#867), which the ported regression tests confirm against the pin. The platform-side changes in rs-platform-wallet are NOT in v4.1-dev and are all retained; the only conflict was a trivial import union in test_support.rs.

Verified: cargo test -p platform-wallet — 502 tests pass (38 asset-lock).

🤖 Generated with Claude Code

---

Review-response summary (2026-07-21)

• FFI error arm: AssetLockInsufficientFunds now crosses as dedicated code 29 (ErrorAssetLockInsufficientFunds), mapped in Kotlin and Swift, with an FFI-level test pinning the numeric code and verbatim message. The Display text is unchanged from what dash-wallet already matches, so no host breakage; hosts should migrate from substring-matching to the typed code at their convenience. Codes 26–28 are deliberately skipped — they're allocated by the reservation-token errors on the split-build-broadcast branch (feat(kotlin-sdk): split build/broadcast with reservation release for BIP70-style deferred submission #4185); a comment in the enum documents the reservation so the two PRs can't collide.
• Privacy-domain gate: selection now defaults to a single privacy domain (transparent BIP44/BIP32 — the only domain that can supply change without linking, since key-wallet derives change on Standard accounts only). Cross-domain union requires an explicit consent parameter threaded from the builder through the FFI (allow_cross_domain, default false everywhere, including the resume path); refusal is typed code 30 (ErrorAssetLockCrossDomainConsentRequired) carrying transparent/union/required amounts. The identity-funding carve-out is unchanged — consent is ignored there, pinned by test. Round-2 addition: a fee-band shortfall (transparent covers the amount but not amount+fee, union covers it) is reclassified to consent-required at the selection-failure site, so hosts prompt instead of dead-ending; both the fee-band and denied-both-short paths are now tested.
• Reservation-ledger blocker: agreed this belongs upstream in key-wallet — a concrete design for atomic per-owning-account reservation commits (API shape, rollback semantics, platform adoption path) is drafted and will be proposed against rust-dashcore; the platform-side race window remains documented in code until that lands.
• CI: fork PRs skip the Rust suite and we can't push same-repo refs. Local evidence a maintainer can compare: cargo test -p platform-wallet --lib → 506 passed; --features shielded --lib → 636 passed; -p platform-wallet-ffi --lib → 198 passed; clippy clean on all three crates.
• Host coordination note: shielding CoinJoin/DashPay funds now requires allowCrossDomain = true after explicit user opt-in; dash-wallet will need a consent touchpoint before adopting the next AAR.

Summary by CodeRabbit

• New Features

  • Added optional funding-path support for shielded asset-lock funding in the Kotlin and Swift SDKs.
  • Users can select a specific account’s UTXOs; blank paths preserve default funding behavior.
  • Added an optional funding-account field to the Swift example app.

• Bug Fixes

  • Asset-lock insufficient-funds failures now return dedicated errors across supported SDKs.
  • Invalid or malformed funding paths are rejected with parameter errors.

---

Provenance (tracker refs moved from code comments per review)

The build.rs funding-eligibility comments previously carried an internal review-tracking token finding 5b52d9844055 (4 sites). Removed from the comments (rationale text kept); it tracked the watch-only DashpayExternalAccount ownership carve-out now expressed through the privacy-domain map.

C-ABI note

platform_wallet_manager_shielded_fund_from_asset_lock gained a trailing allow_cross_domain: bool parameter — a C-ABI break — and result codes 29/30 (ErrorAssetLockInsufficientFunds / ErrorAssetLockCrossDomainConsentRequired) are added. See packages/rs-platform-wallet-ffi/README.md.

[coderabbitai]

Warning

Review limit reached

@bfoss765, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 53 minutes

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

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 6c4fae99-f1e2-4960-b790-f53549147938

📥 Commits

Reviewing files that changed from the base of the PR and between 346f2cb and 78fac36.

📒 Files selected for processing (2)

• packages/rs-platform-wallet-ffi/README.md
• packages/rs-platform-wallet/src/wallet/asset_lock/build.rs

📝 Walkthrough

Walkthrough

Shielded asset-lock funding now supports an optional BIP32 funding path that restricts UTXO selection to one account. Typed insufficient-funds errors propagate through wallet, FFI, JNI, Kotlin, and Swift APIs. The Swift example app accepts the path for Core funding.

Changes

Asset-lock funding path

Layer / File(s)	Summary
Single-account asset-lock construction packages/rs-platform-wallet/src/wallet/asset_lock/build.rs, packages/rs-platform-wallet/src/test_support.rs	Shielded builds select one signable account, use LargestFirst, exclude watch-only DashPay accounts, release reservations by account, and map shortfalls to typed errors.
Funding-path orchestration packages/rs-platform-wallet/src/wallet/asset_lock/..., packages/rs-platform-wallet/src/wallet/shielded/..., packages/rs-platform-wallet/src/wallet/identity/...	The optional derivation path is forwarded through fresh shielded funding. Non-shielded and resume flows pass None.
FFI parameter and error propagation packages/rs-platform-wallet-ffi/src/..., packages/rs-platform-wallet/src/error.rs	The native bridge parses optional UTF-8 paths and maps asset-lock insufficient funds to result code 29 while preserving error messages.
Kotlin and Swift SDK integration packages/kotlin-sdk/..., packages/rs-unified-sdk-jni/..., packages/swift-sdk/...	SDK methods accept funding paths, bridges marshal them, and Kotlin and Swift decode the dedicated error. The Swift example app adds a Core funding-path field.

Estimated code review effort: 4 (Complex) | ~60 minutes

Possibly related PRs

• dashpay/platform#4247 — Both PRs add optional BIP32 funding_path support for single-account wallet funding.

Suggested reviewers: shumkov, lklimek, quantumexplorer, llbartekll, zocolini

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title identifies asset-lock funding and CoinJoin, but inaccurately suggests funding from all accounts instead of one selected account.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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]

🕓 Ready for review — 1 ahead in queue (commit 78fac36)
Queue position: 2/11 · 2 reviews active
ETA: start ~21:42 UTC · complete ~21:59 UTC (median 17m across 30 recent reviews; 2 slots)
Queued 2h 56m ago · Last checked: 2026-08-03 21:30 UTC

[bfoss765]

@coderabbitai full review

[coderabbitai]

✅ Action performed

Full review finished.

---

Your plan includes PR reviews subject to rate limits. More reviews will be available in 47 minutes.

[shumkov]

The fix is correct and still reproduces on tip (the #4073 symptom is live in asset_lock/build.rs on v4.1-dev); shielded-only routing with the privacy carve-out for identity funding is the right call. Two must-address items:

• The new AssetLockInsufficientFunds never crosses the FFI: no arm in From<PlatformWalletError> (rs-platform-wallet-ffi/src/error.rs:267-337) so it flattens to ErrorUnknown(99) — the exact complaint in kotlin-sdk: shieldedFundFromAssetLock coin selection only reaches one account (CoinJoin/other-account funds unspendable) #4073 request 3. The message text also changed, which silently breaks dash-wallet's message matching. Please add an FFI code (sibling of ErrorCoreInsufficientFunds = 22) or explicitly scope the FFI mapping as a coordinated follow-up.
• CI ran zero Rust jobs (fork PR — wallet suite, workspace shards, and lint all skipped; the green run only proves the Kotlin/Swift builds). The 38 new tests need an actual CI run — push to a same-repo ref or otherwise force the wallet suite before merge.

Minor: the SwiftExampleApp funding picker still gates on the single BIP44 account, so the UI blocks the exact scenario this fixes (follow-up); the upstream-behavior pin tests (router/gap-limit) will trip on any rust-dashcore pin change — deliberate?; tracker refs ("finding 5b52d9844055") → PR description.

[shumkov]

Two additional architecture blockers after checking the existing comments:

1. Extra-account inputs are reserved in the primary account's ledger, not their owning ledgers. The code documents this limitation around build_asset_lock_tx_from_all_funding_accounts: set_funding(primary) captures one ReservationSet, then add_inputs(extras) records CoinJoin/BIP32 inputs there. Activity built through the source account can therefore reselect the same UTXO before broadcast reconciliation. The safe fix belongs upstream in key-wallet: union selection and per-source-account reservations must commit atomically.
2. The union silently crosses privacy domains. Largest-first can combine ordinary BIP44/BIP32 funds, CoinJoin outputs, and DashPay receiving funds into one L1 transaction, with BIP44 change. That irreversibly links those domains; shielding afterward cannot undo it. Please select within one domain by default and require explicit caller/user consent before cross-domain co-spend.

The existing typed-error and Swift BIP44-only preflight comments are correct and are not duplicated here.

[bfoss765]

Both must-fix items and both architecture blockers are addressed and pushed. AssetLockInsufficientFunds crosses the FFI as dedicated code 29 (we skipped 26–28 — they're taken by #4185's reservation-token errors on the same base; the enum documents the reservation so the PRs can't silently collide on merge), message text unchanged so existing matching keeps working. Selection now defaults to a single privacy domain with an explicit allow_cross_domain consent parameter (default false at every entry point, typed code 30 on refusal, identity carve-out unchanged and pinned by test) — including a reclassification our own review round caught: a fee-band shortfall (transparent covers the amount but not amount+fee while the union covers it) now surfaces as consent-required rather than dead-ending as insufficient funds.

On the reservation-ledger blocker: implemented upstream as you specified — a rust-dashcore key-wallet PR (opening shortly) adds set_funding_multi reserving each selected input in its owning account's ledger, committed atomically post-selection with signing-failure rollback across all ledgers; platform adopts it at the next pin bump, replacing the set_funding + add_inputs composition. On CI: fork PRs skip the Rust suite — local evidence is in the PR description (506/636/198 tests, clippy clean); if you can trigger the wallet suite on a same-repo ref, even better.

[bfoss765]

@coderabbitai full review

[coderabbitai]

✅ Action performed

Full review finished.

---

Your plan includes PR reviews subject to rate limits. More reviews will be available in 35 minutes.

[shumkov]

Consolidated re-verification (two independent passes). The pushed substance checks out: typed codes 29/30 with by-ref mapping so the shielded entry point can't drift, Kotlin mappings + tests, the privacy-domain consent gate is thorough (transparent-vs-union precheck, fee-band reclassification, default-deny at every entry), and filing rust-dashcore#912 for the reservation ledger is the right split. The Rust asset-lock suite passes 8/8 locally. Remaining blockers:

1. Swift does not compile. PlatformWalletResult.swift adds cases 29/30 to the result-code enum and the C-constant mapping, but PlatformWalletError has no matching cases and init(result:) switches over result.code with no default — the switch is now non-exhaustive → compile error. It's currently masked because the Swift CI job dies at the runner's keychain setup before compiling anything. Add the two error cases + mappings and get a real compile run.

2. The multi-account reservation race is now load-bearing. Inputs selected from CoinJoin/BIP32/DashPay accounts are recorded only in the primary BIP44 ledger, so their owning account can concurrently select them — and this PR's whole purpose is to route through those accounts. rust-dashcore#912 is the right fix but hasn't landed. Either hold this until the pin bump adopts it, or get an explicit maintainer sign-off to ship with the documented race.

3. The consent path is unreachable from SwiftExampleApp. ShieldedFundFromAssetLockView.swift still builds the funding picker from BIP44 accounts only and never sets allowCrossDomain, so the advertised all-funds/cross-domain flow cannot be exercised or consented to on iOS (KotlinExampleApp is fine). Needs a consent/retry UI path or an explicitly tracked follow-up.

4. CI has still never run the Rust suite on any head of this PR (fork gate skips wallet tests, workspace shards, and lint). Please get this onto a same-repo ref before merge — the ~500 wallet tests and the Swift fix both need a real CI run.

Minor: the new build.rs comments add three more "finding …" tracker refs (please move to the PR description); the fund-from-asset-lock export gained a parameter — C-ABI break worth a release-note line; the upstream-pin tests (router/gap-limit) living here vs upstream still needs a maintainer decision.

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In
`@packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/ShieldedFundFromAssetLockView.swift`:
- Around line 275-302: Update the canSubmit logic in
ShieldedFundFromAssetLockView so enabling allowCrossDomain no longer requires
the selected BIP44 balance to cover the full lock amount. Permit submission when
cross-domain consent is enabled, while preserving the existing balance
validation when it is disabled and letting Rust perform the authoritative
union-funds check.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 3eef4ea0-742b-45b1-883c-1ec0700a620b

📥 Commits

Reviewing files that changed from the base of the PR and between 8b466ab and e6da504.

📒 Files selected for processing (19)

• packages/kotlin-sdk/sdk/src/main/kotlin/org/dashfoundation/dashsdk/errors/DashSdkError.kt
• packages/kotlin-sdk/sdk/src/main/kotlin/org/dashfoundation/dashsdk/ffi/FundingNative.kt
• packages/kotlin-sdk/sdk/src/main/kotlin/org/dashfoundation/dashsdk/wallet/PlatformWalletManager.kt
• packages/kotlin-sdk/sdk/src/test/kotlin/org/dashfoundation/dashsdk/errors/DashSdkErrorTest.kt
• packages/rs-platform-wallet-ffi/README.md
• packages/rs-platform-wallet-ffi/src/error.rs
• packages/rs-platform-wallet-ffi/src/shielded_send.rs
• packages/rs-platform-wallet/src/error.rs
• packages/rs-platform-wallet/src/lib.rs
• packages/rs-platform-wallet/src/test_support.rs
• packages/rs-platform-wallet/src/wallet/asset_lock/build.rs
• packages/rs-platform-wallet/src/wallet/asset_lock/mod.rs
• packages/rs-platform-wallet/src/wallet/asset_lock/orchestration.rs
• packages/rs-platform-wallet/src/wallet/shielded/fund_from_asset_lock.rs
• packages/rs-platform-wallet/src/wallet/shielded/seed_pool.rs
• packages/rs-unified-sdk-jni/src/funding.rs
• packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/PlatformWalletManagerShieldedFunding.swift
• packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/PlatformWalletResult.swift
• packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/ShieldedFundFromAssetLockView.swift

[bfoss765]

Addressed the independent findings; the reservation race stays held for rust-dashcore#912.

• Swift now compiles — added the two PlatformWalletError cases for codes 29/30 and mapped them in init(result:), making the switch exhaustive (verified with swiftc -typecheck against the cbindgen-generated header — removing the arms reproduces "switch must be exhaustive").
• Cross-domain consent — wired an "Allow cross-domain funds" toggle (default off) into ShieldedFundFromAssetLockView's fresh-build branch so the code-30 gate is reachable/consentable on iOS, plus a tracked TODO for the fuller catch-30/retry dialog.
• Moved the build.rs tracker refs to the description; added a C-ABI release note for the trailing allow_cross_domain parameter.
• Finding 2 (multi-account reservation race): intentionally NOT fixed here — holding this PR for rust-dashcore#912 (atomic per-owning-account ReservationSet commit), then adopting it at the pin bump.
• CI still runs zero Rust jobs on this fork PR; local evidence: asset-lock suite 46/46 (consent group green), FFI 198/198 incl. the 29/30 mapping tests, clippy clean.

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

packages/rs-platform-wallet-ffi/src/shielded_send.rs (1)

1079-1085: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win

Update the stale error-reference comment.

AssetLockCrossDomainConsentRequired is no longer present in PlatformWalletError / the FFI code mapping, so this comment should only cover AssetLockInsufficientFunds and drop the cross-domain consent rationale.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/rs-platform-wallet-ffi/src/shielded_send.rs` around lines 1079 -
1085, The error-preservation comment in the result handling block should no
longer reference AssetLockCrossDomainConsentRequired or cross-domain consent
behavior. Update it to document only preservation of AssetLockInsufficientFunds
as a dedicated FFI error code, while retaining the existing generic-error
distinction and message-prefix rationale.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@packages/rs-platform-wallet/src/wallet/shielded/fund_from_asset_lock.rs`:
- Line 153: Limit shielded asset-lock funding to the primary account until
reservation bookkeeping supports the selected funding_path, or carry that
account/path through every reservation and release operation in the asset-lock
build flow. Update the funding_path handling in the shielded builder and the
reservation logic in build.rs so rejected or concurrent secondary-account builds
cannot reserve, release, or reselect inputs under the primary
BIP44/account-index path.

---

Outside diff comments:
In `@packages/rs-platform-wallet-ffi/src/shielded_send.rs`:
- Around line 1079-1085: The error-preservation comment in the result handling
block should no longer reference AssetLockCrossDomainConsentRequired or
cross-domain consent behavior. Update it to document only preservation of
AssetLockInsufficientFunds as a dedicated FFI error code, while retaining the
existing generic-error distinction and message-prefix rationale.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 850ec629-a6b8-4066-93fd-aafdb3f1dd72

📥 Commits

Reviewing files that changed from the base of the PR and between e6da504 and dfc670d.

📒 Files selected for processing (19)

• packages/kotlin-sdk/sdk/src/main/kotlin/org/dashfoundation/dashsdk/errors/DashSdkError.kt
• packages/kotlin-sdk/sdk/src/main/kotlin/org/dashfoundation/dashsdk/ffi/FundingNative.kt
• packages/kotlin-sdk/sdk/src/main/kotlin/org/dashfoundation/dashsdk/wallet/PlatformWalletManager.kt
• packages/rs-platform-wallet-ffi/src/asset_lock/build.rs
• packages/rs-platform-wallet-ffi/src/error.rs
• packages/rs-platform-wallet-ffi/src/shielded_send.rs
• packages/rs-platform-wallet/src/error.rs
• packages/rs-platform-wallet/src/wallet/asset_lock/build.rs
• packages/rs-platform-wallet/src/wallet/asset_lock/orchestration.rs
• packages/rs-platform-wallet/src/wallet/asset_lock/sync/recovery.rs
• packages/rs-platform-wallet/src/wallet/identity/network/invitation.rs
• packages/rs-platform-wallet/src/wallet/identity/network/registration.rs
• packages/rs-platform-wallet/src/wallet/platform_addresses/fund_from_asset_lock.rs
• packages/rs-platform-wallet/src/wallet/shielded/fund_from_asset_lock.rs
• packages/rs-platform-wallet/src/wallet/shielded/seed_pool.rs
• packages/rs-unified-sdk-jni/src/funding.rs
• packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/PlatformWalletManagerShieldedFunding.swift
• packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/PlatformWalletResult.swift
• packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/ShieldedFundFromAssetLockView.swift

💤 Files with no reviewable changes (3)

• packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/PlatformWalletResult.swift
• packages/kotlin-sdk/sdk/src/main/kotlin/org/dashfoundation/dashsdk/errors/DashSdkError.kt
• packages/rs-platform-wallet-ffi/src/error.rs

[coderabbitai]

🧹 Nitpick comments (1)

packages/rs-platform-wallet-ffi/src/shielded_send.rs (1)

131-164: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

Add unit tests for the two new funding-path parsing gates. Both parse_optional_derivation_path and read_cstring_opt_strict are new validation boundaries for the same money-source parameter (funding_path / fundingPath), and neither has a dedicated test.

• packages/rs-platform-wallet-ffi/src/shielded_send.rs#L131-L164: add tests for parse_optional_derivation_path covering null pointer, zero length, a valid path (e.g. "m/44'/5'/0'"), invalid UTF-8, and a malformed path string.
• packages/rs-unified-sdk-jni/src/funding.rs#L261-L300: add tests for read_cstring_opt_strict covering null string, empty string, a valid path string, and a string with an interior NUL, and confirm it throws (rather than silently returning None) on a genuine JNI read failure.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/rs-platform-wallet-ffi/src/shielded_send.rs` around lines 131 - 164,
Add dedicated unit tests for parse_optional_derivation_path in
packages/rs-platform-wallet-ffi/src/shielded_send.rs (lines 131-164), covering
null pointers, zero length, a valid BIP32 path, invalid UTF-8, and malformed
paths. Add dedicated tests for read_cstring_opt_strict in
packages/rs-unified-sdk-jni/src/funding.rs (lines 261-300), covering null and
empty strings, a valid path, interior NUL rejection, and propagation of genuine
JNI read failures instead of returning None.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@packages/rs-platform-wallet-ffi/src/shielded_send.rs`:
- Around line 131-164: Add dedicated unit tests for
parse_optional_derivation_path in
packages/rs-platform-wallet-ffi/src/shielded_send.rs (lines 131-164), covering
null pointers, zero length, a valid BIP32 path, invalid UTF-8, and malformed
paths. Add dedicated tests for read_cstring_opt_strict in
packages/rs-unified-sdk-jni/src/funding.rs (lines 261-300), covering null and
empty strings, a valid path, interior NUL rejection, and propagation of genuine
JNI read failures instead of returning None.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: aef95731-f83a-43ab-82e2-c555c87398e1

📥 Commits

Reviewing files that changed from the base of the PR and between dfc670d and bd19a3e.

📒 Files selected for processing (21)

• packages/kotlin-sdk/sdk/src/main/kotlin/org/dashfoundation/dashsdk/errors/DashSdkError.kt
• packages/kotlin-sdk/sdk/src/main/kotlin/org/dashfoundation/dashsdk/ffi/FundingNative.kt
• packages/kotlin-sdk/sdk/src/main/kotlin/org/dashfoundation/dashsdk/wallet/PlatformWalletManager.kt
• packages/kotlin-sdk/sdk/src/test/kotlin/org/dashfoundation/dashsdk/errors/DashSdkErrorTest.kt
• packages/rs-platform-wallet-ffi/README.md
• packages/rs-platform-wallet-ffi/src/asset_lock/build.rs
• packages/rs-platform-wallet-ffi/src/error.rs
• packages/rs-platform-wallet-ffi/src/shielded_send.rs
• packages/rs-platform-wallet/src/error.rs
• packages/rs-platform-wallet/src/test_support.rs
• packages/rs-platform-wallet/src/wallet/asset_lock/build.rs
• packages/rs-platform-wallet/src/wallet/asset_lock/orchestration.rs
• packages/rs-platform-wallet/src/wallet/asset_lock/sync/recovery.rs
• packages/rs-platform-wallet/src/wallet/identity/network/invitation.rs
• packages/rs-platform-wallet/src/wallet/identity/network/registration.rs
• packages/rs-platform-wallet/src/wallet/platform_addresses/fund_from_asset_lock.rs
• packages/rs-platform-wallet/src/wallet/shielded/fund_from_asset_lock.rs
• packages/rs-platform-wallet/src/wallet/shielded/seed_pool.rs
• packages/rs-unified-sdk-jni/src/funding.rs
• packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/PlatformWalletManagerShieldedFunding.swift
• packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/PlatformWalletResult.swift

🚧 Files skipped from review as they are similar to previous changes (17)

• packages/rs-platform-wallet-ffi/src/asset_lock/build.rs
• packages/rs-platform-wallet/src/error.rs
• packages/rs-platform-wallet/src/wallet/identity/network/registration.rs
• packages/kotlin-sdk/sdk/src/main/kotlin/org/dashfoundation/dashsdk/errors/DashSdkError.kt
• packages/kotlin-sdk/sdk/src/test/kotlin/org/dashfoundation/dashsdk/errors/DashSdkErrorTest.kt
• packages/rs-platform-wallet/src/wallet/identity/network/invitation.rs
• packages/rs-platform-wallet/src/wallet/platform_addresses/fund_from_asset_lock.rs
• packages/kotlin-sdk/sdk/src/main/kotlin/org/dashfoundation/dashsdk/wallet/PlatformWalletManager.kt
• packages/kotlin-sdk/sdk/src/main/kotlin/org/dashfoundation/dashsdk/ffi/FundingNative.kt
• packages/rs-platform-wallet/src/wallet/shielded/seed_pool.rs
• packages/rs-platform-wallet/src/wallet/asset_lock/sync/recovery.rs
• packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/PlatformWalletManagerShieldedFunding.swift
• packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/PlatformWalletResult.swift
• packages/rs-platform-wallet-ffi/src/error.rs
• packages/rs-platform-wallet/src/wallet/shielded/fund_from_asset_lock.rs
• packages/rs-platform-wallet/src/test_support.rs
• packages/rs-platform-wallet/src/wallet/asset_lock/build.rs

[thepastaclaw]

Preliminary review — Codex only

The latest delta fixes all four indexed prior findings: delegated credit-key callbacks now occur before reservation, the Standard BIP32 xpub regression is exercised, the Swift picker keeps only BIP44 change sinks selectable, and Rust/Swift/Kotlin documentation agrees. The focused asset-lock suite passes 27 tests and the platform-wallet-ffi suite passes 205 tests, but the PR is not mergeable because cargo fmt --check --all fails in the JNI bridge and the exact wallet CI clippy command fails on five PR-added test helpers compiled outside cfg(test). Two additional test-coverage suggestions remain for the prefetched signer's cache-hit invariant and the funding-path parser.

Validated blockers were found in the Codex precheck. Sonnet is deferred until a fresh Codex revalidation clears the blocker gate.

Review provenance

• Codex reviewers: gpt-5.6-sol — general (completed), gpt-5.6-sol — rust-quality (completed), gpt-5.6-sol — ffi-engineer (completed)
• Verifier: gpt-5.6-sol — verifier
• Sonnet: not run (deferred by blocker gate)

🔴 2 blocking | 🟡 2 suggestion(s)

🤖 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-unified-sdk-jni/src/funding.rs`:
- [BLOCKING] packages/rs-unified-sdk-jni/src/funding.rs:415-420: Run rustfmt on the JNI funding-path bridge
  The repository-enforced `cargo fmt --check --all` command fails on this block. This makes the current head fail the wallet and workspace formatting jobs even though the code compiles. Apply rustfmt's replacement before merging.

In `packages/rs-platform-wallet/src/test_support.rs`:
- [BLOCKING] packages/rs-platform-wallet/src/test_support.rs:290-585: Gate the new asset-lock fixtures to test builds
  The exact wallet CI command, `cargo clippy --package platform-wallet --package platform-wallet-storage --package platform-wallet-ffi --package rs-unified-sdk-ffi --package rs-unified-sdk-jni --all-features --locked -- --no-deps -D warnings`, fails with `dead_code` errors for `split_funded_wallet_manager`, `DashpayLeg`, `foreign_contact_account_xpub`, `split_funded_wallet_manager_dashpay`, and `split_funded_wallet_manager_many_coinjoin`. These `pub(crate)` helpers are referenced only by the `#[cfg(test)]` asset-lock module, while `test_support` itself is compiled into the normal library target. Gate these items and their helper-only imports with `#[cfg(test)]` so the production target remains warning-free while unit tests still compile them.

In `packages/rs-platform-wallet/src/wallet/asset_lock/build.rs`:
- [SUGGESTION] packages/rs-platform-wallet/src/wallet/asset_lock/build.rs:2896-2935: Exercise the prefetched signer's post-reservation cache hit
  `CreditKeyFailingSigner` fails its first and every subsequent `public_key` request, so this test exits during the new up-front prefetch before the delegated builder reserves or signs anything. It proves that a prefetch failure is reservation-free, but it does not protect the load-bearing behavior in `PrefetchedCreditKeySigner`: the delegated builder must request exactly the prefetched path and receive it from cache without invoking the underlying signer again. Add a separate signer whose first `public_key` call succeeds and every later call fails, then assert that the delegated build succeeds and the underlying call count is exactly one. That regression would fail if the prefetch and delegated paths diverged or the wrapper accidentally delegated the cached request.

In `packages/rs-platform-wallet-ffi/src/shielded_send.rs`:
- [SUGGESTION] packages/rs-platform-wallet-ffi/src/shielded_send.rs:140-163: Pin the funding-path parser's fail-closed behavior
  `parse_optional_derivation_path` is a new unsafe C-boundary parser for the account that supplies money, but the existing FFI test module never calls it directly. Its absence/error distinction is important: a null pointer or zero length deliberately selects the default BIP44 source, while invalid UTF-8 or malformed path syntax must return `ErrorInvalidParameter` instead of degrading to that default and potentially selecting different coins. Add focused tests for null, zero length, a valid account-level path, invalid UTF-8, and malformed syntax.

[thepastaclaw]

🔴 Blocking: Run rustfmt on the JNI funding-path bridge

The repository-enforced cargo fmt --check --all command fails on this block. This makes the current head fail the wallet and workspace formatting jobs even though the code compiles. Apply rustfmt's replacement before merging.

Suggested change

	let (funding_path_ptr, funding_path_len) = funding_path
	.as_ref()
	.map_or((ptr::null(), 0usize), |c| {
	let b = c.as_bytes();
	(b.as_ptr(), b.len())
	});
	let (funding_path_ptr, funding_path_len) =
	funding_path.as_ref().map_or((ptr::null(), 0usize), |c| {
	let b = c.as_bytes();
	(b.as_ptr(), b.len())
	});

_{source: ['codex']}

[thepastaclaw]

Resolved in 346f2cb — Run rustfmt on the JNI funding-path bridge no longer present.

_{Auto-resolved by the review system based on the latest commit diff. If you believe this was closed in error, reopen the thread.}

[thepastaclaw]

🔴 Blocking: Gate the new asset-lock fixtures to test builds

The exact wallet CI command, cargo clippy --package platform-wallet --package platform-wallet-storage --package platform-wallet-ffi --package rs-unified-sdk-ffi --package rs-unified-sdk-jni --all-features --locked -- --no-deps -D warnings, fails with dead_code errors for split_funded_wallet_manager, DashpayLeg, foreign_contact_account_xpub, split_funded_wallet_manager_dashpay, and split_funded_wallet_manager_many_coinjoin. These pub(crate) helpers are referenced only by the #[cfg(test)] asset-lock module, while test_support itself is compiled into the normal library target. Gate these items and their helper-only imports with #[cfg(test)] so the production target remains warning-free while unit tests still compile them.

_{source: ['codex']}

[thepastaclaw]

Resolved in 346f2cb — Gate the new asset-lock fixtures to test builds no longer present.

_{Auto-resolved by the review system based on the latest commit diff. If you believe this was closed in error, reopen the thread.}

[thepastaclaw]

🟡 Suggestion: Exercise the prefetched signer's post-reservation cache hit

CreditKeyFailingSigner fails its first and every subsequent public_key request, so this test exits during the new up-front prefetch before the delegated builder reserves or signs anything. It proves that a prefetch failure is reservation-free, but it does not protect the load-bearing behavior in PrefetchedCreditKeySigner: the delegated builder must request exactly the prefetched path and receive it from cache without invoking the underlying signer again. Add a separate signer whose first public_key call succeeds and every later call fails, then assert that the delegated build succeeds and the underlying call count is exactly one. That regression would fail if the prefetch and delegated paths diverged or the wrapper accidentally delegated the cached request.

_{source: ['codex']}

[thepastaclaw]

Resolved in 346f2cb — Exercise the prefetched signer's post-reservation cache hit no longer present.

_{Auto-resolved by the review system based on the latest commit diff. If you believe this was closed in error, reopen the thread.}

[thepastaclaw]

🟡 Suggestion: Pin the funding-path parser's fail-closed behavior

parse_optional_derivation_path is a new unsafe C-boundary parser for the account that supplies money, but the existing FFI test module never calls it directly. Its absence/error distinction is important: a null pointer or zero length deliberately selects the default BIP44 source, while invalid UTF-8 or malformed path syntax must return ErrorInvalidParameter instead of degrading to that default and potentially selecting different coins. Add focused tests for null, zero length, a valid account-level path, invalid UTF-8, and malformed syntax.

_{source: ['codex']}

[thepastaclaw]

Resolved in 346f2cb — Pin the funding-path parser's fail-closed behavior no longer present.

_{Auto-resolved by the review system based on the latest commit diff. If you believe this was closed in error, reopen the thread.}

[bfoss765]

Both blockers fixed in 346f2cb, verified locally with the exact CI commands from tests-rs-wallet.yml.

1. cargo fmt --check --all — applied rustfmt's replacement at rs-unified-sdk-jni/src/funding.rs:412. It was the only formatting diff in the workspace; cargo fmt --all -- --check is now clean.

2. Wallet clippy dead_code — reproduced exactly (5 errors, exit 101) and fixed by gating the five fixtures on #[cfg(test)]. The mechanism, for the record: test_support is gated #[cfg(any(test, feature = "test-utils"))], so --all-features compiles it into the normal lib target where cfg(test) is false, leaving pub(crate) helpers with no consumer.

I went with #[cfg(test)] rather than cfg(any(test, feature = "test-utils")) because it matches the convention this file already documents: RejectFirstBroadcaster (test_support.rs:41-45) carries a comment with the identical rationale, and all four mock broadcasters are gated the same way. The feature-gate form is what this crate uses for the pub cross-crate surface.

To confirm this couldn't break the cross-crate test build I checked the actual consumers: the only external one is rs-platform-wallet-ffi/src/core_wallet/broadcast.rs:258, which imports funded_spv_core_wallet and WalletSigner — both pub, both untouched. The five gated items are pub(crate), so they were never reachable from outside the crate.

One addition to the finding: gating the items surfaced a second clippy failure — OutPoint, TxOut, Txid and Utxo became unused in the non-test build. Those are gated too, following the existing #[cfg(test)] use pattern at the top of the file.

Both suggestions implemented. Agreed on the prefetch gap — CreditKeyFailingSigner fails every public_key call, so that test never reaches the wrapper. Added delegated_builder_serves_credit_key_from_prefetch_cache, using a recording signer that answers exactly one request and poisons the rest, asserting the build succeeds, the underlying signer is called exactly once, and the prefetched path equals the credit path the builder returns. Also added the four parse_optional_derivation_path cases.

Verification:

• cargo fmt --all -- --check → clean, exit 0
• wallet clippy job verbatim (--all-features --locked -- --no-deps -D warnings) → Finished dev profile, exit 0
• cargo test -p platform-wallet -p platform-wallet-ffi --all-features → 642 + 219 + 26 + 9 + 6 passed, 0 failed

No error codes touched — ErrorAssetLockInsufficientFunds stays 29.

[bfoss765]

@thepastaclaw the review appears to have stalled — the sticky has read "Stage: Sonnet review + final verification" at 346f2cb460 since 02:50 UTC with an ETA of ~03:01, and no verdict has been posted. Could you re-run at the current head?

For context, 346f2cb460 fixes both blockers from the bd19a3e020 verdict (the cargo fmt diff in rs-unified-sdk-jni/src/funding.rs and the five dead_code clippy errors in test_support.rs), so the last completed verdict is pre-fix.

[bfoss765]

Pushed a new head 59d3dbf — a doc-only commit aligning the new FFI README release-notes bullet with the crate's dominant "behavior" spelling. No code changes vs 346f2cb460, which already fixed both blockers of the prior verdict; the review gate has been stuck mid-"Sonnet review" at that head since 02:50 UTC and did not respond to mentions, so this push is to hand it a fresh head.

@coderabbitai full review

[coderabbitai]

@bfoss765: I will run a full review on the current head 59d3dbf58c.

✅ Action performed

Full review finished.

---

Your included review limit is currently reached under our Fair Usage Limits Policy. This review may still proceed through usage-based billing if eligible. Your next included review will be available in 55 minutes.

[thepastaclaw]

Final validation — Codex + Sonnet

Verified at exact head 59d3dbf: commit 346f2cb fixes both prior CI blockers and both prior coverage suggestions, while 59d3dbf is documentation-only. Workspace formatting, the exact wallet clippy CI command, all 28 shielded asset-lock builder tests, the prefetched-signer regression, and all four funding-path parser regressions pass. One in-scope suggestion remains: the selected-account builder's post-reservation credit-key failure rollback is reachable and important to this PR's reservation lifecycle, but no test exercises it.

Review provenance

• Codex reviewers: gpt-5.6-sol — general (completed), gpt-5.6-sol — rust-quality (completed), gpt-5.6-sol — ffi-engineer (completed)
• Verifier: gpt-5.6-sol — verifier (fallback)
• Sonnet reviewers: claude-sonnet-5 — general (failed), claude-sonnet-5 — rust-quality (failed), claude-sonnet-5 — ffi-engineer (completed), claude-sonnet-5 — general (completed), claude-sonnet-5 — rust-quality (completed)

🟡 1 suggestion(s)

🤖 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-platform-wallet/src/wallet/asset_lock/build.rs`:
- [SUGGESTION] packages/rs-platform-wallet/src/wallet/asset_lock/build.rs:601-689: Exercise selected-account rollback after credit-key failure
  `build_asset_lock_tx_from_selected_account` calls `build_signed` at lines 590-593, which reserves the selected account's inputs, and then performs the external `signer.public_key(&path)` request at lines 621-657. A failure there reaches the path-matched rollback loop at lines 659-689. The existing selected-account tests cover reservation retention and rejected-broadcast release, while `CreditKeyFailingSigner` is used only with `IdentityRegistration`, which follows the non-shielded prefetched builder and fails before reservation. Add a shielded selected-account regression using that signer, then verify a second build can immediately reselect the account's sole UTXO. This directly protects the account-by-`funding_path` rollback introduced by this PR from silently stranding CoinJoin, DashPay-receiving, or explicit BIP32 inputs.

[thepastaclaw]

🟡 Suggestion: Exercise selected-account rollback after credit-key failure

build_asset_lock_tx_from_selected_account calls build_signed at lines 590-593, which reserves the selected account's inputs, and then performs the external signer.public_key(&path) request at lines 621-657. A failure there reaches the path-matched rollback loop at lines 659-689. The existing selected-account tests cover reservation retention and rejected-broadcast release, while CreditKeyFailingSigner is used only with IdentityRegistration, which follows the non-shielded prefetched builder and fails before reservation. Add a shielded selected-account regression using that signer, then verify a second build can immediately reselect the account's sole UTXO. This directly protects the account-by-funding_path rollback introduced by this PR from silently stranding CoinJoin, DashPay-receiving, or explicit BIP32 inputs.

_{source: ['claude']}