[QuantumExplorer]

Issue being fixed or feature implemented

The iOS app can verify Platform proofs with quorum public keys from its own SPV client instead of relying only on the centralized quorum HTTP service. SDK consumers choose the trust model when they build the SDK: Trusted, strict SPV, or Adaptive (switchable Auto/SPV/Trusted, used by SwiftExampleApp).

Trust root. SPV quorum keys are as trustworthy as dash-spv's checks at Platform's rust-dashcore pin. That pin is c9aeac0d, from v5.1-dev via #5729:

• Headers are checked against Dark Gravity Wave difficulty (feat(dash-spv)!: validate header difficulty against Dark Gravity Wave rust-dashcore#1161). A low-difficulty chain served after the last checkpoint is refused.
• A masternode-list diff is applied only once its merkle proof proves its coinbase in the stored header, and the list it builds hashes to the masternode-list and quorum roots that coinbase commits to (fix(dash-spv)!: verify MnListDiff against its block's coinbase before applying rust-dashcore#1200). This covers single diffs, every diff of a QRInfo, and stored diffs replayed on start.
• A QRInfo refused partway leaves the engine as it was (fix(dash-spv)!: leave the masternode engine untouched by a refused or interrupted QRInfo rust-dashcore#1211).
• The SDK uses only quorums dash-spv marked Verified.

ChainLock anchoring is not part of this trust root. dashpay/rust-dashcore#1309 was closed in favour of DIP 175 quorum proof chains (dashpay/rust-dashcore#1309 (comment)), which are a follow-up (see Follow-ups).

What was done?

Providers (dash-context-provider::routing):

• SpvContextProvider takes quorum keys only from an SPV client and never from the trusted service.
• AdaptiveContextProvider routes each lookup by mode:
  • Auto uses SPV while it is published and synced, and the trusted provider whenever it is not.
  • A missing key is fetched only on the trusted route.
  • It does not forward core_height_verified, because it does not record which source supplied a quorum's key.
• Both read contracts and token configurations from a ContractSource, which has no quorum keys.
• Both report their network to SdkBuilder::build. The adaptive provider also reports its trusted provider's proof requirement, so the builder's provider checks apply to them.
• SpvSourceSlot is where an SPV client publishes its quorum lookups. A client claims it and holds it through a lease, one lease at a time.
• Every "no usable SPV source" outcome is QuorumSourceUnavailable, so the SDK does not ban the node whose proof it could not check.

Local contract cache (rs-sdk-trusted-context-provider):

• The known-contracts and token-configuration part of TrustedHttpContextProvider is now LocalContextResolver. The trusted provider delegates to it.
• System contracts load through the crate's single system_contracts loader, which includes the decision-proposals and token-market contracts from protocol 15.
• The token-market gate holds in the resolver and in the trusted provider, before its fallback provider.

FFI (rs-sdk-ffi):

• dash_sdk_create_trusted, dash_sdk_create_spv and dash_sdk_create_adaptive build the matching provider. Strict SPV never builds the trusted HTTP provider and ignores quorum_url.
• The document FFIs and dash_sdk_add_known_contracts use the SDK's local contract cache, so they work for every kind. Trusted and Adaptive share the trusted provider's cache with proof verification.
• dash_sdk_set_context_provider_mode and dash_sdk_get_context_provider_source drive the adaptive provider.

Wallet (rs-platform-wallet, rs-platform-wallet-ffi):

• platform_wallet_manager_create_with_sdk (with the persistence and event extensions) claims the SDK's slot before it builds the manager. A second manager on the same SDK is refused before it takes the host's callback contexts.

• The manager serves its SPV quorum keys from creation until shutdown or drop.

• The source answers only while all of these hold:

  • sync is running;
  • headers and masternode lists are Synced;
  • the newest masternode list is at most two blocks behind the header tip.

  dash-spv keeps masternode sync Synced when later list updates fail. Without the tip check, a stale list would count as ready and its misses would get honest nodes banned.

• Only quorums dash-spv marked Verified are served. Quorum types that name no LLMQ type are refused.

Swift:

• SDK(network:contextProvider:) defaults to Trusted.
• SDK.quorumSource reads the native provider. SDK.QuorumMode documents each mode.
• PlatformWalletManager.configure(sdk:) creates the manager through create_with_sdk.
• SwiftExampleApp uses Adaptive with an Auto/SPV/Trusted picker. Same-network SDK rebuilds (devnet settings, the Docker toggle) stop SPV and move the wallet manager onto the rebuilt SDK.

Merged with v5.1-dev at 46c26cb05f. This brings in the rust-dashcore pin above, the verified quorum provider (#5523, #5720) and its SDK opt-in (#5721).

• feat(sdk)!: let wasm-sdk and evo-sdk opt into the verified quorum context provider #5721's Sdk::set_context_provider checks now run in SdkBuilder::build, since the provider is fixed at build. Its tests now test the builder.
• The platform-wallet SPV runtime keeps v5.1-dev's adaptations to the new dash-spv API.

How Has This Been Tested?

• Local, mirroring CI's non-shielded phase (cargo test --all-features --locked --lib --bins --tests -- --skip shield, CI's package list and env):
  • 21,808 passed, 0 failed, 70 ignored, across 103 test binaries, at 1655562fbf.
  • The full strategy_tests binary ran, not only the two tests PR CI picks.
• After the readiness fix and the docs commits:
  • platform-wallet, dash-context-provider, rs-sdk-trusted-context-provider (all features): 1,770 + 17 + 150 unit tests passed. The trusted provider's default-feature build: 138 passed.
  • platform-wallet-storage shield-named SQLite tests: 7 passed.
  • wasm-sdk: 217 native tests passed, and 45 wasm32 tests passed under wasm-bindgen-test-runner.
• cargo clippy --all-targets --all-features -- -D warnings, with no warnings, on:
  • dash-context-provider, rs-sdk-trusted-context-provider, dash-sdk, platform-wallet, rs-sdk-ffi, platform-wallet-ffi, dash-platform-balance-checker;
  • the two context-provider crates without features;
  • wasm-sdk for wasm32.
• cargo check --workspace --all-targets.
• Red → green:
  • should_not_be_ready_while_the_masternode_list_trails_the_header_tip;
  • should_forward_provider_requirements_through_every_wrapper;
  • the token-market gate tests in the resolver and in the trusted provider with a fallback, each red with only its own gate removed;
  • the builder refusal tests, red without the build check.
• Also covered by tests:
  • routing by mode and readiness, and fail-closed SPV;
  • no trusted fetch on the SPV route;
  • error classes, and exactly one of concurrent claims succeeding;
  • lease lifetime across manager creation and shutdown;
  • strict SPV building without a quorum service;
  • one contract cache across the trusted, SPV and adaptive providers;
  • the SPV runtime bridge on every Tokio runtime flavor;
  • SDK.quorumSource for a strict SPV SDK (Swift).
• Swift: pasta has no iOS SDK, so the Swift files changed since the last CI run were only syntax-checked (swiftc -parse). The Swift SDK job is the build and test gate.
• Not done: an on-device or simulator pass against a synced testnet node.

Known limits:

• Strict SPV protects quorum keys only. Contracts still come from app storage or earlier fetches.
• An SPV quorum that is not yet Verified is reported as unavailable. A node can name one without being banned.
• Auto's fallback can be forced. Someone who cuts the client off from its SPV peers drops readiness, and Auto then uses the trusted service until SPV is synced again. Auto means the best source available. Clients that must never use the trusted service choose the SPV mode.

Follow-ups:

• Contract registration overwrites newer versions.
• dash_sdk_add_known_contracts accepts system-contract IDs.
• Swift preloads contracts from every network.
• Background (orphan-recovery) managers ignore the quorum mode.
• DIP 175 quorum proof chains (feat(sdk): verify Core quorum proof chains (DIP 175) #5521, feat(sdk): add opt-in verified HTTP context provider #5523, feat(sdk)!: let wasm-sdk and evo-sdk opt into the verified quorum context provider #5721):
  • In Auto, once SPV is not ready, use VerifiedHttpContextProvider before the trusted service, on networks whose relay serves /proofs. Today that is testnet only: mainnet's relay refuses /proofs, and Core v24 is not released.
  • This replaces ChainLock anchoring inside dash-spv, which was dropped in feat(dash-spv)!: trust quorums only below an anchored ChainLock rust-dashcore#1309 (feat(dash-spv)!: trust quorums only below an anchored ChainLock rust-dashcore#1309 (comment)).
  • Forwarding core_height_verified to the source that supplied a key comes with persisting the verified provider's continuation().
• VerifiedHttpContextProvider keeps its own contract and token caches. They duplicate LocalContextResolver and lack its rule that a preload never replaces a newer cached contract. Delegate to the resolver.
• The trusted crate's system-contract activation table is partial. It has no gates for token history and keywords (protocol 9) or document history (13). The full table lives in Drive, behind server, and belongs in dpp.
• Network checks the builder cannot see yet:
  • TrustedHttpContextProvider reports no network();
  • AdaptiveContextProvider::new does not compare its trusted provider's network with its own;
  • the wallet's SPV client network is not checked against the SDK's.
• A quorum the SPV engine marked Invalid reads as missing, so its lookups are charged to the node.

Breaking Changes

None that affect consensus. SDK API changes:

• Removed Sdk::set_context_provider, which v5.1-dev made fallible in feat(sdk)!: let wasm-sdk and evo-sdk opt into the verified quorum context provider #5721. The context provider is fixed at SDK construction, and its network and proof requirement are checked by SdkBuilder::build.
• Sdk::context_provider() now returns Option<Arc<dyn ContextProvider>> instead of Option<impl ContextProvider>.

Checklist:

• I have performed a self-review of my own code
• My Rust, FFI, WASM, Swift or Kotlin changes follow the coding conventions
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have added "!" to the title and described breaking changes in the corresponding section if my code contains any
• I have made corresponding changes to the documentation if needed
• If I added or changed GroveDB structure, I described it in the area's structure.rs, regenerated grovedb-structure.json, and checked the structure viewer link posted on this pull request

🤖 Generated with Claude Code

PR Hygiene · cd8e2c0

• Bots — thepastaclaw 4 threads unresolved — resolve them
• Self-review — post /self-reviewed
• Build failed
• Approvals
  • files with no dedicated owner — you own it
  • rs-platform-wallet-ffi (packages/rs-platform-wallet-ffi/Cargo.toml, packages/rs-platform-wallet-ffi/src/error.rs, packages/rs-platform-wallet-ffi/src/event_handler.rs and 2 more) — HashEngineering or ZocoLini or llbartekll or romchornyi
  • rs-platform-wallet (packages/rs-platform-wallet/Cargo.toml, packages/rs-platform-wallet/src/lib.rs, packages/rs-platform-wallet/src/manager/mod.rs and 3 more) — HashEngineering or ZocoLini or llbartekll or romchornyi
  • rust-sdk-ffi (packages/rs-sdk-ffi/Cargo.toml, packages/rs-sdk-ffi/src/document/create.rs, packages/rs-sdk-ffi/src/document/delete.rs and 11 more) — lklimek or shumkov
  • rust-sdk (packages/rs-sdk/examples/read_contract.rs, packages/rs-sdk/src/sdk.rs, packages/rs-sdk/src/sdk/protocol_gate_tests.rs and 1 more) — lklimek or shumkov
  • swift-sdk (packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/PlatformWalletManager.swift, packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/PlatformWalletResult.swift, packages/swift-sdk/Sources/SwiftDashSDK/SDK.swift and 13 more) — llbartekll or romchornyi

When every merge requirement is met, the PR Hygiene check passes. Reviewer limits do not block merging; other required GitHub checks and protections still apply.

[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.

• Last reviewed commit: 8d2bb27
• Latest commit, not reviewed: cd8e2c0

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

Adds SPV-backed SDK creation using a client handle, introduces Rust quorum resolution through a feature-gated context provider, and adds configurable trusted-quorum fallback behavior to the Swift example app. A specification documents the planned reintegration architecture and validation requirements.

Changes: SPV quorum integration

Layer / File(s)	Summary
SPV context provider and feature wiring packages/rs-platform-wallet/Cargo.toml, packages/rs-platform-wallet/src/lib.rs, packages/rs-platform-wallet/src/spv_context_provider.rs	Adds the feature-gated SpvContextProvider, which resolves quorum keys from a shared masternode-list engine and supplies network activation heights while leaving contract and token lookups empty.
Swift SDK initialization and fallback control packages/swift-sdk/Sources/SwiftDashSDK/SDK.swift, packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/AppState.swift, packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/OptionsView.swift	Adds SPV-handle SDK construction, explicit FFI error handling, persisted trusted-quorum fallback state, SPV handle updates, fallback behavior during initialization and network switching, and a corresponding SwiftUI toggle.
Reintegration specification docs/SPV_CONTEXT_PROVIDER_REINTEGRATION_SPEC.md	Documents the proposed byte-order fix, provider and FFI integration layers, Swift wiring, failure modes, verification plan, and out-of-scope items.

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

Sequence Diagram(s)

sequenceDiagram
  participant AppState
  participant SDK
  participant dash_sdk_create_with_spv_context
  participant SpvContextProvider
  AppState->>SDK: initialize with SPV client handle
  SDK->>dash_sdk_create_with_spv_context: pass network and configured context
  dash_sdk_create_with_spv_context->>SpvContextProvider: resolve quorum public key
  SpvContextProvider-->>dash_sdk_create_with_spv_context: return quorum key or error
  dash_sdk_create_with_spv_context-->>SDK: return SDK handle or error
  SDK-->>AppState: use SPV SDK or trusted fallback

Loading

Possibly related PRs

• dashpay/platform#3644: Updates the Swift SDK’s SPV integration surface in the same SDK.swift area.

Suggested reviewers: shumkov, llbartekll, lklimek, ZocoLini

Pre-merge checks: 4

Check name	Status	Explanation
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.
Description Check		Check skipped - CodeRabbit’s high-level summary is enabled.
Title check		The title "feat(swift-sdk)!: use SPV-synced quorums for Platform proof verification" matches the main change. The PR adds an SPV-based quorum path for Platform proof verification in the Swift SDK, rep…

Full details: Title check

Explanation

The title "feat(swift-sdk)!: use SPV-synced quorums for Platform proof verification" matches the main change. The PR adds an SPV-based quorum path for Platform proof verification in the Swift SDK, replacing the centralized HTTP quorum source. The raw summary and objectives both describe this as the primary change. The title also marks a breaking change with "!", which is consistent with the new SDK initializer and AppState signature changes. The objectives state that no breaking changes are reported against the release base, so the "!" marker is a minor mismatch worth confirming, but it does not make the title unrelated or unclear. The title is 72 characters, which is within a reasonable length for a conventional commit subject.

Finishing Touches

Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/ios-spv-quorums

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

• X
• Mastodon
• Reddit
• LinkedIn

[thepastaclaw]

🕓 Review not started yet because the new head is waiting for the 30-minute push debounce.

• Request normal review — click when the PR is ready for review.
• Request priority review — click to move this review to the front of the queue.

Commit cd8e2c0. Normal review starts when eligible; priority review starts as soon as a slot is available.

[github-actions]

✅ DashSDKFFI.xcframework built for this PR.

• Workflow run: https://github.com/dashpay/platform/actions/runs/23905341422
• 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: "93f085d7f665b623b4cc170feb6c8fc04da6702b601f887c52f8e5181e471994"
)

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.

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/AppState.swift`:
- Around line 45-49: The published property useTrustedQuorumFallback currently
only persists the flag; update its didSet to immediately reapply the SDK
proof-verification mode so the running app reflects the change. After
UserDefaults.standard.set(...), invoke the function that configures the SDK
trust mode (for example the AppState method that initializes or configures the
SDK client—if you have a method like applySDKMode(), reconfigureClient(), or
setTrustedQuorumFallback(on:)), passing the new useTrustedQuorumFallback value;
if no such function exists, call the code path that reconnects or reinitializes
the SDK client so proof verification is updated immediately. Ensure you
reference AppState and useTrustedQuorumFallback when wiring this change.

In `@packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/UnifiedAppState.swift`:
- Around line 126-133: The current network-switch flow lets
walletService.switchNetwork(to:) destroy the SPV client while platformState.sdk
still holds callbacks to the old core handle; update
UnifiedAppState.handleNetworkSwitch to explicitly detach and destroy the old SDK
before tearing down the SPV client: capture the existing platformState.sdk (or
call a teardown method like
platformState.sdk?.destroy()/platformState.clearSDK()), set platformState.sdk =
nil (or call the SDK's close/unbind) on the MainActor to remove callbacks, then
call walletService.switchNetwork(to:) and only after obtaining
walletService.spvClientHandle recreate and assign the new SDK via
platformState.updateSPVClientHandle/new SDK creation — ensuring the old SDK is
fully unbound before SPV teardown.

🪄 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: defaults

Review profile: CHILL

Plan: Pro

Run ID: ed48fb63-d5a9-41ff-b965-9df30eae9aab

📥 Commits

Reviewing files that changed from the base of the PR and between 739754b and f4703d6.

📒 Files selected for processing (7)

• packages/swift-sdk/Sources/SwiftDashSDK/Core/SPV/SPVClient.swift
• packages/swift-sdk/Sources/SwiftDashSDK/Core/SPV/SPVContextProvider.swift
• packages/swift-sdk/Sources/SwiftDashSDK/Core/Services/WalletService.swift
• packages/swift-sdk/Sources/SwiftDashSDK/SDK.swift
• packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/AppState.swift
• packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/UnifiedAppState.swift
• packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/OptionsView.swift

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 64.77%. Comparing base (f7d7c8d) to head (4961a0e).
⚠️ Report is 1369 commits behind head on v5.1-dev.

❗ There is a different number of reports uploaded between BASE (f7d7c8d) and HEAD (4961a0e). Click for more details.

HEAD has 1 upload less than BASE

Flag	BASE (f7d7c8d)	HEAD (4961a0e)
rust	2	1

Additional details and impacted files

@@              Coverage Diff              @@
##           v5.1-dev    #3417       +/-   ##
=============================================
- Coverage     87.40%   64.77%   -22.63%     
=============================================
  Files          2639       24     -2615     
  Lines        333066     2657   -330409     
=============================================
- Hits         291103     1721   -289382     
+ Misses        41963      936    -41027     

Components	Coverage Δ
dpp	∅ <ø> (∅)
drive	∅ <ø> (∅)
drive-abci	∅ <ø> (∅)
sdk	∅ <ø> (∅)
dapi-client	∅ <ø> (∅)
platform-version	∅ <ø> (∅)
platform-value	∅ <ø> (∅)
platform-wallet	∅ <ø> (∅)
drive-proof-verifier	∅ <ø> (∅)

🚀 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.

[coderabbitai]

Actionable comments posted: 4

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@packages/rs-platform-wallet/Cargo.toml`:
- Line 25: The tokio dependency must enable its sync feature for the spv-context
feature and the feature list must use the modern dep: syntax; update Cargo.toml
so the tokio dependency becomes optional with features = ["sync"] (e.g. tokio =
{ version = "1.41", optional = true, features = ["sync"] }) and update the
spv-context feature entry to include "dep:tokio/sync" (instead of the old name)
so spv_context_provider.rs can safely use tokio::sync::RwLock.

In `@packages/rs-platform-wallet/src/spv_context_provider.rs`:
- Around line 115-120: The match that sets `height` currently falls through to
`_ => 0`, silently mapping unsupported `self.network` to 0; replace that
fallback with an explicit error return (e.g., return Err(...) or propagate a
suitable error) so callers are notified of an unsupported Network variant.
Modify the block that computes `height` (the match on `self.network` referencing
`Network::Mainnet`, `Network::Testnet`, `Network::Devnet`) to return a
Result<u64, E> (or use the crate's existing error type) and produce a clear
error for the unsupported branch instead of using 0. Ensure callers of the
enclosing function are updated to handle the Result if necessary.
- Around line 79-80: The call to self.masternode_engine.blocking_read() inside
get_quorum_public_key (which is invoked from async
parse_proof_with_metadata_and_proof) can panic; replace blocking_read() with
try_read() on the Tokio RwLock (self.masternode_engine.try_read()) and handle
the None case gracefully by returning an appropriate error or early failure from
get_quorum_public_key (or falling back to a safe default) instead of unwrapping.
Ensure you reference and use the masternode_lists_around_height result from the
acquired guard when present, and propagate a clear error back to the async proof
verification path so it doesn’t panic.
- Around line 76-77: Validate and reject out-of-range quorum_type before
converting to LLMQType: replace the lossy cast "(quorum_type as u8).into()" with
a fallible conversion using TryInto (e.g., let llmq_type: LLMQType =
(quorum_type.try_into()?) or map the TryInto error to a meaningful error) so
values >255 are handled instead of wrapping; keep
QuorumHash::from_byte_array(quorum_hash) as-is and ensure any error returned
propagates to the caller before using ml.quorums.get(&llmq_type).

🪄 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: defaults

Review profile: CHILL

Plan: Pro

Run ID: 0b462740-73cb-43f3-9a1b-7653a611fe5e

📥 Commits

Reviewing files that changed from the base of the PR and between ad6904a and d9e478e.

⛔ Files ignored due to path filters (1)

• Cargo.lock is excluded by !**/*.lock

📒 Files selected for processing (4)

• packages/rs-platform-wallet/Cargo.toml
• packages/rs-platform-wallet/src/lib.rs
• packages/rs-platform-wallet/src/spv_context_provider.rs
• packages/rs-sdk-ffi/src/spv_context_provider.rs

✅ Files skipped from review due to trivial changes (1)

• packages/rs-platform-wallet/src/lib.rs

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

• packages/rs-sdk-ffi/src/spv_context_provider.rs

[QuantumExplorer]

All review feedback addressed. Additionally, bumped rust-dashcore to 3f65002 which includes the FFIDashSpvClient::masternode_list_engine() accessor (rust-dashcore PR #608). The FFI bridge module (rs-sdk-ffi/src/spv_context_provider.rs) is now deleted — dash_sdk_create_with_spv_context extracts the engine directly and uses the pure-Rust platform_wallet::SpvContextProvider. Zero FFI in the quorum lookup path.

[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/swift-sdk/SwiftExampleApp/SwiftExampleApp/AppState.swift (1)

215-267: ⚠️ Potential issue | 🟠 Major

Make the network switch commit atomically.

The new SPV-first failure paths can throw after the collections are cleared and dataManager.currentNetwork is advanced, but before sdk is replaced. On that path the UI says “new network” while platform calls still go through the old SDK instance. If currentNetwork should also be authoritative, it needs the same success-only commit behavior.

♻️ Possible fix

 func switchNetwork(to network: AppNetwork) async {
     guard let modelContext = modelContext else { return }
-
-    // Clear current data
-    identities.removeAll()
-    contracts.removeAll()
-    documents.removeAll()
-    tokens.removeAll()
-
-    // Update DataManager's current network
-    dataManager?.currentNetwork = network

     // Re-initialize SDK with new network
     do {
         isLoading = true
@@
-        sdk = newSDK
+        identities.removeAll()
+        contracts.removeAll()
+        documents.removeAll()
+        tokens.removeAll()
+        dataManager?.currentNetwork = network
+        sdk = newSDK

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/AppState.swift` around
lines 215 - 267, The switchNetwork method mutates state (clearing
identities/contracts/documents/tokens and advancing dataManager?.currentNetwork)
before potentially failing during SDK creation and load; make the switch atomic
by first creating and initializing the new SDK and loading contracts/data (use
local temporaries like let newSDK and temp collections), and only after
loadKnownContractsIntoSDK and loadPersistedData succeed assign sdk = newSDK, set
dataManager?.currentNetwork = network, and replace
identities/contracts/documents/tokens with the newly loaded data; keep all
error-throwing work (SDK(network:), loadKnownContractsIntoSDK,
loadPersistedData) before mutating shared state so failures leave the existing
sdk and currentNetwork unchanged.

🧹 Nitpick comments (1)

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/AppState.swift (1)

104-124: Extract the SPV/trusted SDK creation path into one helper.

The same fallback tree now lives in both initializeSDK and switchNetwork. The next change to error handling or provider selection is easy to land in one path and miss in the other.

Also applies to: 234-253

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/AppState.swift` around
lines 104 - 124, Extract the SPV/trusted SDK creation logic used in
initializeSDK and switchNetwork into a single helper function (e.g.,
makeSDKForNetwork(network:sdkNetwork, spvHandle:spvClientHandle?,
useFallback:useTrustedQuorumFallback) -> SDK) that encapsulates the fallback
tree: try constructing SDK(network: , spvClientHandle:) if spvHandle != nil, on
failure fall back to SDK(network:) only if useFallback is true, otherwise
rethrow; if spvHandle is nil create SDK(network:) when useFallback is true or
throw SDKError.invalidState when false. Replace the duplicated blocks in
initializeSDK and switchNetwork to call this new helper and preserve the same
NSLog messages and error propagation behavior.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/AppState.swift`:
- Around line 143-146: The race occurs because updateSPVClientHandle(_:) runs in
handleNetworkSwitch() while switchNetwork(...) can be started asynchronously
from the currentNetwork didSet in OptionsView; modify handleNetworkSwitch() so
that after calling updateSPVClientHandle(_:) it immediately triggers/awaits the
SDK rebuild (call switchNetwork(...) directly or await the spawned Task) to
ensure the SDK is rebuilt with the new spvClientHandle before returning;
reference updateSPVClientHandle(_:), handleNetworkSwitch(), switchNetwork(...),
currentNetwork didSet/OptionsView to locate and change the code paths so the
handle update is always followed synchronously by the SDK rebuild.

---

Outside diff comments:
In `@packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/AppState.swift`:
- Around line 215-267: The switchNetwork method mutates state (clearing
identities/contracts/documents/tokens and advancing dataManager?.currentNetwork)
before potentially failing during SDK creation and load; make the switch atomic
by first creating and initializing the new SDK and loading contracts/data (use
local temporaries like let newSDK and temp collections), and only after
loadKnownContractsIntoSDK and loadPersistedData succeed assign sdk = newSDK, set
dataManager?.currentNetwork = network, and replace
identities/contracts/documents/tokens with the newly loaded data; keep all
error-throwing work (SDK(network:), loadKnownContractsIntoSDK,
loadPersistedData) before mutating shared state so failures leave the existing
sdk and currentNetwork unchanged.

---

Nitpick comments:
In `@packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/AppState.swift`:
- Around line 104-124: Extract the SPV/trusted SDK creation logic used in
initializeSDK and switchNetwork into a single helper function (e.g.,
makeSDKForNetwork(network:sdkNetwork, spvHandle:spvClientHandle?,
useFallback:useTrustedQuorumFallback) -> SDK) that encapsulates the fallback
tree: try constructing SDK(network: , spvClientHandle:) if spvHandle != nil, on
failure fall back to SDK(network:) only if useFallback is true, otherwise
rethrow; if spvHandle is nil create SDK(network:) when useFallback is true or
throw SDKError.invalidState when false. Replace the duplicated blocks in
initializeSDK and switchNetwork to call this new helper and preserve the same
NSLog messages and error propagation behavior.

🪄 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: defaults

Review profile: CHILL

Plan: Pro

Run ID: 1d056420-6f71-49b1-ad49-3434618ac7b3

📥 Commits

Reviewing files that changed from the base of the PR and between d9e478e and 8d2bb27.

📒 Files selected for processing (4)

• packages/rs-platform-wallet/Cargo.toml
• packages/rs-platform-wallet/src/spv_context_provider.rs
• packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/AppState.swift
• packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/UnifiedAppState.swift

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

• packages/rs-platform-wallet/Cargo.toml
• packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/UnifiedAppState.swift
• packages/rs-platform-wallet/src/spv_context_provider.rs

[github-actions]

Your move: thepastaclaw requested changes on this head; dismiss the review or push a fix; thepastaclaw left review threads unresolved; resolve them.
Full checklist in the description.

[thepastaclaw]

Re-review — Final validation — Phase 1 + Phase 2

The SPV routing and SDK rebuild changes are substantially implemented, and the changed Rust, Swift, Kotlin, and JavaScript checks reported by CI are successful. However, the PR still exposes quorum keys before the pinned SPV dependency authenticates network difficulty and Core masternode commitments, and Swift can replace a wallet manager before its asynchronous teardown completes; these remain blocking correctness and security issues.

🔴 4 blocking

1 finding(s) not shown inline (the lines are not part of this PR's diff)

🔴 Blocking: Keep contract Data buffers alive through the preload FFI call
packages/swift-sdk/Sources/SwiftDashSDK/SDK.swift:492-496

loadKnownContracts stores pointers returned from each Data.withUnsafeBytes closure in contractDataPointers, then invokes dash_sdk_add_known_contracts after all those closures have returned. Swift only guarantees those pointers for the duration of the corresponding closure; retaining the Data values in contracts does not extend the validity of escaped buffer pointers because Foundation may use temporary or relocated storage. The Rust FFI function immediately dereferences each pointer while deserializing the contracts at rs-sdk-ffi/src/sdk.rs:959-965. This can cause invalid reads or preload failures, preventing strict-SPV contract-dependent proof verification from working reliably. Keep every withUnsafeBytes scope open until the FFI call returns.

_{source: gpt-6.1-sol (phase2-reviewer: ffi-engineer)}

2 carried-forward finding(s) already raised on this PR; not re-posting as new inline comments.

Review provenance

Source: reviewer 1: muse-spark-1.3-contributor (agent: phase1-reviewer, role: general); reviewer 2: muse-spark-1.3-contributor (agent: phase1-reviewer, role: rust-quality); reviewer 3: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 4: gpt-6.1-sol (agent: phase2-reviewer, role: architecture-layering); reviewer 5: gpt-6.1-sol (agent: phase2-reviewer, role: ffi-engineer); reviewer 6: gpt-6.1-sol (agent: phase2-reviewer, role: rust-quality); reviewer 7: gpt-6.1-sol (agent: phase2-reviewer, role: security-auditor); final verifier: gpt-6.1-sol (agent: sol-verifier, role: final-verifier)

• Triage: critical by gpt-6.1-sol (effort low) — This is a large, intricate diff that changes quorum public-key sourcing and proof-verification trust boundaries, including cryptographic key handling, SPV verification readiness, concurrent source leasing, and FFI ownership/lifecycle paths in files such as packages/rs-platform-wallet/src/spv_context_provider.rs and packages/rs-sdk-ffi/src/sdk.rs.
• Phase 1 reviewers: muse-spark-1.3-contributor — general (completed, effort xhigh); agent phase1-reviewer, muse-spark-1.3-contributor — rust-quality (completed, effort xhigh); agent phase1-reviewer
• Phase 1 model: muse-spark-1.3-contributor — not quota-gated; passed over gemini-3.8-flash-high (antigravity quota lookup failed), glm-5.3-flash (not used above high effort; tier asks max)
• Single stage: Phase 1 and Phase 2 reviewed this head side by side, with no blocker gate between them (triage tier)
• Fresh verifier: gpt-6.1-sol — final-verifier; agent sol-verifier
• Phase 2 reviewers: gpt-6.1-sol — general (completed, effort xhigh); agent phase2-reviewer, gpt-6.1-sol — architecture-layering (completed, effort xhigh); agent phase2-reviewer, gpt-6.1-sol — ffi-engineer (completed, effort xhigh); agent phase2-reviewer, gpt-6.1-sol — rust-quality (completed, effort xhigh); agent phase2-reviewer, gpt-6.1-sol — security-auditor (completed, effort xhigh); agent phase2-reviewer

🤖 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/Sources/SwiftDashSDK/SDK.swift`:
- [BLOCKING] packages/swift-sdk/Sources/SwiftDashSDK/SDK.swift:492-496: Keep contract Data buffers alive through the preload FFI call
  `loadKnownContracts` stores pointers returned from each `Data.withUnsafeBytes` closure in `contractDataPointers`, then invokes `dash_sdk_add_known_contracts` after all those closures have returned. Swift only guarantees those pointers for the duration of the corresponding closure; retaining the `Data` values in `contracts` does not extend the validity of escaped buffer pointers because Foundation may use temporary or relocated storage. The Rust FFI function immediately dereferences each pointer while deserializing the contracts at `rs-sdk-ffi/src/sdk.rs:959-965`. This can cause invalid reads or preload failures, preventing strict-SPV contract-dependent proof verification from working reliably. Keep every `withUnsafeBytes` scope open until the FFI call returns.

In `packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/WalletManagerStore.swift`:
- [BLOCKING] packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/WalletManagerStore.swift:225-231: Tear down stale managers before replacing their SDK
  When `activate` detects that a cached manager was configured against a different SDK, it creates and stores the replacement without awaiting shutdown of the stale manager. `PlatformWalletManager.deinit` only schedules native teardown asynchronously, while the old manager can still be retained by SwiftUI views, wallet-scoped services, or in-flight operations. The replacement is then configured and published against the same persistence scope before the old manager is quiescent, allowing concurrent callbacks, reads, writes, or SPV-related teardown against shared state. Await the old manager's `shutdown()` before configuring or publishing its replacement, while retaining the old manager if replacement setup fails.

In `packages/rs-platform-wallet/src/spv/runtime.rs`:
- [BLOCKING] packages/rs-platform-wallet/src/spv/runtime.rs:358-369: Require network-difficulty validation before trusting SPV headers
  (existing thread: https://github.com/dashpay/platform/pull/3417#discussion_r4351202371)
  The readiness gate treats dash-spv's `SyncState::Synced` headers as sufficient before the manager publishes SPV quorum lookups. The pinned rust-dashcore revision `aca020263990a86a15cc1d97ae2cbf965d488db5` validates continuity and whether each header satisfies the target encoded in that header, but its `BlockHeaderValidator` does not validate the network-required Dark Gravity Wave difficulty. The current rust-dashcore default branch contains a network-aware validator that derives required difficulty from network parameters and header history, but that implementation is not present in the pinned revision. A peer can therefore extend a trusted checkpoint with a cheaply generated, internally consistent header tail and make the SPV source appear ready. Keep the SPV quorum source unavailable until the dependency pin includes the network-difficulty and related chain-selection fixes.
- [BLOCKING] packages/rs-platform-wallet/src/spv/runtime.rs:548-556: Authenticate SPV quorum state against Core headers before trusting its keys
  (existing thread: https://github.com/dashpay/platform/pull/3417#discussion_r3962587472)
  `get_quorum_public_key_with_status` returns a key once dash-spv reports the quorum as `Verified`, but the pinned dependency's masternode synchronization applies `MnListDiff` and QRInfo data without authenticating the corresponding coinbase Merkle proof or comparing reconstructed masternode-list and quorum roots with Core's coinbase commitments. Its `Verified` status therefore establishes consistency between quorum signatures and the locally constructed masternode entries, not that those entries came from the authenticated Core chain. The runtime then uses that key as the Platform proof trust root. An attacker controlling the relevant SPV responses and Platform proof endpoint could provide a fabricated list and attacker-controlled quorum key that passes this gate. The dependency pin must remain gated on the upstream coinbase, commitment, and ChainLock anchoring work before SPV keys are exposed.

Out-of-scope follow-up suggestions (1)

These are valid observations, but they are outside this PR's scope and should be handled in separate issues or author/maintainer-requested PRs rather than blocking this review.

• Validate the SPV network against the SDK network — The SPV attachment ABI accepts an independent network argument even though the SDK already has a configured network. The shipped Swift caller passes matching values, and this API predates the reviewed change, so it does not block this PR; however, another FFI caller could install activation-height and quorum-family rules for the wrong network.
  • Follow-up: Create a separate rs-platform-wallet-ffi hardening change that derives the SPV network from the SDK or rejects mismatched values.

[github-actions]

Your move: thepastaclaw requested changes on this head; dismiss the review or push a fix; thepastaclaw left review threads unresolved; resolve them.
Full checklist in the description.

[thepastaclaw]

Re-review — Final validation — Phase 1 + Phase 2

The Rust and Swift implementation checks pass, but the SPV provider still exposes quorum keys before the pinned dependency authenticates network difficulty and Core coinbase commitments. The manager replacement path also ignores non-clean shutdown results, and SPV lease arbitration is implemented in the FFI layer despite the repository's rule that mobile orchestration belongs in the wallet crate. The PR Hygiene policy check is failing, but the code-review blockers are independent of that policy result.

🔴 4 blocking

2 carried-forward finding(s) already raised on this PR; not re-posting as new inline comments.

Review provenance

Source: reviewer 1: muse-spark-1.3-contributor (agent: phase1-reviewer, role: general); reviewer 2: muse-spark-1.3-contributor (agent: phase1-reviewer, role: rust-quality); reviewer 3: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 4: gpt-6.1-sol (agent: phase2-reviewer, role: architecture-layering); reviewer 5: gpt-6.1-sol (agent: phase2-reviewer, role: ffi-engineer); reviewer 6: gpt-6.1-sol (agent: phase2-reviewer, role: rust-quality); reviewer 7: gpt-6.1-sol (agent: phase2-reviewer, role: security-auditor); final verifier: gpt-6.1-sol (agent: sol-verifier, role: final-verifier)

• Triage: critical by gpt-6.1-sol (effort low) — This is a large cross-language change that alters quorum public-key sourcing and Platform proof-verification trust boundaries, directly affecting cryptographic key handling and security-sensitive verification paths.
• Phase 1 reviewers: muse-spark-1.3-contributor — general (completed, effort xhigh); agent phase1-reviewer, muse-spark-1.3-contributor — rust-quality (completed, effort xhigh); agent phase1-reviewer
• Phase 1 model: muse-spark-1.3-contributor — not quota-gated; passed over gemini-3.8-flash-high (antigravity quota lookup failed), glm-5.3-flash (not used above high effort; tier asks max)
• Single stage: Phase 1 and Phase 2 reviewed this head side by side, with no blocker gate between them (triage tier)
• Fresh verifier: gpt-6.1-sol — final-verifier; agent sol-verifier
• Phase 2 reviewers: gpt-6.1-sol — general (completed, effort xhigh); agent phase2-reviewer, gpt-6.1-sol — architecture-layering (completed, effort xhigh); agent phase2-reviewer, gpt-6.1-sol — ffi-engineer (completed, effort xhigh); agent phase2-reviewer, gpt-6.1-sol — rust-quality (completed, effort xhigh); agent phase2-reviewer, gpt-6.1-sol — security-auditor (completed, effort xhigh); agent phase2-reviewer

🤖 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/WalletManagerStore.swift`:
- [BLOCKING] packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/WalletManagerStore.swift:243-264: Do not replace a manager after a non-clean shutdown
  `await stale.shutdown()` returns metrics but the replacement path ignores whether native shutdown was clean. The Rust manager reports a non-clean shutdown when a coordinator, event adapter, SPV teardown, or other worker exceeds its bounded join budget; `platform_wallet_manager_destroy` still returns success and leaves straggling workers alive while retaining their persistence callbacks. `activate()` then restores the replacement and publishes it for the same network, allowing the old worker and the new manager to access the same persisted wallet state concurrently. The shutdown contract must surface `all_clean()` (or otherwise serialize persistence until every worker has terminated), and the replacement must refuse to proceed when the old manager has live workers.

In `packages/rs-platform-wallet-ffi/src/manager.rs`:
- [BLOCKING] packages/rs-platform-wallet-ffi/src/manager.rs:216-243: Keep SPV lease ownership in the wallet crate
  The FFI constructor directly calls `SpvSourceSlot::claim()` and carries the resulting lifecycle lease into `PlatformWalletManager::serve_spv_quorums()`. This is orchestration logic enforcing the invariant that one wallet manager owns an SDK's SPV source, not FFI marshalling. The repository's coding conventions require mobile orchestration to live in `rs-platform-wallet`; otherwise native wallet callers must reproduce the claim/install protocol manually and can construct a manager without the same exclusivity and teardown invariant. Move claim and lease installation behind an owner-level wallet-manager constructor or attach operation, leaving this FFI function responsible only for converting the SDK handle and callback tables.

In `packages/rs-platform-wallet/src/spv/runtime.rs`:
- [BLOCKING] packages/rs-platform-wallet/src/spv/runtime.rs:353-369: Require network-difficulty validation before trusting SPV headers
  (existing thread: https://github.com/dashpay/platform/pull/3417#discussion_r4351202371)
  `is_ready()` treats dash-spv as ready once header and masternode synchronization report `SyncState::Synced`. The pinned rust-dashcore revision `aca020263990` validates header continuity and whether each header satisfies the target encoded in that header, but does not validate `bits` against the network's required Dark Gravity Wave difficulty. The current upstream implementation adds this network-aware check, but it is not present in the pinned revision. A peer can therefore extend a trusted checkpoint with a cheap artificial header tail and then provide matching attacker-controlled masternode and quorum state; this code will publish those quorum keys as a Platform proof trust root. Keep SPV quorum serving unavailable until the dependency pin includes the network-difficulty validation tracked by rust-dashcore#1161.
- [BLOCKING] packages/rs-platform-wallet/src/spv/runtime.rs:471-510: Authenticate SPV quorum state against Core headers before trusting its keys
  (existing thread: https://github.com/dashpay/platform/pull/3417#discussion_r3962587472)
  `get_quorum_public_key()` accepts a quorum whenever dash-spv reports `LLMQEntryVerificationStatus::Verified`; that status only verifies the quorum against the masternode data currently held by the engine. In the pinned rust-dashcore revision, MnListDiff and QRInfo processing does not authenticate the coinbase Merkle proof against the stored header or compare the reconstructed masternode-list and quorum roots with the CbTx commitments. The current upstream tree contains these validation calls, but the Platform pin does not. A peer able to influence the SPV list-diff inputs can consequently supply attacker-controlled Platform quorum keys that pass the local `Verified` check and are then used to authenticate forged Platform proofs. Do not expose this source as a proof trust root until the pinned dependency includes the authenticated coinbase and commitment checks tracked by rust-dashcore#1077 and its dependent fixes.

[thepastaclaw]

🔴 Blocking: Do not replace a manager after a non-clean shutdown

await stale.shutdown() returns metrics but the replacement path ignores whether native shutdown was clean. The Rust manager reports a non-clean shutdown when a coordinator, event adapter, SPV teardown, or other worker exceeds its bounded join budget; platform_wallet_manager_destroy still returns success and leaves straggling workers alive while retaining their persistence callbacks. activate() then restores the replacement and publishes it for the same network, allowing the old worker and the new manager to access the same persisted wallet state concurrently. The shutdown contract must surface all_clean() (or otherwise serialize persistence until every worker has terminated), and the replacement must refuse to proceed when the old manager has live workers.

_{source: gpt-6.1-sol (phase2-reviewer: general)}

[github-actions]

📖 Book Preview built successfully.

Download the preview from the workflow artifacts.
To view locally: download the artifact, unzip, and open index.html.

Updated at 2026-11-06T07:46:46.521Z

[github-actions]

Your move: thepastaclaw requested changes on this head; dismiss the review or push a fix; thepastaclaw left review threads unresolved; resolve them.
Full checklist in the description.

[thepastaclaw]

Re-review — Final validation — Phase 1 + Phase 2

Verified head 1ab26d6: 13 prior findings are fixed, and the SPV lease-placement objection is withdrawn. Two blocking manager-replacement defects remain—restoring before old persistence writers are quiescent and publishing an empty manager after restoration fails—plus one upstream readiness-tracking suggestion. This was a static review; current Rust workspace, wasm32, Swift and Kotlin CI checks pass, PR Hygiene remains pending, and the supplied base-drift analysis reports no merge conflicts.

🔴 2 blocking | 🟡 1 suggestion(s)

1 carried-forward finding(s) already raised on this PR; not re-posting as new inline comments.

Review provenance

Source: reviewer 1: muse-spark-1.3-contributor (agent: phase1-reviewer, role: general); reviewer 2: muse-spark-1.3-contributor (agent: phase1-reviewer, role: rust-quality); reviewer 3: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 4: gpt-6.1-sol (agent: phase2-reviewer, role: architecture-layering); reviewer 5: gpt-6.1-sol (agent: phase2-reviewer, role: ffi-engineer); reviewer 6: gpt-6.1-sol (agent: phase2-reviewer, role: platform-versioning); reviewer 7: gpt-6.1-sol (agent: phase2-reviewer, role: rust-quality); reviewer 8: gpt-6.1-sol (agent: phase2-reviewer, role: security-auditor); final verifier: gpt-6.1-sol (agent: sol-verifier, role: final-verifier)

• Triage: critical by gpt-6.1-sol (effort low) — The large, intricate change directly changes quorum public-key sourcing for cryptographic proof verification in packages/rs-context-provider/src/routing.rs and packages/rs-platform-wallet/src/spv_context_provider.rs, including trust-source routing and SPV eligibility checks.
• Phase 1 reviewers: muse-spark-1.3-contributor — general (completed, effort xhigh); agent phase1-reviewer, muse-spark-1.3-contributor — rust-quality (completed, effort xhigh); agent phase1-reviewer
• Phase 1 model: muse-spark-1.3-contributor — not quota-gated; passed over gemini-3.8-flash-high (antigravity quota lookup failed), glm-5.3-flash (not used above high effort; tier asks max)
• Single stage: Phase 1 and Phase 2 reviewed this head side by side, with no blocker gate between them (triage tier)
• Fresh verifier: gpt-6.1-sol — final-verifier; agent sol-verifier
• Phase 2 reviewers: gpt-6.1-sol — general (completed, effort xhigh); agent phase2-reviewer, gpt-6.1-sol — architecture-layering (completed, effort xhigh); agent phase2-reviewer, gpt-6.1-sol — ffi-engineer (completed, effort xhigh); agent phase2-reviewer, gpt-6.1-sol — platform-versioning (completed, effort xhigh); agent phase2-reviewer, gpt-6.1-sol — rust-quality (completed, effort xhigh); agent phase2-reviewer, gpt-6.1-sol — security-auditor (completed, effort xhigh); agent phase2-reviewer

🤖 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/WalletManagerStore.swift`:
- [BLOCKING] packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/WalletManagerStore.swift:297-307: Do not publish an empty replacement after wallet restoration fails
  This catch converts an unavailable wallet snapshot into a successful empty replacement. The caller has already shut down the stale manager and unconditionally caches and publishes the new manager after this helper returns. Restoration genuinely can fail: the Swift persistence handler returns an error when fetching persisted wallets fails, and Rust's loader propagates that error and rolls back partial wallet registrations. The fresh manager can consequently remain empty while the SDK rebuild reports success.

  This is not equivalent to a successful load containing no wallets. Existing wallets disappear from the active manager, and subsequent `activate` calls with the same SDK take the identity fast path without retrying hydration. The newly ordered handover therefore depends on a fallible operation that its comment incorrectly treats as unable to fail.

  Carry restoration failure through the replacement lifecycle and expose an unavailable, retryable state rather than publishing an empty manager as successfully restored. Account for the fact that the old manager is already terminal: merely throwing into the current rollback path would leave the app retaining a shut-down manager. Add a failed-read/retry handover test.
- [BLOCKING] packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/WalletManagerStore.swift:262-265: Do not replace a manager after a non-clean shutdown
  (existing thread: https://github.com/dashpay/platform/pull/3417#discussion_r4416654088)
  Awaiting `stale.shutdown()` does not establish that its persistence writers have stopped. Rust's `PlatformWalletManager::shutdown` bounds coordinator drains and worker joins and explicitly reports timeouts with potentially live workers, but `platform_wallet_manager_destroy` removes the handle, logs that report and returns Success. Swift's shutdown metrics record those FFI results, not the worker-level report, so even inspecting the existing metrics would not establish quiescence.

  The next statements load and publish another manager against the same network's persisted wallets. An already-admitted coordinator pass can finish after its drain budget and persist through its retained callback context; for example, `persistAddressBalances` directly assigns balance, nonce and `lastSeenHeight`. The replacement can therefore load before the old pass's final commit, or an old write can overwrite state subsequently written by the replacement. Callback ownership prevents dangling pointers, but does not serialize these writers.

  Provide a wallet-owned replacement/quiescence contract that prevents hydration until old writers have terminated, or fences every superseded persistence writer, and expose its actionable outcome through FFI. Preserve the early configuration-failure behavior, and add coverage where an admitted worker outlives shutdown's budget; the current activation test only establishes that native destroy returned before the swap.

In `packages/rs-platform-wallet/src/spv/runtime.rs`:
- [SUGGESTION] packages/rs-platform-wallet/src/spv/runtime.rs:65-75: Track the stale-sync readiness repair in dash-spv
  The two-block tolerance is a legitimate Platform policy, but the need to supplement `Synced` reflects an upstream health-reporting gap. At both the pinned and current upstream revisions, `MasternodesManager::settle_diff` returns from a given-up tip update without withdrawing `Synced`, and `SyncProgress::is_synced` checks phase states without freshness. This guard protects this provider, while other dash-spv consumers still receive that misleading health result.

  Track the freshness/degradation contract in dashpay/rust-dashcore's masternode progress API and link the follow-up from this PR before deferring it. dashpay/rust-dashcore#954 covers related initial QRInfo retry exhaustion, but its stated scope does not cover failed incremental tip updates; extend that issue or link a dedicated one. Platform can retain its allowed-lag policy while consuming authoritative upstream freshness information.

Out-of-scope follow-up suggestions (1)

These are valid observations, but they are outside this PR's scope and should be handled in separate issues or author/maintainer-requested PRs rather than blocking this review.

• Consume upstream validation-before-fork-recovery fix — The pinned dash-spv header pipeline can emit ForkDetected for an unmatched header before checking its proof of work or required difficulty, allowing an invalid fork announcement to trigger recovery. This is an existing upstream synchronization-availability defect, separate from the repaired quorum-list authentication path.
  • Follow-up: Track dashpay/rust-dashcore#1304 and consume its validation-before-routing fix in a separate dependency-update PR.

[thepastaclaw]

🔴 Blocking: Do not publish an empty replacement after wallet restoration fails

This catch converts an unavailable wallet snapshot into a successful empty replacement. The caller has already shut down the stale manager and unconditionally caches and publishes the new manager after this helper returns. Restoration genuinely can fail: the Swift persistence handler returns an error when fetching persisted wallets fails, and Rust's loader propagates that error and rolls back partial wallet registrations. The fresh manager can consequently remain empty while the SDK rebuild reports success.

This is not equivalent to a successful load containing no wallets. Existing wallets disappear from the active manager, and subsequent activate calls with the same SDK take the identity fast path without retrying hydration. The newly ordered handover therefore depends on a fallible operation that its comment incorrectly treats as unable to fail.

Carry restoration failure through the replacement lifecycle and expose an unavailable, retryable state rather than publishing an empty manager as successfully restored. Account for the fact that the old manager is already terminal: merely throwing into the current rollback path would leave the app retaining a shut-down manager. Add a failed-read/retry handover test.

_{source: gpt-6.1-sol (phase2-reviewer: general)}

[thepastaclaw]

🟡 Suggestion: Track the stale-sync readiness repair in dash-spv

The two-block tolerance is a legitimate Platform policy, but the need to supplement Synced reflects an upstream health-reporting gap. At both the pinned and current upstream revisions, MasternodesManager::settle_diff returns from a given-up tip update without withdrawing Synced, and SyncProgress::is_synced checks phase states without freshness. This guard protects this provider, while other dash-spv consumers still receive that misleading health result.

Track the freshness/degradation contract in dashpay/rust-dashcore's masternode progress API and link the follow-up from this PR before deferring it. dashpay/rust-dashcore#954 covers related initial QRInfo retry exhaustion, but its stated scope does not cover failed incremental tip updates; extend that issue or link a dedicated one. Platform can retain its allowed-lag policy while consuming authoritative upstream freshness information.

_{source: gpt-6.1-sol (phase2-reviewer: architecture-layering)}

[github-actions]

Your move: thepastaclaw left review threads unresolved; resolve them.
Full checklist in the description.