[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.
• AdaptiveContextProvider::new refuses a trusted provider that declares another network, which the builder cannot see behind it.
• 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.
• Adding, preloading and registering a contract keep a held contract of a higher version. This is v5.1-dev's rule from feat(sdk): send, scan and read DashPay private contact requests #5809, which the resolver now owns, so it holds for the SPV and adaptive providers too. replace_known_contract replaces on purpose.

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.
• Its quorum-source indicator follows SPV progress and running state, from a leaf view that observes the wallet manager.

Merged with v5.1-dev at 9b36712770 (earlier at 46c26cb05f). The first merge brought in the rust-dashcore pin above, the verified quorum provider (#5523, #5720) and its SDK opt-in (#5721). The second:

• moves feat(sdk): send, scan and read DashPay private contact requests #5809's keep-newer contract rule into LocalContextResolver. Registration no longer overwrites a newer held contract, as this PR first had it;
• drops the tests for an SDK without a context provider (fix(sdk): stop banning nodes for proofs the SDK's context provider cannot verify #5769, feat(sdk): send, scan and read DashPay private contact requests #5809), a state that cannot be built here;
• builds two feat(wasm-sdk): seal and scan DashPay private contact requests #5811 wasm-sdk test SDKs with their context instead of calling set_context_provider.

Earlier merge details:

• 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?

• At 47e3355613, after the second v5.1-dev merge:
  • CI's non-shielded phase mirrored locally (CI's package list plus dash-context-provider, its env, --all-features --locked --lib --bins --tests -- --skip shield): 21,980 passed, 0 failed, 70 ignored, across 104 test binaries. That run predates only the last commit, which adds one test.
  • rs-sdk-trusted-context-provider: 155 passed (all features), 142 (default features). wasm-sdk: 221 native tests passed.
  • cargo clippy --all-targets --all-features -- -D warnings clean on dash-context-provider, rs-sdk-trusted-context-provider, dash-sdk, rs-sdk-ffi, platform-wallet, platform-wallet-ffi, wasm-sdk; the context-provider crates also without features.
  • Red → green: should_refuse_a_trusted_provider_for_another_network (red with the constructor fallible but unchecked) and the resolver's should_keep_a_newer_contract_over_a_registered_older_one (red with registration overwriting, as before the merge).
  • Swift: only swiftc -parse here; the Swift SDK job builds it. The indicator fix has no test, as SwiftExampleAppTests cannot drive a view's modifiers.

Earlier rounds:

• 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:

• 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 and lookup, which duplicate LocalContextResolver. 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() (feat(sdk): make TrustedHttpContextProvider report its network so the SDK refuses a mismatch #5766);
  • 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.
• dash-spv keeps masternode sync Synced while its newest list lags the header tip after given-up tip updates; this PR's readiness adds a two-block lag check. Tracked upstream in dash-spv: masternode sync stays Synced while its newest list falls behind the header tip rust-dashcore#1366.
• SwiftExampleApp's manager replacement ignores a non-clean shutdown and a failed wallet restore, both of which predate this PR. Tracked in SwiftExampleApp: replacing a network's wallet manager ignores a non-clean shutdown and a failed wallet restore #5816.

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

• Bots — thepastaclaw ✓
• Self-review — post /self-reviewed
• Build green
• 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/manager.rs) — 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/SDK.swift, packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/AppState.swift and 11 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: 47e3355

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.
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…
Description Check		Check skipped - CodeRabbit’s high-level summary is enabled.

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 47e3355. 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]

📖 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-09T16:04:30.220Z

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

[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

Static verification at cd8e2c0 confirms two blocking wallet-replacement defects: incomplete shutdown is ignored, and restoration failure is published as successful empty state. Current CI now reports the Swift refusal regression test failing; Rust workspace, wasm32, and Kotlin checks passed, while book preview failed during the unrelated mdBook download/extraction. The upstream stale-sync tracking request is satisfied by rust-dashcore#1366, and the supplied base changes do not supersede the remaining findings.

🔴 2 blocking

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

Review provenance

Source: reviewer 1: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 2: gpt-6.1-sol (agent: phase2-reviewer, role: architecture-layering); reviewer 3: gpt-6.1-sol (agent: phase2-reviewer, role: ffi-engineer); reviewer 4: muse-spark-1.3-contributor (agent: phase1-reviewer, role: general); reviewer 5: gpt-6.1-sol (agent: phase2-reviewer, role: platform-versioning); reviewer 6: gpt-6.1-sol (agent: phase2-reviewer, role: rust-quality); reviewer 7: gpt-6.1-sol (agent: phase2-reviewer, role: security-auditor); reviewer 8: muse-spark-1.3-contributor (agent: phase1-reviewer, role: rust-quality); 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 proof-verification key handling and trust-source selection in packages/rs-context-provider/src/routing.rs and packages/rs-platform-wallet/src/spv_context_provider.rs, determining which quorum public keys are accepted for Platform proofs.
• 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:262-266: Do not replace a manager after a non-clean shutdown
  (existing thread: https://github.com/dashpay/platform/pull/3417#discussion_r4416654088)
  `shutdown()` now returns the native teardown verdict through `PlatformWalletShutdownMetrics.allWorkersStopped`, but activation discards it and immediately restores the successor from the same persistence scope. Rust destroy removes the handle even when it returns `ErrorShutdownIncomplete`; a surviving worker retains its persister and owned callback context and can still write afterward. Those lifetime guarantees prevent use-after-free, not stale overwrites of balances, nonces, or synchronization state written by the replacement. A newly rebuilt SDK has its own source slot, so slot exclusivity does not prevent this overlap.

  Require a clean shutdown before restoring or publishing the successor. On refusal, explicitly shut down the unused replacement, expose a restart-required/unavailable state, and retain the refusal for that persistence scope across later activation and background-manager requests. Merely retaining the predecessor's revoked handle is not a usable rollback. Current Swift CI confirms the missing behavior: job https://github.com/dashpay/platform/actions/runs/42572897360/job/129021078416 lists `WalletManagerStoreActivateTests.testShouldRefuseTheReplacementWhileTheReplacedManagerHasLiveWorkers()` under `Failing tests` and ends with `** TEST FAILED **`. This is the same lifecycle defect, not a separate test-only finding.
- [BLOCKING] packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/WalletManagerStore.swift:297-307: Do not publish an empty replacement after wallet restoration fails
  (existing thread: https://github.com/dashpay/platform/pull/3417#discussion_r4490717728)
  `loadFromPersistor()` propagates a failed bulk persistence load, but this helper catches it and returns normally. Activation has already shut down the predecessor before calling the helper, then unconditionally caches and publishes the fresh manager. An unreadable wallet store therefore becomes an apparently healthy empty wallet set, and the rebuild coordinator also publishes the new SDK. A subsequent activation using that SDK takes the cache-hit return without retrying hydration.

  Although catch-and-log restoration existed on the base, this PR moves it into this helper and relies on that success-shaped result in its new shutdown-before-restoration replacement lifecycle, so the issue remains in scope. Preserve the restoration failure through activation, explicitly dispose of the unpublished replacement, and expose an unavailable/retryable restoration state rather than enabling normal wallet flows over apparent absence. The Rust loader already distinguishes load failure from an empty store and rolls back partial hydration; the coordinator must not discard that distinction. Add a restoration-failure activation test alongside the configuration-failure coverage.

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.

• Expose incomplete teardown to Kotlin lifecycle consumers — JNI logs the native shutdown report but returns Unit, so Kotlin cannot distinguish surviving workers before closing its persistence executor or permitting another manager to open the same state. These lifecycle behaviors predate this PR; the changed logging does not introduce them, but they warrant a dedicated correctness follow-up.
  • Follow-up: A follow-up PR should propagate the native destroy verdict through JNI and coordinate Kotlin persistence-resource lifetime and manager replacement with that verdict.

[github-actions]

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

[github-actions]

Waiting for bot review — thepastaclaw not yet. Wait for the missing reviews, or a writer can post /skip-bots to proceed without them; blocking findings still need addressing.
Full checklist in the description.

[thepastaclaw]

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

At e15b2df, the SPV trust prerequisites, fail-closed routing, contract-cache sharing, and prior boundary fixes are present; two non-blocking issues remain in native provider composition and the app's source indicator. Current CI passes Rust workspace, wasm32, Swift SDK, Kotlin, and JavaScript checks; this verification was static-only, with no local builds or tests. The pre-existing manager replacement failures remain tracked in #5816, and the supplied eleven-commit base drift contains no reported merge conflicts or changes superseding this integration.

🟡 2 suggestion(s)

Review provenance

Source: reviewer 1: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 2: gpt-6.1-sol (agent: phase2-reviewer, role: architecture-layering); reviewer 3: gpt-6.1-sol (agent: phase2-reviewer, role: ffi-engineer); reviewer 4: gpt-6.1-sol (agent: phase2-reviewer, role: platform-versioning); reviewer 5: gpt-6.1-sol (agent: phase2-reviewer, role: rust-quality); reviewer 6: gpt-6.1-sol (agent: phase2-reviewer, role: security-auditor); reviewer 7: muse-spark-1.3-contributor (agent: phase1-reviewer, role: general); reviewer 8: muse-spark-1.3-contributor (agent: phase1-reviewer, role: rust-quality); reviewer 9: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 10: gpt-6.1-sol (agent: phase2-reviewer, role: architecture-layering); reviewer 11: gpt-6.1-sol (agent: phase2-reviewer, role: ffi-engineer); reviewer 12: gpt-6.1-sol (agent: phase2-reviewer, role: platform-versioning); reviewer 13: gpt-6.1-sol (agent: phase2-reviewer, role: rust-quality); reviewer 14: 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, cross-cutting change directly alters 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 fallback and SPV readiness 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 final gate: an independent Phase-2 review ran after iterative findings were reconciled
• 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, 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/rs-context-provider/src/routing.rs`:
- [SUGGESTION] packages/rs-context-provider/src/routing.rs:311-321: Reject mismatched networks when composing an adaptive provider
  The constructor accepts the routing network independently of `trusted.network()`, then `network()` advertises only the routing network. Wrapping a Testnet `VerifiedHttpContextProvider` with `Network::Mainnet` therefore passes the Mainnet SDK builder's network check even though installing that child directly would be rejected. Auto before SPV readiness, and Trusted mode, subsequently use the Testnet provider while reporting Mainnet; proof verification does not universally catch this mismatch afterward, since identity verification ignores its network argument and Tenderdash signature verification uses the response's chain ID. The existing FFI factory supplies matching networks, so this is a native-composition safeguard rather than a demonstrated regression in the shipped Swift path. Reject a child that declares a different network in the routing owner and add a regression using a child that returns `Some(other_network)`; the current requirements test uses a child with no declared network.

In `packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/SwiftExampleAppApp.swift`:
- [SUGGESTION] packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/SwiftExampleAppApp.swift:185-187: Refresh the quorum-source indicator when SPV stops running
  Readiness depends on running state as well as progress. At the pinned dash-spv revision, a failed continuous-sync loop clears `running`, and coordinator shutdown retains the last progress snapshot. `PlatformWalletManager.applyManagerSnapshot` can consequently publish `spvIsRunning = false` without changing `spvProgress`. Auto then switches native proof verification to trusted HTTP, but this observer does not refresh `AppState.quorumSource`, leaving Options displaying the green “SPV (trustless)” label until another progress or mode change. Observe `spvIsRunning` too and add coverage for a running-to-stopped transition with unchanged progress.

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.

• Complete the tracked wallet-manager replacement lifecycle repair — Native destroy still returns success after an incomplete shutdown, and restoration errors still permit publication of an empty replacement. Both deficiencies predate this integration, but can leave overlapping persistence workers or present unavailable wallets as absent.
  • Follow-up: Resolve #5816 in a separate lifecycle PR that propagates shutdown completeness, prevents overlapping persistence ownership, and makes restoration failure explicitly unavailable and retryable.

[thepastaclaw]

🟡 Suggestion: Reject mismatched networks when composing an adaptive provider

The constructor accepts the routing network independently of trusted.network(), then network() advertises only the routing network. Wrapping a Testnet VerifiedHttpContextProvider with Network::Mainnet therefore passes the Mainnet SDK builder's network check even though installing that child directly would be rejected. Auto before SPV readiness, and Trusted mode, subsequently use the Testnet provider while reporting Mainnet; proof verification does not universally catch this mismatch afterward, since identity verification ignores its network argument and Tenderdash signature verification uses the response's chain ID. The existing FFI factory supplies matching networks, so this is a native-composition safeguard rather than a demonstrated regression in the shipped Swift path. Reject a child that declares a different network in the routing owner and add a regression using a child that returns Some(other_network); the current requirements test uses a child with no declared network.

_{source: gpt-6.1-sol (phase2-reviewer: general, architecture-layering, ffi-engineer, platform-versioning, rust-quality, security-auditor)}

[thepastaclaw]

🟡 Suggestion: Refresh the quorum-source indicator when SPV stops running

Readiness depends on running state as well as progress. At the pinned dash-spv revision, a failed continuous-sync loop clears running, and coordinator shutdown retains the last progress snapshot. PlatformWalletManager.applyManagerSnapshot can consequently publish spvIsRunning = false without changing spvProgress. Auto then switches native proof verification to trusted HTTP, but this observer does not refresh AppState.quorumSource, leaving Options displaying the green “SPV (trustless)” label until another progress or mode change. Observe spvIsRunning too and add coverage for a running-to-stopped transition with unchanged progress.

Suggested change

	.onChange(of: walletManager.spvProgress) { _, _ in
	platformState.applyQuorumMode()
	}
	.onChange(of: walletManager.spvProgress) { _, _ in
	platformState.applyQuorumMode()
	}
	.onChange(of: walletManager.spvIsRunning) { _, _ in
	platformState.applyQuorumMode()
	}

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

[github-actions]

Bots are done — your move: post /self-reviewed.
Full checklist in the description.