[Claudius-Maginificent]

TL;DR: Updates Dash Evo Tool for Platform v5.1-dev (5.0.0-rc.8) while retaining the protocol 14 features in this PR and integrating the current development branch.

User story

As a wallet user, I want to keep my existing wallets and identities and use the features supported by my selected network safely.

Scenario

Mainnet (protocol 13) and testnet (protocol 14) answer identity discovery in different formats. With this update, the app asks each network in the format that network has proven it supports and verifies the signed answer, so identity lookup works on both.

Detailed discussion

Dependency and integration

• Pin dash-sdk, rs-sdk-trusted-context-provider, platform-wallet, and platform-wallet-storage together to Platform v5.1-dev 132ae31a1356d035cd8326f27c1109685090a71d (5.0.0-rc.8). In Cargo.lock only Platform packages move.
• Merge v1.0-dev, including fix(ui): deliver each task's result to the screen that started it #1091 result ownership/routing and fix(identity): recover Home contacts after startup #1099 Home contacts recovery.
• Adapt to the rust-dashcore cryptography API (dashcore::secp256k1 re-export removed, new ECDSA key types). Signing output is byte-identical: DET keeps RFC 6979 deterministic signatures and does not switch to the new low-R signing path.
• Preserve this PR's protocol 14 support: key spending limits and expiry, contract-bound key selection, once-per-identity token distributions, confirmed document action fees, contract fee-pot claims, and failed-withdrawal reporting. Protocol 14-only operations remain gated.
• Newly exposed shielded token operations and pool configuration are displayed without offering unsupported mutations. Document replacement preserves moderation metadata; unsupported typed-array documents cannot be submitted by the editor.
• Token creation can mark a token non-transferable (protocol 14), and Transfer is not offered for such tokens.
• New protocol refusals (username, vote, token transfer) get dedicated, actionable error messages.
• The connection indicator says when wallet sync data could not be saved. Headless (MCP/CLI) reporting of this fault is a TODO.
• Comments explain entropy-only document ids (placeholders from protocol 14) and why new tokens are not tradeable. Deferred upstream features link to feat(dpns): sell, buy and transfer usernames through the platform-wallet marketplace #1103, feat(dashpay): create and claim DashPay invitations, and withdraw credits to a contact #1104 and feat(shielded): move credits between identities and the shielded pool, and shield to another wallet #1105.

Mainnet compatibility

Upstream #5515 (included in this pin) versions the non-unique identity lookup: the SDK sends the V0 request, answered with the protocol 13 two-proof IdentityProvedResponse (field 2), until the network has proven a protocol version that serves V1.

Verified live on 2026-10-23 with upstream's ignored harness rs-sdk/tests/identity_discovery_live.rs at this exact pin, read-only, with full proof and quorum-signature verification (no relaxed checks, no funds, no writes):

• Mainnet, protocol 13, height 457323: V0 two-proof answers verified for every probed key hash (matches and proved absence), including the two nodes probed on 2026-10-21 (45.135.180.114, 84.247.180.190) and the default node list. A V1 request is refused by protocol 13 nodes, and the SDK never sends one before protocol 14 is proven.
• Testnet, protocol 14, height 639696: both V0 two-proof and V1 one-proof answers verified.

The harness takes quorum keys from the trusted HTTPS quorum service, while DET takes them from SPV; the proof and signature verifier is the same. DET's own end-to-end discovery on mainnet was not run.

Existing data

The upstream V019 migration adds an asset-lock operation identifier; prior V001–V018 migration sources are unchanged, and rc.8 changes no migration. Forward migration must preserve wallet, identity, key, protection, and history data. The previous V018 reader cannot open the upgraded storage: rollback requires a pre-upgrade copy. No in-place downgrade compatibility is claimed.

Profiles opened by #1028's side-branch dependency are a separate case: its Core transaction accounting migration differs from this pin's V019. The current bridge does not recognize that history; the upgrade is safely refused as incompatible.

Scope limits

• Identity-to-Platform inflated actual-fee display is separately tracked as MemCan 0bf85881-633b-421d-b4c0-e0b4eee736dc.
• Live name-registration/voting retests are excluded at the user's request.
• DET's own end-to-end identity discovery on mainnet (SPV quorum keys) was not run; the SDK path was verified live (see Mainnet compatibility).

Validation

