feat: identity registration with asset-lock proofs

[shumkov]

Issue being fixed or feature implemented

SwiftExampleApp could only create a Platform identity from an existing asset-lock proof — there was no path to register an identity directly from a Core (SPV) wallet balance. This PR adds that flow end-to-end, with ExternalSignable wallets (no root xpriv on the Rust side) and an automatic IS-lock → ChainLock fallback when InstantSend doesn't show up.

Status: validated end-to-end on testnet through Phase 2. Identity successfully registered from Core funds with both IS-lock (3.5 s after broadcast) and ChainLock paths confirmed working. Phase 3 (stuck-asset-lock catch-up, CL-height retry hardening, and 23 post-review fixes) builds cleanly but the latest review-fix sweep has not yet been re-validated live on testnet.

What was done?

End-to-end Core-funded identity registration with no private-key material crossing the FFI boundary, plus follow-on fixes that took it from "compiles" to "works on testnet" and then "recovers from every edge case we found."

Phase 1 — core feature (initial 5 commits):

• rs-dpp + rs-sdk + rs-sdk-ffi (992be090): StateTransition::sign_with_signer<S: key_wallet::signer::Signer>; renamed try_from_identity_with_signer → try_from_identity_with_signer_and_private_key + new try_from_identity_with_signers<IS, AS> sibling; mirror split for top-up; ProtocolError::ExternalSignerError(String); put_to_platform_with_signer / broadcast_request_for_new_identity_with_signer / top_up_identity_with_signer on the SDK side. Rename ripple across rs-sdk-ffi, wasm-sdk, rs-drive-abci, strategy-tests.
• rs-platform-wallet-ffi: MnemonicResolverCoreSigner trampoline (203067259): implements key_wallet::signer::Signer by deferring to a Swift-side MnemonicResolver vtable. Each Core ECDSA call atomically fetches mnemonic → derives key → signs digest → zeroes buffers. No private-key bytes ever leave Swift. Typed MnemonicResolverSignerError.
• rs-platform-wallet refactor (f1a7d1c2): IdentityFunding enum (FromWalletBalance, FromExistingAssetLock, UseAssetLock) replaces the dual IdentityFundingMethod/TopUpFundingMethod pair. L1/L2 merge: single register_identity_with_signer (signer + proof + path + keys_map) + single register_identity_with_funding (funding-source orchestration). IS→CL fallback (180 s) and H3 cleanup-on-success centralized. build_asset_lock_transaction<S: Signer> / create_funded_asset_lock_proof<S: Signer> return (_, DerivationPath) — credit-output privkey no longer leaves the wallet.
• swift-sdk wrappers (9d5e506a): registerIdentityWithFunding(amountDuffs:identityIndex:identityPubkeys:signer:) with internal MnemonicResolver() and withExtendedLifetime so ARC can't release the resolver mid-FFI. ManagedAssetLockManager.buildTransaction / createFundedProof take an external MnemonicResolver. KeychainManager delete-query fix (was using kSecValueData as a filter → errSecDuplicateItem).
• SwiftExampleApp (8a57e882): CreateIdentityView Core-account branch + plan doc.

Phase 2 — end-to-end unblock (after Phase 1 testnet attempt):

• 885a1be3 — fix(platform-wallet-ffi): always enable masternode sync for SPV
  Real root cause for the "tx never IS-locks" symptom. In trusted-SDK mode the app set masternodeSyncEnabled=false, which disabled dash-spv's ChainLockManager + InstantSendManager. The SPV client connected to masternode peers and received CLSig/ISLock P2P messages, but with no manager subscribed, MessageDispatcher dropped them. Removed the FFI knob entirely; hardcoded enable_masternodes = true. Asset-lock proofs are a published platform-wallet feature; the IS/CL subscription is a non-optional dependency.
• 4184a425 — chore: bump rust-dashcore to 5297d61a for chainlock wallet handling
  Picks up feat(key-wallet): add chainlock handling to the wallet rust-dashcore#756 which adds WalletInterface::process_chain_lock, promotes records InBlock → InChainLockedBlock on chainlock arrival, and emits a new WalletEvent::TransactionsChainlocked variant. Without this the chainlock fallback branch of wait_for_proof could never resolve — records were stuck at InBlock(_) forever. Match-arm coverage added in core_bridge + balance_handler for the new variant.
• 3d16a31a — fix(SwiftExampleApp): bump identity funding floor to v1 minimum for 3 keys
  Platform rejected v1 identity-creates funded at the v0 floor (200_000 duffs) because v1's calculate_min_required_fee_v1 adds per-key creation cost. With defaultKeyCount = 3 the real floor is 221_500 duffs (2_000_000 base + 3 × 6_500_000 per-key, all in credits, ÷ 1000 credits/duff). Bumped minIdentityFundingDuffs to 221_500 and defaultCoreFundingDuffs to 250_000.
• 34d702d3 — docs(swift-sdk): mark SPV event-routing follow-up resolved — plan doc resolution note.

Phase 3 — stuck-asset-lock catch-up + retry hardening + post-review cleanup:

The Phase 2 testnet run worked for fresh registrations but exposed a recoverability gap: an asset lock that was broadcast before the app was killed (or that received its IS-lock / chainlock during a session the app was not running) sat at Broadcast forever after relaunch. Resolving that surfaced a chain of issues, each of which became a commit:

• f65e2e4351 fix(platform-wallet): persist chain-lock context promotions to Swift via bridge — Rust-side WalletEvent::TransactionsChainlocked was emitted but the changeset bridge wasn't projecting the per-record InBlock → InChainLockedBlock flip into the PlatformWalletChangeSet Swift consumes. Added chain_lock_promotions to the core changeset and wired the projection.
• d404cd0caf feat(platform-wallet-ffi): restore tx records for unresolved asset locks at load + 5aa9e9ad5f feat(swift-sdk): project tx records for unresolved asset locks into restore entry — at app launch, Swift now hands the funding-tx record (with persisted BlockInfo context) back to Rust as part of the wallet restore entry, so the in-memory transactions() map has something for the chainlock cascade to promote. Without this, restored asset locks at Broadcast had no in-memory record for apply_chain_lock to find, so the cascade silently no-op'd.
• 67f5962012 feat(platform-wallet): background catch-up for stuck asset locks — new fire-and-forget FFI asset_lock_manager_catch_up_blocking + Swift PlatformWalletManager.catchUpStuckAssetLocks that walks every PersistentAssetLock with statusRaw < 2 and spawns Task.detached calls into resume_asset_lock, parked on wait_for_proof. The chain-lock cascade then fires on the next CLSig without any user interaction.

Phase 3.5 — what the in-flight working tree adds on top (this session, not yet split into commits):

After Phase 3's four commits a second round of testnet inspection turned up several deeper issues. Captured here for context; full commit will follow review:

• The actual root cause for "stuck asset lock chore(wallet-lib): upgrade webpack to v.5 #10": PlatformWalletInfo is a wrapper around upstream's ManagedWalletInfo and delegated ~20 WalletInfoInterface methods (network, wallet_id, balance, sync heights, etc.) but silently missed apply_chain_lock and last_applied_chain_lock. Both fell through to the trait's default no-op. Upstream's spawn_chainlock_wallet_dispatch task was calling wallet.write().await.apply_chain_lock(...) for every validated CL, but it was hitting the no-op — metadata.last_applied_chain_lock stayed None, records never got promoted, the cascade never reached wait_for_proof. Two-line fix: delegate both methods.
• CL-height-too-low retry path on identity registration. A wallet that observes a fresh ChainLock locally can race Platform's view of the same height; submitting too early returns InvalidAssetLockProofCoreChainHeightError (consensus code 10506). New submit_with_cl_height_retry helper in registration.rs retries every 15s for 210s (matching mainnet's create-empty-blocks-interval = 3m), bumping PutSettings::user_fee_increase per retry. Tenderdash's mempool caches rejected ST hashes for ~24h on mainnet/testnet (keep-invalid-txs-in-cache = true in dashmate's tenderdash/config.toml.dot), so retries must produce distinct signable bytes to bypass the cache. Critical follow-up: the original wiring was a no-op because broadcast_request_for_new_identity_with_signer hardcoded user_fee_increase = 0 (packages/rs-sdk/src/platform/transition/broadcast_identity.rs:171) — the threading was missing through the trait method. Symmetric fix to both private-key and signer variants now propagates PutSettings::user_fee_increase end-to-end.
• Wallet trust hierarchy made explicit. The retry path no longer queries Platform's self-reported core_chain_locked_height anywhere. That metadata is unproven and a malicious DAPI node could stall us indefinitely. The wallet's last_applied_chain_lock (SPV-verified BLS signature, cryptographic) is the only signal trusted. Removed get_platform_core_chain_locked_height and its call sites; submission is now optimistic and reacts to Platform's deterministic 10506 rejection.
• Wallet-side CL fallback in wait_for_proof — if the per-record context didn't promote (race between SPV's apply_chain_lock and the catch-up task entering wait_for_proof), the fallback uses wallet.last_applied_chain_lock.block_height >= record.height() to build a Chain proof directly. Gated on a chain-id match (wallet.network() == sdk.network) so a misconfigured wallet (network drift / restore from wrong-network backup) can't synthesize a proof on the wrong chain.
• AssetLockStatus::Consumed terminal variant. The previous remove_asset_lock deleted the row from both Rust's in-memory tracked_asset_locks and Swift's PersistentAssetLock table. The deletion broke historical UI lookups: the "Transactions" list couldn't map a consumed funding tx back to its locked amount. New semantics: Rust drops from memory (terminal — no more proof work to do); Swift retains the row at statusRaw = 4 "Consumed" for the lifetime of the wallet. Catch-up scanner and "ready to fund" UI continue to filter < InstantSendLocked so Consumed entries don't generate noise. Renamed the function remove_asset_lock → consume_asset_lock to match.
• PlatformWalletError::FinalityTimeout(OutPoint) — was FinalityTimeout(Txid). The full outpoint now flows from wait_for_proof through resolve_funding_with_is_timeout_fallback directly, eliminating a BTreeMap-iteration-order-dependent find_tracked_unproven_lock helper that could pick the wrong unproven lock when multiple were tracked at the same (funding_type, identity_index).
• Wallet's last-applied chain-lock exposed via FFI. New has_last_applied_chain_lock / last_applied_chain_lock_height / last_applied_chain_lock_block_hash[32] fields on CoreWalletStateFFI; Swift CoreWalletStateSnapshot.lastAppliedChainLockHeight: UInt32? and lastAppliedChainLockBlockHash: Data?. Currently in-memory only — not persisted across app restarts.
• Transaction-list UI for asset-lock rows. Asset-lock txs were reading as "Internal transaction to myself" with +0.00000000 DASH in red. The Rust classifier already labeled them TransactionType::AssetLock but the Swift row picked an icon from direction (which was Internal) and an amount from transaction.netAmount (which is ~0 because the credit output is a self-owned address). Fixed: purple lock icon (lock.fill), displayDirection returns "Asset Lock" / "Asset Unlock" instead of "Internal", row joins PersistentAssetLock.amountDuffs by txid (summing across vouts) and renders the actual L1 DASH burned; falls back to "Asset Lock (amount unknown)" if the linked row is missing. Same treatment in TransactionDetailView.
• Multi-reviewer code audit + 20 of 23 findings addressed. Spawned ce-correctness-reviewer / ce-adversarial-reviewer / ce-maintainability-reviewer / rust-quality-engineer / silent-failure-hunter against the working tree. Findings ranged from "load-bearing CRITICAL" (the user_fee_increase no-op) down to LOW cleanups (stray TODO comment). The 3 deliberately skipped are documented in code comments (FundingResolution refactor: out of scope; saturating_add(1): defensive only inside the budget; #[non_exhaustive] on AssetLockStatus: would force wildcard arms and lose the compile-time signal for new variants).
• Fix for Found-008 (Found-008: LockNotifyHandler::notify_waiters() drops lock events arriving in wait_for_proof's check/await gap (concurrent asset-lock builds stall on FinalityTimeout) #3641): LockNotifyHandler missed-wakeup race in wait_for_proof. The tokio::sync::Notify API has a well-known foot-gun: notify_waiters() only wakes currently-registered waiters and does NOT store a permit. The wait_for_proof loop checks state, then calls lock_notify.notified().await — an IS/CL event arriving in that gap is silently dropped, and the next event never comes for that specific txid, so the wait stalls until FinalityTimeout. Fix uses the canonical Notified::enable() pattern (Option C in my comment on Found-008: LockNotifyHandler::notify_waiters() drops lock events arriving in wait_for_proof's check/await gap (concurrent asset-lock builds stall on FinalityTimeout) #3641 — different from the issue body's Option A/B): arm the future BEFORE the state check, so any subsequent notify_waiters() is captured by the pinned future. ~10 lines per loop site (applied to both wait_for_proof and wait_for_chain_lock), preserves the multi-waiter semantics that notify_one would break, no API change to LockNotifyHandler. Closes Found-008: LockNotifyHandler::notify_waiters() drops lock events arriving in wait_for_proof's check/await gap (concurrent asset-lock builds stall on FinalityTimeout) #3641 (Found-008 / AL-001). The AL-001 e2e regression test in PR test(platform-wallet): e2e framework + full test suite — triage pins, Found-*/PA-* guards, fail-closed persist, Stage-2 merge #3549 will pin the fix once that PR merges.

How Has This Been Tested?

• cargo test --workspace green for rs-dpp / rs-sdk / rs-platform-wallet (124/124 in the lib tests).
• Testnet end-to-end identity registration confirmed working (Phase 2 validation): IS-lock arrived 3.5 s after broadcast; live event tracing showed every wiring channel firing (PlatformEventManager::on_sync_event → LockNotifyHandler → wait_for_proof poll → context flip → InstantAssetLockProof emitted → Platform IdentityCreateTransition accepted).
• Stuck-asset-lock catch-up confirmed working in the working-tree session: slot chore(wallet-lib): upgrade webpack to v.5 #10 (broadcast pre-restart, on-chain txlock=true, 538 confirmations) advanced from statusRaw=1 to statusRaw=3 with a populated proofBytes after the apply_chain_lock delegation fix landed — exactly the cascade described above.
• iOS sim build green after every commit and after every review fix (./build_ios.sh --target sim --profile dev).
• The Phase 3.5 review-fix sweep (CL-height retry path actually threading user_fee_increase, Consumed status persisting, the new FinalityTimeout(OutPoint) shape) has not been re-exercised on testnet yet — the build is green but a follow-up identity registration on a fresh wallet is needed to confirm the retry path now bypasses Tenderdash's hash cache as intended.

Breaking Changes

• Removed masternode_sync_enabled parameter from the platform_wallet_manager_spv_start FFI signature and the corresponding masternodeSyncEnabled field on PlatformSpvStartConfig. Callers must drop the argument. Rationale: asset-lock proof acquisition requires it, so the flag was unsafe to expose. Internal-FFI ABI; the Swift SDK in this repo is the only consumer.
• At the Rust public-API level, the prior try_from_identity_with_signer / try_from_identity methods were renamed to _and_private_key / _with_private_key variants alongside new _with_signer(s) siblings (all internal callers updated in the same commit).
• BroadcastRequestForNewIdentity trait signature change: both broadcast_request_for_new_identity_with_private_key and broadcast_request_for_new_identity_with_signer gained a user_fee_increase: UserFeeIncrease parameter. This is the critical fix that makes the retry path actually function — the old hardcoded 0 produced identical ST hashes across retries and got dedup'd at Tenderdash. External implementors of the trait need to thread the parameter through to IdentityCreateTransition::try_from_identity_with_signer{,s}{,_and_private_key}.
• AssetLockStatus gained a Consumed variant. Exhaustive matches in downstream consumers must add an arm. We intentionally did NOT mark the enum #[non_exhaustive] — every cross-crate match site uses exhaustive arms by design so the compiler catches the next variant addition the same way it caught this one.
• PlatformWalletError::FinalityTimeout(Txid) → FinalityTimeout(OutPoint). The variant payload type changed; consumers pattern-matching the variant need to destructure an OutPoint instead of a Txid. .txid field still accessible via the outpoint.
• tracked_asset_locks map semantics changed. Was: removed on consumption. Now: terminal entries are dropped from the in-memory map but the Swift PersistentAssetLock row is retained with statusRaw=4. Load-path filters Consumed entries so they're never re-added to memory. Consumers reading the in-memory map see only still-actionable locks.
• rust-dashcore rev bump (53130869 → 5297d61a) introduces WalletEvent::TransactionsChainlocked which forces match-arm coverage in downstream consumers of the WalletEvent enum.

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

Summary by CodeRabbit

• New Features

  • Resumable identity registrations with persisted asset-locks, background catch‑up, progress UI, and single‑flight registration coordinator
  • Support for external signer flows (host-backed signing) for transactions, asset-locks, and identity operations

• Improvements

  • ChainLock fallback for InstantSend timeouts and broader ChainLock handling (more reliable finality)
  • SPV startup now enables masternode sync by default for correct asset‑lock proofs
  • Improved asset‑lock/transaction display, “Consumed” state visibility, and storage views

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

📝 Walkthrough

<review_stack_artifact>

</review_stack_artifact>

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/swift/funding-with-asset-lock

[thepastaclaw]

Code Review

Re-review at 9a82020. Multiple prior blockers (catch-up handle retention, SecretKey wipe, Consumed-status persistence, last_applied_chain_lock advance, missed-wakeup race, user_fee_increase threading) are resolved at HEAD. Two real blocking bugs remain: the funded-with-signer FFI silently drops contract_bounds from Swift pubkeys (sibling path decodes them), and the post-submission IS→CL upgrade is unreachable for IdentityFunding::UseAssetLock because upgrade_to_chain_lock_proof requires the outpoint to be in tracked_asset_locks. Two lower-severity FFI-boundary issues persist (sendToAddresses C-string lifetime, asset-lock restore hardcoding account_index=0).

Reviewed commit: 9a82020

🔴 1 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-platform-wallet/src/wallet/identity/network/registration.rs`:
- [BLOCKING] lines 515-540: IS→CL upgrade after Platform rejection is unreachable for IdentityFunding::UseAssetLock
  On `InvalidInstantAssetLockProofSignatureError`, this branch unconditionally calls `self.asset_locks.upgrade_to_chain_lock_proof(&proof_out_point, CL_FALLBACK_TIMEOUT)`. That helper short-circuits at `packages/rs-platform-wallet/src/wallet/asset_lock/sync/proof.rs:168-176` with `PlatformWalletError::AssetLockProofWait("Asset lock {} is not tracked")` whenever the outpoint is absent from `tracked_asset_locks`. The `IdentityFunding::UseAssetLock` arm at line 339 deliberately sets `tracked_out_point: None` (caller owns the lock lifecycle) and never inserts into `tracked_asset_locks`. Net effect: when a caller supplies an externally-managed IS proof that Platform rejects (e.g. quorum rotation), the wallet swallows the original SDK error and surfaces a misleading "is not tracked" failure — the very stale-IS case this fallback was added to handle. The same bug is mirrored in `top_up_identity_with_funding` at lines 710-731. Fix: gate the IS→CL upgrade on `tracked_out_point.is_some()` and re-raise the original `PlatformWalletError::Sdk(e)` for the `UseAssetLock` case, or extend `upgrade_to_chain_lock_proof` to accept an explicit account index for the caller-managed path.

In `packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/PlatformWalletPersistenceHandler.swift`:
- [SUGGESTION] lines 2855-2965: Asset-lock restore buffers hardcode account_index = 0 even though the Rust loader uses it as a lookup key
  Both `buildAssetLockRestoreBuffer` (line 2865) and `buildUnresolvedAssetLockTxRecordBuffer` (line 2965) serialize `entry.account_index = 0`. The inline comment at line 2862-2864 ("The Rust load path doesn't read this field for anything load-bearing") is incorrect: in `packages/rs-platform-wallet-ffi/src/persistence.rs:2324-2336`, `spec.account_index` is stored into `TrackedAssetLock.account_index` AND used as the key in the per-account `BTreeMap`. Likewise `restore_unresolved_asset_lock_tx_records` at `persistence.rs:2739` reinserts funding transactions into `standard_bip44_accounts.get_mut(&rec.account_index)` and drops the row when no matching account exists. The public Swift asset-lock APIs (`buildTransaction`, `createFundedProof`, `sendToAddresses`) all accept arbitrary `accountIndex`, so any wallet funded from a nonzero BIP44 account silently loses crash-recovery for in-flight asset locks at restart. Today's iOS app happens to use account 0 only, which keeps this latent — but `PersistentAssetLock` needs a real `accountIndex` column (mirroring `identityIndexRaw`) before nonzero BIP44 accounts are supported.

In `packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/CoreWallet/ManagedCoreWallet.swift`:
- [SUGGESTION] lines 108-134: sendToAddresses passes C-string pointers backed by bridged-NSString temporaries
  `let cStrings = recipients.map { ($0.address as NSString).utf8String }` produces an array of `UnsafePointer<CChar>?` whose backing UTF-8 buffers are owned by autoreleased `NSString` temporaries created inside the closure — the array retains the pointers, not the NSString owners. Rust immediately dereferences each with `CStr::from_ptr` in `packages/rs-platform-wallet-ffi/src/core_wallet/broadcast.rs`. In practice within a single synchronous non-`@autoreleasepool` function the temporaries live until function exit (no pool drain between `map` and the FFI call), so no concrete misbehavior is reproducible at this SHA. But this is the documented Swift→C anti-pattern: Apple's NSString docs warn that `utf8String` returns memory "automatically freed just as a returned object would be released," any future refactor introducing an `await`, `withCheckedThrowingContinuation`, or nested `@autoreleasepool` between buffer construction and the FFI call invalidates the pointers, and every other FFI buffer in this file already uses owned `strdup`/`free` allocations. Worth tightening because this is a transaction-signing path.

[codecov]

Codecov Report

❌ Patch coverage is 58.84244% with 128 lines in your changes missing coverage. Please review.
✅ Project coverage is 87.84%. Comparing base (cd93b2f) to head (bd2aaad).
⚠️ Report is 11 commits behind head on v3.1-dev.

Files with missing lines	Patch %	Lines
...entity/identity_create_transition/v0/v0_methods.rs	46.15%	28 Missing ⚠️
.../identity/identity_topup_transition/methods/mod.rs	24.32%	28 Missing ⚠️
...identity/identity_create_transition/methods/mod.rs	31.57%	26 Missing ⚠️
...dentity/identity_topup_transition/v0/v0_methods.rs	4.00%	24 Missing ⚠️
packages/rs-dpp/src/state_transition/mod.rs	75.55%	22 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##           v3.1-dev    #3634      +/-   ##
============================================
- Coverage     88.06%   87.84%   -0.23%     
============================================
  Files          2521     2537      +16     
  Lines        308995   311315    +2320     
============================================
+ Hits         272122   273472    +1350     
- Misses        36873    37843     +970     

Components	Coverage Δ
dpp	87.84% <47.10%> (-0.18%)	⬇️
drive	87.03% <ø> (-0.03%)	⬇️
drive-abci	90.05% <100.00%> (ø)
sdk	∅ <ø> (∅)
dapi-client	∅ <ø> (∅)
platform-version	∅ <ø> (∅)
platform-value	92.17% <ø> (ø)
platform-wallet	∅ <ø> (∅)
drive-proof-verifier	53.13% <ø> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

✅ DashSDKFFI.xcframework built for this PR.

• Workflow run: https://github.com/dashpay/platform/actions/runs/26092700260
• Artifacts: DashSDKFFI.xcframework (folder), DashSDKFFI.xcframework.zip, xc_checksum.txt

SwiftPM (host the zip at a stable URL, then use):

.binaryTarget(
  name: "DashSDKFFI",
  url: "https://your.cdn.example/DashSDKFFI.xcframework.zip",
  checksum: "d60065cf853539a5aa7b356a45c5bde0f4d08929c881b1a27e1ae31bc761c0f9"
)

Xcode manual integration:

• Download 'DashSDKFFI.xcframework' artifact from the run link above.
• Drag it into your app target (Frameworks, Libraries & Embedded Content) and set Embed & Sign.
• If using the Swift wrapper package, point its binaryTarget to the xcframework location or add the package and place the xcframework at the expected path.

[thepastaclaw]

Code Review

Verified at 1e3264d. All prior blocking findings remain resolved — contract_bounds decoding on the funded-signer FFI path, removal of the unreachable UseAssetLock variant, Consumed-status persistence via self-queued changeset, accountIndexRaw threading through restore buffers, strdup-owned C-strings in sendToAddresses, per-task ARC retention of the catch-up FFI handle, user_fee_increase threading, and the pinned Notified::enable() pattern for the missed-wakeup race. One real logic gap remains in the Swift Resumable Registrations filter (terminal status=4 Consumed locks leak into the UI after local identity delete, showing a perpetual spinner). Three suggestion-severity items: a duplicate FFI pubkey decoder (already drifted once), a defense-in-depth zeroization gap in derive_priv, and missing test coverage for the new CL-height retry fee-bump loop.

Reviewed commit: 1e3264d

🟡 4 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/swift-sdk/SwiftExampleApp/SwiftExampleApp/Utils/PersistentAssetLockDisplay.swift`:
- [SUGGESTION] line 37: isVisibleAsResumable accepts Consumed (4), leaking terminal locks into Resumable Registrations after a local identity delete
  `isVisibleAsResumable: statusRaw >= 1` has no upper bound, and `IdentitiesContentView.crossWalletResumableLocks` (IdentitiesContentView.swift:304) uses the same `statusRaw >= 1` floor. The new `AssetLockStatus::Consumed = 4` discriminant introduced by this PR is terminal — the inline doc at lines 26–28 even says "Consumed (4) was already used to fund an identity and cannot be reused; the persisted row survives only for historical lookup" — so it should not surface in the resume UI.

In the happy path this is masked by the `(walletId, identityIndex)` anti-join because `PersistentIdentity` claims the slot. But IdentitiesContentView exposes a 'Delete a single identity locally' action (IdentitiesContentView.swift:331+) whose doc-comment explicitly says it does NOT touch the funding `PersistentAssetLock`. After such a delete the slot frees up, the Consumed lock re-enters the cross-wallet list, and the row falls into the `else` branch of `trailingAffordance` (IdentitiesContentView.swift:535–551) because `canFundIdentity` (correctly) rejects status 4 — producing a perpetual `ProgressView` labelled "Waiting for InstantSendLock or ChainLock…" for a lock that can never be resumed. Tapping through would also error out: `resume_asset_lock` rejects Consumed entries with `AssetLockProofWait("Asset lock {} is already Consumed — nothing to resume")`.

The new test `testForwardCompatibleStatusFloor` (CreateIdentityResumableTests.swift:93–100) actively pins the wrong behavior — it asserts `statusRaw=4` surfaces, with a comment treating 4 as a hypothetical future value. Now that 4 IS Consumed, both the filter and the test need updating. Add the same bound to `crossWalletResumableLocks` for consistency.

In `packages/rs-platform-wallet-ffi/src/identity_registration_funded_with_signer.rs`:
- [SUGGESTION] lines 54-110: Duplicate unsafe IdentityPubkeyFFI decoder — sibling registration path already diverged once on contract_bounds
  `decode_identity_pubkeys()` here reconstructs `IdentityPublicKeyV0` with the same field-by-field logic that already exists in `packages/rs-platform-wallet-ffi/src/identity_registration_with_signer.rs:349-379`. The earlier `contract_bounds` regression occurred precisely because one decoder evolved while the other did not — both now call `decode_contract_bounds(...)` but the surrounding row→key construction (KeyType/Purpose/SecurityLevel validation, null-buffer check, `IdentityPublicKeyV0` field mapping) is still duplicated across two unsafe FFI entrypoints. Because semantic drift here silently changes the on-chain meaning of Swift-supplied keys, the safer shape is a single shared decoder helper for `IdentityPubkeyFFI` rows that both entrypoints call, so future field additions cannot land in only one path. The error-surfacing styles differ (`Result<_, PlatformWalletFFIResult>` here vs. `unwrap_result_or_return!` there), but that can be normalized to the `Result` form and `unwrap_result_or_return!`-ed at the single remaining call site.

In `packages/rs-sdk-ffi/src/mnemonic_resolver_core_signer.rs`:
- [SUGGESTION] lines 277-288: derive_priv leaves BIP-32 ExtendedPrivKey SecretKey scalars unwiped in memory
  `derive_priv` builds `master: ExtendedPrivKey` and `derived: ExtendedPrivKey`, each owning a `secp256k1::SecretKey` containing a 32-byte private scalar. `SecretKey` does NOT zeroize on drop in the `secp256k1` crate — that is exactly why `sign_ecdsa`/`public_key` later call `non_secure_erase()` on their reconstructed `secret` before drop. The module doc-comment (lines 39–44) explicitly promises that "Every intermediate that carries key material … is wrapped in Zeroizing and dropped before the method returns," but neither ExtendedPrivKey is wiped — both go out of scope still holding live scalars. The canonical copy is already `Zeroizing<[u8;32]>` and returned to the caller, so this is defense-in-depth divergence rather than a fresh exposure, but it weakens the documented invariant. Calling `non_secure_erase()` on `derived.private_key` and `master.private_key` before they drop (or shadowing them through a local SecretKey you erase explicitly) brings the implementation back in line with the doc.

In `packages/rs-platform-wallet/src/wallet/identity/network/registration.rs`:
- [SUGGESTION] lines 156-215: submit_with_cl_height_retry has no dedicated test pinning the fee-bump behavior
  `submit_with_cl_height_retry()` is load-bearing for crash-free identity registration/top-up under consensus code 10506, and this PR series already regressed it once (`user_fee_increase` was threaded incorrectly before being fixed). The existing tests only pin the timeout discriminator; there is no deterministic unit test that feeds a stub submit closure returning repeated `InvalidAssetLockProofCoreChainHeightError`s and asserts (a) successive attempts receive incremented `PutSettings::user_fee_increase` (hash-cache avoidance depends on this), and (b) the original error surfaces once `CL_HEIGHT_RETRY_BUDGET` is exhausted. The retry logic is entirely local and time-driven, so a paused-Tokio test would be cheap and would directly protect Tenderdash hash-cache avoidance behavior from a future silent regression.

[QuantumExplorer]

Codex review:

I’m Codex. I found a few issues in this PR:

1. [P1] Core-funded registration ignores the account selected in the UI.

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/CreateIdentityView.swift accepts Standard/CoinJoin accounts as selectedCoreAccount and reads that selected account’s live balance, but the submit path calls registerIdentityWithFunding(...) without passing any account identity. The Swift API and FFI also only pass amountDuffs/identityIndex, and the Rust IdentityFunding::FromWalletBalance path then hardcodes account index 0 when calling create_funded_asset_lock_proof(...).

This means selecting BIP32, CoinJoin, or BIP44 account #1 can either fail even though the selected account has funds, or spend from BIP44 #0 instead of the account the UI showed. Please either plumb account type/index through the Swift/FFI/Rust path, or restrict this UI to the actual supported BIP44 #0 funding source.

2. [P2] Wallet deletion leaves persisted asset locks behind.

PlatformWalletPersistenceHandler.deleteWalletData(walletId:) wipes identities, balances, txos, pending inputs, wallet rows, orphan transactions, and sync state, but it never deletes PersistentAssetLock rows. Those rows are scoped by walletId and are restored on wallet load via loadCachedAssetLocksOnQueue, so deleting and reimporting the same wallet can resurrect stale pending/resumable asset-lock state.

Please add a walletId-scoped PersistentAssetLock delete in the wallet deletion path and cover it in WalletDeletionTests.

3. [P2] The new mnemonic resolver signer overstates key-material zeroization.

packages/rs-sdk-ffi/src/mnemonic_resolver_core_signer.rs says every key-carrying intermediate is Zeroizing and that no private key bytes survive the trait-method boundary, but master and derived ExtendedPrivKey values are plain locals. Existing code in signer_simple.rs already notes that ExtendedPrivKey does not zeroize on drop.

Please either scrub/avoid those ExtendedPrivKey copies or narrow the security claim so callers do not rely on a false “no private bytes survive” guarantee.

Checks I ran:

• git diff --check origin/v3.1-dev...HEAD
• cargo test -p rs-sdk-ffi mnemonic_resolver_core_signer --no-default-features
• cargo test -p platform-wallet-ffi restore_unresolved_records --no-default-features

I did not run full CI or Swift/Xcode tests.

[thepastaclaw]

Code Review

Verified at 117f113. All prior blocking issues are resolved. Two convergent suggestion-level concerns persist: the IdentityPubkeyFFI row decoder is still duplicated across two unsafe FFI entrypoints (only decode_contract_bounds was extracted), and the load-bearing submit_with_cl_height_retry helper still lacks a deterministic test despite having regressed once in this PR series. One additional FFI hardening gap: core_wallet_send_to_addresses dereferences nullable inner C-string pointers without checking them — downgraded from Codex's 'blocking' to 'suggestion' since the realistic null source is strdup OOM and Swift is the only known caller, but worth fixing for boundary hygiene.

Reviewed commit: 117f113

🟡 2 suggestion(s)

1 additional finding

🟡 suggestion: core_wallet_send_to_addresses dereferences nullable inner C-string pointers without checking them

packages/rs-platform-wallet-ffi/src/core_wallet/broadcast.rs (lines 77-83)

After the sendToAddresses lifetime fix on the Swift side, cStringStorage is [UnsafeMutablePointer<CChar>?] populated by strdup, which can return NULL on allocation failure. The Rust callee only checks that the outer addresses array pointer is non-null, then immediately calls CStr::from_ptr(addr_ptrs[i]).to_str() for every element. If any inner element is null (strdup OOM, or any other C-ABI caller passing nullable slots), that call is undefined behavior — CStr::from_ptr requires a non-null pointer to a valid NUL-terminated string. This is no longer the original temporary-lifetime bug, but it is still an unchecked nullable-pointer dereference on the Swift→Rust FFI boundary that should return a structured FFI error rather than UB. Add a per-element null check inside the loop returning PlatformWalletFFIResultCode::ErrorNullPointer with the offending index, matching the inner-pointer validation pattern other FFI entrypoints in this crate already use for pubkey_bytes.

🤖 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-ffi/src/identity_registration_funded_with_signer.rs`:
- [SUGGESTION] lines 54-110: IdentityPubkeyFFI row decoder still duplicated across two unsafe FFI entrypoints
  `decode_identity_pubkeys()` here and the inline loop at `identity_registration_with_signer.rs:349-379` both reconstruct `IdentityPublicKeyV0` from a `*const IdentityPubkeyFFI` row with the same field-by-field logic (KeyType/Purpose/SecurityLevel `try_from`, null/empty `pubkey_bytes` check, `BinaryData` wrap, `IdentityPublicKeyV0 { … }` struct literal). Only the `decode_contract_bounds` helper has been factored out — the surrounding decoder body is still two copies of unsafe pointer-deref code. The two sites also use different error-surfacing styles (`Result<_, PlatformWalletFFIResult>` here vs. `unwrap_result_or_return!` there). This PR series has already shipped one regression on exactly this drift channel (`contract_bounds: None` landed in only one of the two sites and silently changed on-chain identity key semantics). A shared `unsafe fn decode_identity_pubkeys(...) -> Result<BTreeMap<u32, IdentityPublicKey>, PlatformWalletFFIResult>` that both entrypoints unwrap through `unwrap_result_or_return!` or `?` closes the divergence vector for future field additions on the FFI surface.

In `packages/rs-platform-wallet-ffi/src/core_wallet/broadcast.rs`:
- [SUGGESTION] lines 77-83: core_wallet_send_to_addresses dereferences nullable inner C-string pointers without checking them
  After the `sendToAddresses` lifetime fix on the Swift side, `cStringStorage` is `[UnsafeMutablePointer<CChar>?]` populated by `strdup`, which can return NULL on allocation failure. The Rust callee only checks that the outer `addresses` array pointer is non-null, then immediately calls `CStr::from_ptr(addr_ptrs[i]).to_str()` for every element. If any inner element is null (strdup OOM, or any other C-ABI caller passing nullable slots), that call is undefined behavior — `CStr::from_ptr` requires a non-null pointer to a valid NUL-terminated string. This is no longer the original temporary-lifetime bug, but it is still an unchecked nullable-pointer dereference on the Swift→Rust FFI boundary that should return a structured FFI error rather than UB. Add a per-element null check inside the loop returning `PlatformWalletFFIResultCode::ErrorNullPointer` with the offending index, matching the inner-pointer validation pattern other FFI entrypoints in this crate already use for `pubkey_bytes`.

[shumkov]

@QuantumExplorer (responding to the Codex review at #3634 (review))

All three findings addressed

P1 (account_index hardcoded) → e9e56f3636 (fix: plumb account_index through new-identity registration)

• IdentityFunding::FromWalletBalance enum gained account_index: u32
• FFI platform_wallet_register_identity_with_funding_signer and Swift registerIdentityWithFunding both gained accountIndex: UInt32
• Top-up sibling helper updated for parity
• CreateIdentityView now threads selectedCoreAccount.accountIndex through to the FFI and restricts the picker to BIP44 standard accounts (CoinJoin / BIP32 are not supported by create_funded_asset_lock_proof on the Rust side yet — documented at the variant + FFI + Swift wrapper layers)

P2 (deleteWalletData leaves PersistentAssetLock) → same commit e9e56f3636 (the two fixes ended up in one commit by accident — see PR thread for details)

• PlatformWalletPersistenceHandler.deleteWalletData(walletId:) now wipes PersistentAssetLock rows scoped to the walletId, placed alongside the existing per-walletId sweeps and ahead of the wallet-row delete
• New test testDeleteWalletDataRemovesAssetLockRowsAndPreservesOtherWallets in WalletDeletionTests.swift covers (a) target wallet's rows wiped, (b) sibling wallet's rows untouched (cross-wallet isolation)

P2 (mnemonic resolver signer zeroization claim) → 04e299f869 (code) + bd2aaad183 (docstring)

• Code wipe was already in: both MnemonicResolverCoreSigner::derive_priv (rs-sdk-ffi) and dash_sdk_sign_with_mnemonic_resolver_and_path (rs-platform-wallet-ffi) take master and derived as mut and call secret.private_key.non_secure_erase() before drop. secp256k1::SecretKey::non_secure_erase is the upstream-blessed primitive for SecretKey wipe; same defense is at the sign-site (per R7 review thread).
• Module-level docstring sharpened to describe the two-tier mechanism explicitly: Zeroizing for byte buffers (mnemonic / seed / derived 32-byte scalar) plus explicit non_secure_erase() for the secp256k1::SecretKey scalars inside the intermediate ExtendedPrivKey values (which have no Drop / Zeroize impl in key-wallet).
• TODO(upstream) notes on each site flag that the proper fix is a Zeroize / ZeroizeOnDrop impl in dashpay/rust-dashcore's key-wallet/src/bip32.rs — until that ships, the local wipes keep the no-residue invariant true.

Let me know if anything still looks off.

[thepastaclaw]

Code Review

Cumulative review at e9e56f3. The latest delta (117f113..e9e56f3) resolves all prior code-quality findings: the IdentityPubkeyFFI decoder was centralized into a shared decode_identity_pubkeys helper, and submit_with_cl_height_retry now has a deterministic paused-tokio test pinning per-retry user_fee_increase bumps and budget-exhaustion error surfacing. The new account_index plumbing through IdentityFunding::FromWalletBalance and the PersistentAssetLock cleanup on wallet deletion are clean. One prior FFI-boundary suggestion is still valid because core_wallet/broadcast.rs is unchanged in this delta: core_wallet_send_to_addresses still dereferences nullable C-string pointers without per-element null checks.

🟡 1 suggestion(s)

1 additional finding(s) omitted (not in diff).

Findings not attached inline (unchanged lines / prior carried-forward findings)

• **[suggestion] packages/rs-platform-wallet-ffi/src/core_wallet/broadcast.rs — core_wallet_send_to_addresses has two unchecked UB paths on the FFI boundary

  Verified at e9e56f3 — file unchanged in this delta. Two distinct UB paths remain in this entrypoint:

1. Outer pointers when count == 0: The check_ptr!(addresses) / check_ptr!(amounts) calls at lines 67-68 are gated behind if count > 0, but lines 74-75 then unconditionally call std::slice::from_raw_parts(addresses, count) and std::slice::from_raw_parts(amounts, count). Per from_raw_parts's contract, the pointer must be non-null and properly aligned even for zero-length slices — a caller passing count == 0 with NULL pointers triggers UB rather than a clean no-op.

2. Inner C-string pointers: The loop at lines 77-78 calls CStr::from_ptr(addr_ptrs[i]).to_str() for every element without a per-element null check. CStr::from_ptr requires a non-null pointer to a valid NUL-terminated string. On the Swift side cStringStorage is [UnsafeMutablePointer<CChar>?] populated by strdup, which can return NULL on allocation failure; any null inner element is UB rather than a structured FFI error.

Other FFI entrypoints in this crate (e.g. the pubkey_bytes and decode_contract_bounds per-row null checks in identity_registration_with_signer.rs) consistently validate inner pointers before dereferencing — this entrypoint is the outlier. Add a null check on each addr_ptrs[i] before CStr::from_ptr, and either ungate the outer pointer checks or skip the from_raw_parts calls entirely when count == 0, returning PlatformWalletFFIResultCode::ErrorNullPointer with the offending index on null.

[thepastaclaw]

Code Review

Verified all findings against the worktree at bd2aaad. The broadcast.rs FFI UB issue (count==0 with NULL pointers triggers UB via from_raw_parts; per-element NULL inner pointers dereferenced unchecked) is real and unchanged. Two additional Codex findings about the mnemonic-resolver signers are valid: both implementations only call non_secure_erase on the success path, so a derive_priv failure leaves the ExtendedPrivKey master scalar resident in memory, contradicting the newly-documented zeroization guarantee.

🟡 3 suggestion(s)

3 additional finding(s) omitted (not in diff).

Findings not attached inline (unchanged lines / prior carried-forward findings)

• **[suggestion] packages/rs-platform-wallet-ffi/src/core_wallet/broadcast.rs — core_wallet_send_to_addresses has two unchecked UB paths at the FFI boundary

  Verified at bd2aaad — file unchanged in this push. Two distinct UB paths remain in this entrypoint:

1. Outer pointers when count == 0: The check_ptr!(addresses) / check_ptr!(amounts) guards at lines 67-68 are gated behind if count > 0, but lines 74-75 unconditionally call std::slice::from_raw_parts(addresses, count) and from_raw_parts(amounts, count). from_raw_parts's safety contract requires the pointer to be non-null and properly aligned even for zero-length slices, so a caller passing count == 0 with NULL pointers triggers UB instead of a clean no-op. Swift withUnsafeBufferPointer on an empty array can return a NULL baseAddress.

2. Inner C-string pointers: The loop at line 78 calls CStr::from_ptr(addr_ptrs[i]).to_str() for every element with no per-element null check. The Swift side populates the array with strdup, which returns NULL on allocation failure; any null inner element is UB rather than a structured FFI error.

Other FFI entrypoints in this crate (e.g. the per-row checks in identity_registration_with_signer.rs) consistently validate inner pointers before dereferencing — this entrypoint is the outlier. Fix: add a per-element null check on addr_ptrs[i] before CStr::from_ptr, and either ungate the outer pointer checks or skip the from_raw_parts calls entirely when count == 0, returning PlatformWalletFFIResultCode::ErrorNullPointer with the offending index on null.

• **[suggestion] packages/rs-sdk-ffi/src/mnemonic_resolver_core_signer.rs — derive_priv skips the ExtendedPrivKey wipe on the derivation error path

  The newly-expanded zeroization doc-comment promises that no private-key bytes survive past this boundary, but derive_priv only honors that on the success path. master is fully initialized at line 294, then master.derive_priv(&secp, path) at lines 296-298 propagates errors with ?. On that error path, master drops immediately without ever reaching the master.private_key.non_secure_erase() / derived.private_key.non_secure_erase() calls at lines 314-315. Because ExtendedPrivKey has no Drop/Zeroize impl (as the comment notes), the master secret scalar is left resident in memory — exactly the residual-secret class the new documentation claims to have closed. The fix is to wipe master.private_key before returning the derivation error.

• **[suggestion] packages/rs-platform-wallet-ffi/src/sign_with_mnemonic_resolver.rs — FFI mnemonic-resolver signer has the same success-only zeroization hole

  The lower-level dash_sdk_sign_with_mnemonic_resolver_and_path mirrors the same pattern as the trait signer. master is initialized at lines 203-206; if master.derive_priv(&secp, &path) at lines 208-210 fails, the early return fail(SIGN_WITH_RESOLVER_ERR_DERIVATION) skips the explicit wipes at lines 222-223 and drops the initialized ExtendedPrivKey without zeroizing its inner SecretKey. Since ExtendedPrivKey has no Drop/Zeroize impl, the master scalar is left in memory on this error path. Both resolver-backed signing implementations need the same fix: wipe master.private_key before returning the derivation error.

Inline posting failed; posted the verified findings in the top-level review body.