• Library tests: 3879 passed. UI (kittest): 503 passed. Archived-profile migration matrix: 64 passed.
• Clippy --all-features --all-targets -- -D warnings and pinned formatting pass; the dependency ancestry/migration-fingerprint guard passes.
• The protocol 13 client-table snapshot is re-recorded for the one additive verifier entry from #5515.
• Crypto byte parity checked, including a BLS signature vector through the real identity signer; approved migration fixture bytes preserved.
• No live funded tests or GUI network flows were run.
• Validated commit: 786584817fafc9b4d0c4fbaaebb38797f67a8678.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

PR Hygiene · 6be15c9

• Bots — coderabbitai skipped after the window · thepastaclaw requested changes — dismiss the review or push a fix
• Self-review — not asked of a bot author
• Build green
• Approvals
  • files with no dedicated owner (AGENTS.md, Cargo.lock, Cargo.toml and 154 more) — lklimek

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]

Important

Review skipped

We couldn't safely recover the incremental review. No full review was started, and the last reviewed checkpoint was preserved. Retry later, or explicitly request a full review by commenting @coderabbitai full review.

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

Use the checkbox below for a quick retry:

• 🔍 Trigger review

Walkthrough

The change adds protocol v14 support for key limits, scoped signing, once-per-identity token distributions, document action fees, and contract fee pots. It also adds typed error mappings, feature gates, storage, UI flows, tests, and platform dependency pins.

Changes: Protocol v14 contracts and fees

Layer / File(s)	Summary
Document fee agreements and validation src/model/fee_estimation.rs, src/backend_task/document.rs, src/ui/contracts_documents/document_action_screen.rs	Document actions now quote, confirm, validate, and transmit action-fee agreements. Optional token costs can be omitted.
Contract fee pots src/backend_task/contract.rs, src/backend_task/contract_fee_pots.rs, src/ui/contracts_documents/contract_fee_pots_screen.rs, src/ui/mod.rs	Backend tasks fetch and claim contract fee pots. A feature-gated Fee Pots screen displays balances and claim status.
Feature gates, errors, and platform state src/context/feature_gate.rs, src/backend_task/error.rs, src/backend_task/platform_info.rs, src/wallet_backend/*	Protocol v14 capabilities, upstream error mappings, epoch refresh behavior, withdrawal warnings, and token-operation rejection classification are added.
Dependency pins and supporting records Cargo.toml, scripts/migration-fixtures/*, docs/user-stories.md, CLAUDE.md	Platform dependencies and migration fingerprints use the new revision. User stories and error-message guidance are updated.

Identity key limits and signing usability

Layer / File(s)	Summary
Key-limit rules and scoped selection src/model/identity_key_limits.rs, src/model/identity_key_usability.rs, src/model/qualified_identity/*	Key budget and expiry validation, limit raises, live-key reconciliation, signing scopes, caveats, and usability-aware key selection are added.
Backend key-limit operations src/backend_task/identity/*, src/backend_task/mod.rs	Backend tasks fetch remaining budgets and raise reviewed limits while checking live key state and signer usability.
Identity key UI src/ui/identity/keys/*, src/ui/helpers.rs	Key creation supports limits and expiry. Key details display remaining budgets and raise-limit controls. Key choosers display scoped caveats.
Scoped signing integration src/backend_task/dashpay/*, src/ui/dashpay/*, src/ui/contracts_documents/*, src/ui/identity/*, src/ui/tokens/*	Signing-key lookups use KeyRequirements, SigningScope, and live key records across identity, DashPay, contract, and token actions.

Once-per-identity token distribution

Layer / File(s)	Summary
Distribution rules and validation src/model/token.rs, src/context/feature_gate.rs, src/backend_task/tokens/*	Once-per-identity amounts are parsed and represented as version 1 distribution rules. Registration rejects them when the network lacks support.
Claim persistence and backend recording src/context/contract_token_db.rs, src/backend_task/tokens/claim_tokens.rs	Per-identity claim timestamps are stored locally after successful claims. Node refusals are not recorded as successful claims.
Token creator and token views src/ui/tokens/tokens_screen/*	The token creator exposes the distribution, validates its amount, includes its fee, and displays the configuration in token information.
Claim experience src/ui/tokens/claim_tokens_screen.rs, src/ui/tokens/*	The claim screen supports once-per-identity distributions, shows local claim hints, allows dismissing hints, and uses contract-scoped signing keys.

Priority: Normal

Estimated code review effort: 5 (Critical) | ~90 minutes

Merge Risk: High · up to ddbe5

Changing networks or document targets can leave stale values active and cause valid operations to fail or target the wrong context. These state-reset and key-selection issues should be fixed before merging.

Pre-merge checks: 4 · 1

Failed checks: 1 warning

Check name	Status	Explanation	Resolution
Docstring Coverage		Docstring coverage is 68.37% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 332 functions across 50 files. (13 skippe…	Write docstrings for the functions missing them to satisfy the coverage threshold.

Passed checks: 4 passed

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 clearly summarizes the main change: adding Platform protocol version 14 support with the v5.1-dev SDK.
Description Check		Check skipped - CodeRabbit’s high-level summary is enabled.

Full details: Docstring Coverage

Explanation

Docstring coverage is 68.37% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 332 functions across 50 files. (13 skipped: 4 unsupported, 9 over the file limit.)

Resolution

Write docstrings for the functions missing them to satisfy the coverage threshold.

✨ Finishing Touches: 💡 1

📝 Generate docstrings: 💡

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

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

_{Comment @coderabbitai help to get the list of available commands.}

[thepastaclaw]

⛔ Final review complete — 2 blocking finding(s) (commit 6be15c9) · triage: critical · Phase 2 only (no Phase 1 for this repository)

[github-actions]

Waiting for bot review — coderabbitai not yet · thepastaclaw requested changes — dismiss the review or push a fix. 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 2 only (no Phase 1 for this repository)

The current head still has one blocking correctness issue: a successful key-limit update broadcasts a fee-paying transition but only persists the changed key, leaving the locally displayed identity balance stale. Three additional non-blocking issues remain around claim-hint persistence, typed error payloads, and protocol-version cache fallback. CI reports successful tests, Clippy, formatting, and pin checks; PR Hygiene is still pending.

🔴 1 blocking | 🟡 3 suggestion(s)

4 finding(s) not shown inline (GitHub refused the PR diff as too large)

🔴 Blocking: Refresh or persist the identity balance after a successful limits raise
src/backend_task/identity/key_limits.rs:128-140

update_key_limits(...).await broadcasts a fee-paying identity transition, but the success path persists only the returned public key through persist_raised_key. The upstream operation returns the rewritten key rather than a refreshed identity balance, so the local identity record retains its pre-transition balance. KeyInfoScreen then reloads that stale record, which can overstate the credits available for later fee-paying operations. Persist the post-transition balance or fetch a proved identity/balance before reporting success.

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

🟡 Suggestion: Do not silently discard a failed once-per-identity claim-hint write
src/backend_task/tokens/claim_tokens.rs:114-128

After a once-per-identity claim succeeds and is proof-backed, a failure from record_once_per_identity_claim is only logged while the task still returns the ordinary success result. The claim is irreversible, while this local record prevents the UI from offering the same claim again. Losing the record can cause a later session to offer another attempt that Platform refuses and may charge. Preserve the persistence failure in a typed success-with-warning result or a dedicated post-claim error that clearly says the claim succeeded but the local record was not saved.

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

🟡 Suggestion: Keep node-supplied contract-authoring details in typed sources
src/backend_task/error.rs:2916-2951

DocumentImmutablePropertyChanged, ReferencedDocumentTypeNotDeletable, and DocumentActionFeesWithoutModeration copy node-supplied names and paths into String fields even though each variant already preserves the complete Box<SdkError> source and intentionally omits those values from Display. The duplicated untrusted strings weaken the typed TaskError boundary and can be accidentally exposed if formatting changes later. Remove the redundant fields unless callers need structured values; otherwise retain the diagnostic information only in the typed source.

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

🟡 Suggestion: Do not serve a cached contract from the wrong protocol version
src/context/system_contracts.rs:62-85

SystemContractsCache::get accepts an exact requested PlatformVersion, but a failed reload logs the mismatch and returns the previously cached set. context_provider::resolve_data_contract uses this result during proof verification, so a protocol-14 request can receive protocol-13 system contracts if loading the requested version fails. Version-specific contract resolution should fail closed or propagate a typed load error instead of silently mixing protocol-version-specific schemas.

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

Review provenance

Source: reviewer 1: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 2: gpt-6.1-sol (agent: phase2-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: rust-quality); final verifier: gpt-6.1-sol (agent: sol-verifier, role: final-verifier)

• Triage: critical by gpt-6.1-sol (effort low) — This large cross-cutting diff changes cryptographic signing and key handling in wallet and identity code, peer-facing protocol serialization and verification, funds movement and fee operations, and storage migration compatibility, including files such as src/wallet_backend/det_signer.rs, src/backend_task/identity/key_limits.rs, src/backend_task/protocol_13_transitions.rs, and src/context/mod.rs.
• Phase 1 reviewers: not run (disabled for this repository)
• 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 — rust-quality (completed, effort xhigh); agent phase2-reviewer, gpt-6.1-sol — general (completed, effort xhigh); agent phase2-reviewer, gpt-6.1-sol — rust-quality (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 `src/backend_task/identity/key_limits.rs`:
- [BLOCKING] src/backend_task/identity/key_limits.rs:128-140: Refresh or persist the identity balance after a successful limits raise
  `update_key_limits(...).await` broadcasts a fee-paying identity transition, but the success path persists only the returned public key through `persist_raised_key`. The upstream operation returns the rewritten key rather than a refreshed identity balance, so the local identity record retains its pre-transition balance. `KeyInfoScreen` then reloads that stale record, which can overstate the credits available for later fee-paying operations. Persist the post-transition balance or fetch a proved identity/balance before reporting success.

In `src/backend_task/tokens/claim_tokens.rs`:
- [SUGGESTION] src/backend_task/tokens/claim_tokens.rs:114-128: Do not silently discard a failed once-per-identity claim-hint write
  After a once-per-identity claim succeeds and is proof-backed, a failure from `record_once_per_identity_claim` is only logged while the task still returns the ordinary success result. The claim is irreversible, while this local record prevents the UI from offering the same claim again. Losing the record can cause a later session to offer another attempt that Platform refuses and may charge. Preserve the persistence failure in a typed success-with-warning result or a dedicated post-claim error that clearly says the claim succeeded but the local record was not saved.

In `src/backend_task/error.rs`:
- [SUGGESTION] src/backend_task/error.rs:2916-2951: Keep node-supplied contract-authoring details in typed sources
  `DocumentImmutablePropertyChanged`, `ReferencedDocumentTypeNotDeletable`, and `DocumentActionFeesWithoutModeration` copy node-supplied names and paths into `String` fields even though each variant already preserves the complete `Box<SdkError>` source and intentionally omits those values from `Display`. The duplicated untrusted strings weaken the typed `TaskError` boundary and can be accidentally exposed if formatting changes later. Remove the redundant fields unless callers need structured values; otherwise retain the diagnostic information only in the typed source.

In `src/context/system_contracts.rs`:
- [SUGGESTION] src/context/system_contracts.rs:62-85: Do not serve a cached contract from the wrong protocol version
  `SystemContractsCache::get` accepts an exact requested `PlatformVersion`, but a failed reload logs the mismatch and returns the previously cached set. `context_provider::resolve_data_contract` uses this result during proof verification, so a protocol-14 request can receive protocol-13 system contracts if loading the requested version fails. Version-specific contract resolution should fail closed or propagate a typed load error instead of silently mixing protocol-version-specific schemas.

[Claudius-Maginificent]

Re the thepastaclaw review of 9742faa56 (findings not shown inline). All four checked against the code and the pinned Platform source; all four held and are fixed:

• 🔴 Balance after a key limits raise: confirmed. The update pays a fee, but update_key_limits returns only the rewritten key and its proof holds nothing more. Fixed in cb38dba: after an accepted raise, the task reads the identity's proved balance and stores it in the same record write as the key. If that read fails, the raise is not reported as failed: the key is stored, and KeyLimitsRaisedButBalanceNotRefreshed tells the user to refresh the identity. A failed save still maps to KeyLimitsRaisedButNotSaved.
• 🟡 Once-per-identity claim record: fixed in e2f6d53. A failed record write after a successful claim maps to the typed TokensClaimedButClaimNotRecorded (storage error as #[source]), which says the tokens were claimed and not to claim this token again with this identity.
• 🟡 Node-supplied strings in error variants: no caller used them structurally. Removed in cd8706b: the unproven names and paths now live only in the typed source_error; the identifiers stay. The injection test now goes through the real consensus-error conversion.
• 🟡 Wrong-version system contracts: fixed in dd4c2cd. The verifier path uses SystemContractsCache::try_get, which returns the exact requested version or the load error; the context provider reports that error as a data contract failure, so verification fails closed. The app's own reads keep their logged fallback so the UI stays usable.

Each fix carries a regression test.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

[github-actions]

Waiting for bot review — coderabbitai not yet · thepastaclaw requested changes — dismiss the review or push a fix. 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 2 only (no Phase 1 for this repository)

The main protocol-14 implementation and all 28 prior findings are addressed, and the current test, clippy, and platform-pin checks pass. Two new correctness issues remain: numeric capability gates accept unknown future protocol versions, and concurrent epoch refreshes can overwrite newer fee and protocol state with stale data.

🔴 1 blocking | 🟡 1 suggestion(s)

2 finding(s) not shown inline (GitHub refused the PR diff as too large)

🔴 Blocking: Fail closed for unknown future protocol versions in capability gates
src/context/feature_gate.rs:77-89

These capability checks compare the raw connected protocol number directly with activation thresholds. AppContext::adopt_epoch_info stores the protocol number from a proved epoch, while the pinned SDK deliberately ignores unknown protocol versions for its own ratchet and can still verify the response using the newest known verifier tables. If a valid response reports protocol 15, these >= 14 checks enable key-limit updates, once-per-identity distributions, fee-pot claims, and shielded operations even though this build has no protocol-15 definitions. The contract-bound and non-transferable checks already use PlatformVersion::get_optional and fail closed; the numeric gates need the same known-version check.

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

🟡 Suggestion: Do not let an older epoch refresh overwrite newer protocol and fee state
src/backend_task/platform_info.rs:594-598

refresh_current_epoch is used by multiple asynchronous paths, including platform-information refreshes and document-action-fee refusals. A response proving an older epoch can complete after a newer response, but adopt_epoch_info unconditionally replaces both the fee multiplier and protocol version. This can regress the connected protocol from 14 to 13 and replace current fee estimates with stale values. Store the adopted epoch index and only update epoch-derived state when the fetched epoch is at least as new; protocol-version adoption should also remain monotonic.

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

Review provenance

Source: reviewer 1: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 2: gpt-6.1-sol (agent: phase2-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) — This is a large cross-cutting change that directly modifies cryptographic signing and key handling, peer-facing protocol deserialization and verification, funds movement, and storage migration paths across files such as src/wallet_backend/det_signer.rs, src/context_provider.rs, src/backend_task/identity/key_limits.rs, and migration-related code.
• Phase 1 reviewers: not run (disabled for this repository)
• 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 — rust-quality (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 `src/context/feature_gate.rs`:
- [BLOCKING] src/context/feature_gate.rs:77-89: Fail closed for unknown future protocol versions in capability gates
  These capability checks compare the raw connected protocol number directly with activation thresholds. `AppContext::adopt_epoch_info` stores the protocol number from a proved epoch, while the pinned SDK deliberately ignores unknown protocol versions for its own ratchet and can still verify the response using the newest known verifier tables. If a valid response reports protocol 15, these `>= 14` checks enable key-limit updates, once-per-identity distributions, fee-pot claims, and shielded operations even though this build has no protocol-15 definitions. The contract-bound and non-transferable checks already use `PlatformVersion::get_optional` and fail closed; the numeric gates need the same known-version check.

In `src/backend_task/platform_info.rs`:
- [SUGGESTION] src/backend_task/platform_info.rs:594-598: Do not let an older epoch refresh overwrite newer protocol and fee state
  `refresh_current_epoch` is used by multiple asynchronous paths, including platform-information refreshes and document-action-fee refusals. A response proving an older epoch can complete after a newer response, but `adopt_epoch_info` unconditionally replaces both the fee multiplier and protocol version. This can regress the connected protocol from 14 to 13 and replace current fee estimates with stale values. Store the adopted epoch index and only update epoch-derived state when the fetched epoch is at least as new; protocol-version adoption should also remain monotonic.

[Claudius-Maginificent]

Re the thepastaclaw review of dd4c2cd59 (findings not shown inline). Both checked against the code and the pinned Platform source; both held and are fixed:

• 🔴 Unknown future protocol versions: fixed in db4c7ca. Every protocol capability now reads the connected version through PlatformVersion::get_optional, so a version this build does not define (or one not fetched yet) fails closed, the same as the contract-bound and non-transferable gates. At this pin rs-platform-version defines protocols up to 15, so 15 keeps the gates open and 16 closes them; the regression test pins both sides.
• 🟡 Out-of-order epoch refreshes: fixed in f65cc81. The context records the adopted epoch index and adopts a proved epoch only if it is at least as new, under one lock covering the check and both stores. The protocol version only moves up, including on the DPNS-fetch fallback. Each network has its own context; rebuilding the connection (new endpoints, e.g. a reset devnet) forgets the adopted epoch so its epochs are compared afresh.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

[github-actions]

Waiting for bot review — coderabbitai not yet · thepastaclaw requested changes — dismiss the review or push a fix. 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 2 only (no Phase 1 for this repository)

The connection rebuild resets only the adopted epoch index, while retaining the cached protocol version and fee multiplier and carrying the old protocol version into the replacement SDK. In-flight epoch requests against the old SDK can also adopt stale state after the rebuild, so a lower-protocol or reset network may temporarily expose unsupported operations or use stale fee data. All build, test, clippy, and platform-pin checks passed on this head; only the non-code PR Hygiene check remains in progress.

🔴 1 blocking

1 finding(s) not shown inline (GitHub refused the PR diff as too large)

🔴 Blocking: Do not let an older epoch refresh overwrite newer protocol and fee state
src/context/mod.rs:1257-1275

Reinitializing the SDK carries self.sdk.load().protocol_version_number() into the replacement SDK and then calls forget_adopted_epoch(), but that method clears only the epoch index. The cached platform_protocol_version and fee multiplier therefore survive a connection rebuild. If the new endpoints serve protocol 13 or a reset devnet, protocol-14 capability gates can remain open, the replacement SDK can continue constructing and validating at the stale protocol version, and fee estimates can use the previous network's multiplier. There is also a cross-generation race: run_backend_task captures an Arc to the old SDK before awaiting refresh_current_epoch; if that response completes after the swap and epoch reset, it can become the first adoption for the new connection and install stale fee/protocol state. Reset all connection-derived protocol and fee state and initialize the replacement SDK from the configured network minimum, then associate epoch adoption with a connection generation or SDK identity so responses from the previous generation are rejected.

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

Review provenance

Source: reviewer 1: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 2: gpt-6.1-sol (agent: phase2-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) — This large, cross-cutting diff changes cryptographic signing and key handling, peer-facing protocol deserialization and verification, funds movement and fee-related operations, and wallet storage migrations in files including src/wallet_backend/det_signer.rs, src/model/qualified_identity/mod.rs, src/context/mod.rs, and src/backend_task/migration/*.rs.
• Phase 1 reviewers: not run (disabled for this repository)
• 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 — rust-quality (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 `src/context/mod.rs`:
- [BLOCKING] src/context/mod.rs:1257-1275: Do not let an older epoch refresh overwrite newer protocol and fee state
  Reinitializing the SDK carries `self.sdk.load().protocol_version_number()` into the replacement SDK and then calls `forget_adopted_epoch()`, but that method clears only the epoch index. The cached `platform_protocol_version` and fee multiplier therefore survive a connection rebuild. If the new endpoints serve protocol 13 or a reset devnet, protocol-14 capability gates can remain open, the replacement SDK can continue constructing and validating at the stale protocol version, and fee estimates can use the previous network's multiplier. There is also a cross-generation race: `run_backend_task` captures an `Arc` to the old SDK before awaiting `refresh_current_epoch`; if that response completes after the swap and epoch reset, it can become the first adoption for the new connection and install stale fee/protocol state. Reset all connection-derived protocol and fee state and initialize the replacement SDK from the configured network minimum, then associate epoch adoption with a connection generation or SDK identity so responses from the previous generation are rejected.

[Claudius-Maginificent]

Re the thepastaclaw review of f65cc81a4 (finding not shown inline). Confirmed: a rebuild carried the old SDK's protocol version and kept the cached protocol version and fee multiplier, and an epoch read in flight on the old SDK could become the new connection's first adoption. Fixed in c7e037b:

• A rebuild now starts like a cold start. The replacement SDK begins at the network minimum (the carried-version seed is gone), and reset_connection_state bumps a connection generation, forgets the adopted epoch, and resets the protocol version to unknown and the fee multiplier to the default. Capabilities fail closed until the new connection proves its version.
• Epoch reads capture the generation and check they run on the current SDK before they are sent; adoption (and the DPNS-fetch protocol fallback) is dropped for an old generation or a replaced SDK. The SDK is swapped before the generation is bumped, so a read that sees the new generation also sees the new SDK.
• rebuild_connection, used by both the settings rebuild and the automatic DAPI refresh, reads the new connection's epoch right away, so the closed window lasts one round trip.

Regression tests cover the reset and a stale-generation read being dropped.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

[github-actions]

Waiting for bot review — coderabbitai not yet · thepastaclaw requested changes — dismiss the review or push a fix. 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 2 only (no Phase 1 for this repository)

The protocol-14 integration and the previously reported fixes are present at the reviewed head, and the code, test, clippy, and pin-guard checks reported by CI are successful. One blocking concurrency defect remains: connection rebuilding publishes the replacement SDK before clearing protocol and fee state, allowing backend tasks to observe a new SDK paired with stale connection metadata.

🔴 1 blocking

1 finding(s) not shown inline (GitHub refused the PR diff as too large)

🔴 Blocking: Publish the replacement SDK only after resetting connection-scoped protocol state
src/context/mod.rs:1333-1341

reinit_core_client_and_sdk stores the replacement SDK and only then calls reset_connection_state. Backend tasks snapshot the SDK independently in run_backend_task, while capability gates and fee estimation read the separately cached protocol version and fee multiplier. A task can therefore start after self.sdk.store(...) but before reset_connection_state(), using the new network's SDK with the previous connection's protocol capabilities and fee state. For example, a protocol-14 capability can remain enabled briefly while the task operates through a replacement protocol-13 connection, and stale fee multipliers can be applied to new-connection work. The epoch generation checks do not make ordinary SDK snapshots and connection-scoped state atomic. Synchronize rebuilding with task snapshots, or introduce a shared generation/state snapshot that tasks validate before performing work; merely swapping the two calls would move the mismatch window rather than eliminate it.

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

Review provenance

Source: reviewer 1: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 2: gpt-6.1-sol (agent: phase2-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) — This large cross-cutting diff changes cryptographic signing and key handling, peer-facing protocol deserialization and verification, funds-moving wallet operations, and storage migration behavior in files including src/wallet_backend/det_signer.rs, src/backend_task/identity/key_limits.rs, and src/context/mod.rs.
• Phase 1 reviewers: not run (disabled for this repository)
• 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 — rust-quality (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 `src/context/mod.rs`:
- [BLOCKING] src/context/mod.rs:1333-1341: Publish the replacement SDK only after resetting connection-scoped protocol state
  `reinit_core_client_and_sdk` stores the replacement SDK and only then calls `reset_connection_state`. Backend tasks snapshot the SDK independently in `run_backend_task`, while capability gates and fee estimation read the separately cached protocol version and fee multiplier. A task can therefore start after `self.sdk.store(...)` but before `reset_connection_state()`, using the new network's SDK with the previous connection's protocol capabilities and fee state. For example, a protocol-14 capability can remain enabled briefly while the task operates through a replacement protocol-13 connection, and stale fee multipliers can be applied to new-connection work. The epoch generation checks do not make ordinary SDK snapshots and connection-scoped state atomic. Synchronize rebuilding with task snapshots, or introduce a shared generation/state snapshot that tasks validate before performing work; merely swapping the two calls would move the mismatch window rather than eliminate it.

[Claudius-Maginificent]

Re: Publish the replacement SDK only after resetting connection-scoped protocol state (src/context/mod.rs) — fixed in 6be15c9.

reinit_core_client_and_sdk now calls replace_connection(new_sdk), which, under the epoch_adoption lock, bumps the connection generation, clears the epoch, resets the protocol version and fee multiplier, and only then stores the new SDK. Epoch adoption and the DPNS fallback read the generation and "is this the current SDK" together under the same lock (connection_snapshot_for), so a read begun on the old SDK is dropped.

The reset is written before the new SDK is published, so any task that loads the new SDK is guaranteed to see the reset protocol version and fee multiplier. The only remaining combination is a task that already held the old SDK seeing the reset state: an unknown protocol closes every protocol capability, and the default fee multiplier is the value the new connection uses until its first proved epoch. Nothing is enabled or priced from stale data that way; it fails closed.

Test: context::tests::the_new_sdk_is_published_only_after_the_connection_state_is_reset asserts, at the point between the two halves of the swap, that a visible new SDK implies protocol 0 and the default fee; it failed on the previous order.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

[github-actions]

Waiting for bot review — coderabbitai not yet · thepastaclaw requested changes — dismiss the review or push a fix. 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 2 only (no Phase 1 for this repository)

The final head fixes all 32 previously verified findings, and the reported Test Suite, Clippy, formatting, and platform-pin checks pass. Two new blocking correctness issues remain: a confirmed key-limit raise can be overwritten by legacy-recovery dispatch, and a stale epoch refresh can be reported as successful without updating the fee cache.

🔴 2 blocking

2 finding(s) not shown inline (GitHub refused the PR diff as too large)

🔴 Blocking: A confirmed key-limit raise can be dropped when legacy recovery dispatches in the same frame
src/ui/identity/keys/key_info_screen.rs:950-966

pending_raise.take() removes the confirmed raise and immediately produces a non-None action. The following legacy-recovery check or restore can also produce an action, but AppAction::BitOrAssign replaces an existing action instead of accumulating both tasks. When that happens, the recovery task is dispatched while the raise has already been removed from pending_raise; raise_in_flight remains true and its progress banner cannot be cleared because no raise result or error will arrive. The comment above this code only addresses the budget read versus recovery collision and does not prevent this newer raise-versus-recovery collision. Dispatch only one operation per frame, or retain the raise until it is actually returned as the dispatched action.

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

🔴 Blocking: Do not report a fee refresh when the epoch was read from a stale connection
src/backend_task/document.rs:170-172

refresh_current_epoch returns Ok(epoch_info) even when the epoch was not adopted. It captures the connection generation and SDK identity before awaiting the request, then ignores the boolean result from adopt_epoch; a connection rebuild or a newer adopted epoch can therefore cause the cache update to be rejected while the caller still treats the refresh as successful. fee_refusal_after_refresh then returns DocumentActionFeeMultiplierRose, whose message tells the user that the contract fee has been updated, although the cached multiplier is unchanged. Make the refresh report whether adoption occurred, and only use the updated-fee error when the current connection actually adopted the epoch.

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

Review provenance

Source: reviewer 1: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 2: gpt-6.1-sol (agent: phase2-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: rust-quality); final verifier: gpt-6.1-sol (agent: sol-verifier, role: final-verifier)

• Triage: critical by gpt-6.1-sol (effort low) — This large, cross-cutting diff changes cryptographic signing and key handling, wallet and identity funds operations, peer-facing protocol responses, and storage migration behavior across files such as src/wallet_backend/det_signer.rs, src/model/qualified_identity/mod.rs, and src/context/mod.rs.
• Phase 1 reviewers: not run (disabled for this repository)
• 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 — rust-quality (completed, effort xhigh); agent phase2-reviewer, gpt-6.1-sol — general (completed, effort xhigh); agent phase2-reviewer, gpt-6.1-sol — rust-quality (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 `src/ui/identity/keys/key_info_screen.rs`:
- [BLOCKING] src/ui/identity/keys/key_info_screen.rs:950-966: A confirmed key-limit raise can be dropped when legacy recovery dispatches in the same frame
  `pending_raise.take()` removes the confirmed raise and immediately produces a non-None action. The following legacy-recovery check or restore can also produce an action, but `AppAction::BitOrAssign` replaces an existing action instead of accumulating both tasks. When that happens, the recovery task is dispatched while the raise has already been removed from `pending_raise`; `raise_in_flight` remains true and its progress banner cannot be cleared because no raise result or error will arrive. The comment above this code only addresses the budget read versus recovery collision and does not prevent this newer raise-versus-recovery collision. Dispatch only one operation per frame, or retain the raise until it is actually returned as the dispatched action.

In `src/backend_task/document.rs`:
- [BLOCKING] src/backend_task/document.rs:170-172: Do not report a fee refresh when the epoch was read from a stale connection
  `refresh_current_epoch` returns `Ok(epoch_info)` even when the epoch was not adopted. It captures the connection generation and SDK identity before awaiting the request, then ignores the boolean result from `adopt_epoch`; a connection rebuild or a newer adopted epoch can therefore cause the cache update to be rejected while the caller still treats the refresh as successful. `fee_refusal_after_refresh` then returns `DocumentActionFeeMultiplierRose`, whose message tells the user that the contract fee has been updated, although the cached multiplier is unchanged. Make the refresh report whether adoption occurred, and only use the updated-fee error when the current connection actually adopted the epoch.