[QuantumExplorer]

Basic explanation

What this does: Android apps can now sync, send and accept DashPay private contact requests through the Kotlin SDK, over the same platform-wallet FFI the Swift SDK uses.

• The request is signed by the identity signer the app already uses for public requests.
• The wallet picks how an accepted request is replied to.
• Result codes 68 to 76 become typed errors.
• KotlinExampleApp:
  • shows a contact as pending while the wallet holds the pair for a private request;
  • shows a public request or accept that may have gone through as being checked, with no second one offered, until a DashPay sync settles it;
  • shows "setting up" (or the reason a restoration failed) while the wallet's private payments are not restored;
  • opens the shielded store when it activates the manager.

Value: parity with iOS for private contact requests.

Risks: low.

• No consensus change.
• New JNI exports and Kotlin wrappers. The public contact request bridges are unchanged.
• The Room handler now declares the private scan state capability (bit 15). Hosts that use it must open the shielded store when they activate the manager (see Breaking Changes).

Issue being fixed or feature implemented

Part of anonymous DashPay contact requests for 5.1, on top of #5812.

Known limit, tracked in #4270. Platform cannot yet prove to a client whether a state transition executed, or that it can no longer execute, so the wallet infers the outcome of an unconfirmed transition and holds notes and contact pairs until it has evidence it can verify itself. The result codes for unconfirmed outcomes and held pairs (18, 20, 71, 72, 76) and what the app shows for them follow from that. The handling is interim, as #5810's description explains; #4270 tracks the gap in the proofs and #5822 what the wallet needs from it.

What was done?

JNI (rs-unified-sdk-jni/src/dashpay.rs)

• syncPrivateContactRequests(walletHandle, coreSignerHandle, maxPages) returns the pass's six counters as a long[]. It destroys every returned request handle, since Kotlin reads the requests from Room.
• sendPrivateContactRequest(...) and acceptPrivateContactRequest(...):
  • built with the shielded feature;
  • the signer crosses as the SignerHandle the public sendContactRequest takes;
  • a negative account, or a shielded address that is not 43 bytes, is refused before anything crosses.
• acceptContactRequestReplyingInKind(...) is exported in every build.
• managedIdentityPrivateContact(identityHandle, contactId) returns how a contact's requests came, as JSON, or null.
• privatePairHeld(walletHandle, senderId, recipientId) bridges platform_wallet_get_private_pair_held.
• publicContactRequestUnconfirmed(walletHandle, senderId, recipientId) bridges platform_wallet_get_public_contact_request_unconfirmed (feat(swift-sdk): send, receive and accept DashPay private contact requests #5812).
• privateContactReadiness(walletHandle, identityId) returns four flags, in this order:
  • privatePaymentsRestored
  • privateStoreRead
  • unresolvedPrivatePayment
  • privatePaymentsRestoreFailed
• privatePaymentsRestoreFailure(walletHandle, identityId) returns the reason, or null.
• rs-unified-sdk-jni/src/persistence.rs wires the five scan state slots, only for a bridge that overrides the store, the load, the wallet list (onLoadPrivateContactScanStateWallets, ()[B, the 32-byte ids packed back to back) and the contact upsert.
• nativeCreate and nativeEffectivePersistenceCapabilityBits build the bridge's persistence through one helper (bridge_persistence): the declaration, the vtable, the account-writer restriction and the extension. The capability check therefore cannot drift from what a manager is created with.

Kotlin SDK

• Dashpay:
  • syncPrivateContactRequests(coreSignerHandle, maxPages) returns a PrivateContactSyncResult.
  • privateContact(ourIdentityId, contactId) returns how a contact's requests came.
  • privateRepliesPending(ourIdentityId, contactIds) returns the contacts whose pair the wallet holds, one pair-hold read per contact, as a send decides it.
  • publicContactRequestsUnconfirmed(ourIdentityId, contactIds) returns the contacts a public request to which awaits its outcome, one read per contact.
  • privateContactReadiness(ourIdentityId) returns a PrivateContactReadiness with privatePaymentsRestoreFailed.
  • privatePaymentsRestoreFailure(ourIdentityId) returns the reason, or null.
  • incomingContactRequest(ourIdentityId, senderId) (Swift's getIncomingContactRequest(senderId:)) gives an accept its request.
• PlatformWalletManager:
  • sendPrivateContactRequest(...), acceptContactRequestReplyingInKind(...) and acceptPrivateContactRequest(...) sit with the other shielded spends.
  • They use the manager's resolver and identity signer, behind the manager's teardown gate.
• DashSdkError.PlatformWallet types codes 68 to 76:
  • 68 PrivateContactRequestNeedsPrivateReply
  • 69 ShieldedBuildRequired
  • 70 ProtocolVersionNotActive
  • 71 PrivateContactRequestPending
  • 72 PrivateContactPaymentsNotRestored
  • 73 PrivateContactRecoveryUnsupported
  • 74 PrivateContactStoreNotRead, retryable
  • 75 SdkPinnedBelowProtocolVersion
  • 76 PublicContactRequestUnconfirmed
• Scan state persistence:
  • NativePersistenceBridge.CAPABILITY_PRIVATE_CONTACT_REQUEST_SCAN_STATE is 1L shl 15. Bit 14 is ASSET_LOCK_SHIELDED_RECIPIENTS, which Android does not declare.
  • Room goes to version 16 (MIGRATION_15_16, two tables, a new DAO).
  • The handler declares the capability with atomic changesets, stages the writes into the changeset round, and purges them with the wallet, except a position record marked unresolved (see below).
  • onLoadPrivateContactScanStateWallets lists every wallet with stored positions (walletIdsWithPositions).
• Each new wrapper's KDoc names its Swift counterpart.

// The one accept a host calls: the wallet replies the way the request came.
manager.acceptContactRequestReplyingInKind(walletId, request).close()

// Whether to offer a send or reply to this contact.
val held = dashpay.privateRepliesPending(ourIdentityId, listOf(contactId)).isNotEmpty() ||
    dashpay.publicContactRequestsUnconfirmed(ourIdentityId, listOf(contactId)).isNotEmpty()

// Whether the wallet's private payments are restored, and why not.
val readiness = dashpay.privateContactReadiness(ourIdentityId)
if (readiness.privatePaymentsRestoreFailed) {
    val reason = dashpay.privatePaymentsRestoreFailure(ourIdentityId)
}

KotlinExampleApp

• DashPaySyncHelpers.acceptIncomingContactRequest accepts with acceptContactRequestReplyingInKind. Requests and Add Contact's collision accept use it.
• Pull-to-refresh on Requests also reads the private store.
• There is no "Send privately" toggle yet. A public send to a private contact shows the wallet's refusal (68), as the iOS app does with its toggle off.
• AppContainer opens the shielded store before loadPersistedWallets.
• SendTransactionScreen's shielded path reads 20 as it reads 18: "may have gone through, do not retry" (shieldedOperationMayHaveGoneThrough).
• Requests and Add Contact read both of the wallet's holds per contact (contactRequestHolds): the private one and the public one.
  • While either holds a pair, the row or Add Contact offers no Accept, Ignore or Send.
  • A public hold shows "This request may have gone through; it is being checked. The next sync settles it."
  • A send or accept that returns 20, or 76, shows the same at once, never a retry.
  • The Requests pull-to-refresh runs the DashPay sync, which settles the hold first, and then reads it. Add Contact gets a "Check again" button that does the same. Both also read again when any DashPay sync pass ends, the background one included.
• The invitation claim's contact request reads 18, 20 and 76 as "may have gone through; it is being checked", not as a failure.

Parity

• docs/sdk/sdk-parity-manifest.json has dashpay.private_contact_requests and dashpay.private_contact_request_scan_state, with the FFI symbols in shared_symbols, including platform_wallet_get_private_pair_held, platform_wallet_get_public_contact_request_unconfirmed and platform_wallet_get_private_payments_restore_failure. The public hold's tests are listed as its verification.
• Both hosts are partial. A send or accept needs a protocol version 15 network with shielded funds, and no gate is recorded yet.
• PARITY_SUMMARY.md is regenerated with scripts/check_sdk_parity_manifest.py --write-summary.

Current behaviour

The wallet rules are the same as on iOS (#5812, #5810).

• A read before every request. Every contact request and acceptance first reads DashPay's private store for the identity to its end. While that read cannot finish, the request is refused with 74 and nothing is sent.
• A pair is held until the wallet can prove what happened. The pair stays held while:
  • a private request is in flight;
  • it is paid and not yet read back; or
  • the shielded store's payment journal keeps it unresolved.
  • An endpoint's refusal does not free it. It is freed when the entry is read back or the payment's anchor is proven pruned, up to about 1100 blocks after it was recorded.
  • Dashpay.privateRepliesPending reads this per pair, applying discharged journal records first.
• A public request that may have gone through holds the pair (feat(platform-wallet): send, receive and accept DashPay private contact requests #5810). A public send or accept whose broadcast may have been delivered returns 20, and the wallet keeps the pair held with the signed transition.
  • Until a DashPay sync settles it, every request or accept to the pair, and removing the sender identity, is refused with 76. Nothing new is signed.
  • The sync settles it first: a request found is recorded as sent; a nonce proved used frees the pair; otherwise it broadcasts the same bytes again and keeps the hold.
  • Dashpay.publicContactRequestsUnconfirmed reads the hold per pair.
• Wallet readiness (72). While a wallet's private payments are not restored, every contact request is refused with 72. Causes:
  • a wallet published with no shielded store configured, by a persister that declares the scan state;
  • a wallet that bound a shielded account in an earlier process;
  • a restoration that failed or waits for a busy store;
  • an identity loaded with its unresolved-payment marker;
  • an identity added to a wallet registered or loaded under an id whose record the host kept marked after an earlier wallet under it was removed.
• Opening the store at activation. AppContainer opens the shielded store before persisted wallets load.
  • If that fails, AppContainer.shieldedStoreFailure holds why, and the screens show it.
  • The bind-time calls stay. On the same path they do not wait on the store.
• Recovery on a DashPay refresh. A restoration can fail after the store opened, and then configureShielded succeeds with nothing recorded. So on every refresh of Requests or Add Contact, while the store did not open or the readiness reads not restored:
  • the app calls AppContainer.configureShieldedStoreAgain; on a store already open, that is the wallet's own retry of every wallet still held, and it never waits on a busy store;
  • it then reads the readiness the screen shows, followed by the pair-hold reads;
  • the app clears or rebuilds no hold itself.
  • While the payments stay unrestored, the effect keeps refreshing for as long as the screen is shown: every 3 s for the first minute, then every 15 s, with no last refresh. It also refreshes when a shielded sync pass ends.
  • A scan can hold the store for minutes, and the wallet runs the restoration it deferred only once the scan frees it, so the gate lifts when that restoration completes, with no isBound change.
  • Each refresh is local: in-memory reads, and a repeat configure that queues at most one deferred restoration per wallet.
  • It stops when the readiness reads restored or the screen leaves the composition.
  • No bind, restart or submitted request is needed.
• A marked record outlives its wallet. The Room handler purges a wallet's scan state with the wallet, except a position record marked unresolved: the private payment it stands for may still execute.
  • It keeps that record until a record stored cleared for the same wallet and identity replaces it.
  • The next load hands it back as retained, so a wallet registered again under the id holds the identity it names (72) until a restoration shows the payment resolved.
• Reads. The readiness and pair-hold reads each apply discharges themselves, so the screens read them in either order. A screen's read always covers both holds: a read of the private hold alone would offer a public request awaiting its outcome again.
• A failed read is kept apart from "nothing pending": PrivateRepliesPendingSnapshot keeps the last good snapshot and leaves the controls off until a read succeeds.

What KotlinExampleApp does for each code (ContactRequestOutcomesTest pins these, as ContactRequestOutcomesTests.swift does):

Code	Meaning	KotlinExampleApp
16	For a note spend: refused before anything was sent; notes released	Ordinary failure; retry offered
18	A note spend that may have been delivered; notes kept	"This may have gone through"; no retry offered
20	A state transition the SDK could not confirm after a possible acceptance; the spend contract keeps it for a private send or accept, and a public one returns it through the blanket conversion, the wallet holding the pair until a DashPay sync settles it	"This may have gone through"; no retry offered. A public one's row or Add Contact shows "This request may have gone through; it is being checked", with no Accept or Send, until publicContactRequestsUnconfirmed no longer lists it
68	A public send or accept to a contact whose requests went privately	Failure message
69	A private reply on a build without shielded	Failure message
70	The network is proven below protocol version 15	Failure on a send; a private refresh stays quiet
71	The pair is held for a private request	Row or Add Contact shows pending; Accept, Ignore and Send off; private sync offered; controls come back only when the per-pair read says free
72	The wallet's private payments are not restored	Every contact waits, showing "Setting up this wallet's private payments", or why the restoration failed, or why the shielded store did not open; each refresh asks the wallet to retry, and a timer refreshes again while the screen is shown (every 3 s for a minute, then every 15 s)
73	The persister cannot keep the scan state with atomic changesets	Storage configuration error
74	The private store read did not finish	"Still reading private contact requests"; no pending row; the user may try again
75	The SDK is pinned below the protocol version	Developer-facing message, on a send and on a refresh
76	A public request to the pair awaits its outcome; nothing was signed	"This request may have gone through; it is being checked"; no retry offered; a DashPay sync is started, and the controls come back only when publicContactRequestsUnconfirmed no longer lists it

a private reply whose payment the network refused
  the wallet keeps the pair held; the row shows the pending notice, with Accept off
  once the payment's anchor is proven pruned, privateRepliesPending no longer lists it and the next reload re-enables Accept
a public accept whose result cannot be confirmed (20)
  the row shows "This request may have gone through; it is being checked", with Accept off
  a refresh whose sync fails, or does not settle it, keeps the row so; the private-pending read is empty and changes nothing
  a second accept is not offered; one made anyway is refused with 76, nothing signed
  once a sync records the request, the pair moves to Contacts; once it proves the nonce used, Accept comes back
opening the shielded store fails at activation
  every contact shows "The shielded store could not be opened: <reason>"
  each DashPay reload tries again; once it opens, the wallet restores its payments and the notice goes away

How Has This Been Tested?

• cargo fmt --all -- --check: clean.
• cargo clippy -p rs-unified-sdk-jni --all-targets -- -D warnings, with default features and with --no-default-features: clean.
• cargo test -p rs-unified-sdk-jni --lib: 63 passed. These include:
  • the readiness flags in the order Kotlin reads them;
  • the restore-failed flag on its own;
  • the sync counter order;
  • handle release;
  • the five scan state slots wired together, and the wallet list unpacking.
• Gradle on the JBR runtime:
  • :sdk:kspDebugKotlin, :sdk:compileDebugKotlin, :sdk:compileDebugAndroidTestKotlin and :app:compileDebugKotlin compile.
  • DashSdkErrorTest: 36 passed, including codes 68 to 76 (shouldReportAnUnconfirmedPublicRequestByItsOwnCode).
  • RegistrationCoordinatorTest: 12 passed.
  • PrivateContactScanStatePersistenceTest (9 passed) and PlatformWalletPersistenceHandlerTest (162 passed, including the declared mask 0x8bbf without bit 14) ran on the previous head; the last merge changed neither, nor the persistence they test.
  • ContactRequestOutcomesTest: 29 passed. They cover one or more per code above (20 by shouldKeepAnUnconfirmedStateTransitionPending, for the contact request and the shielded send), plus the refresh recovery:
    • shouldRetryARestorationThatFailedAfterTheStoreOpenedOnARefresh
    • shouldShowTheReadinessReadAfterTheRetry
    • shouldNotAskTheWalletToRetryWhenThePaymentsAreRestored
    • shouldOpenTheStoreAgainWhileAStoreFailureIsRecorded
    • shouldKeepRefreshingWhileARestorationStaysDeferred (past the first minute, 200 refreshes)
    • shouldStopRefreshingWhenRestoredOrWhenTheScreenGoesAway
  • And the public hold:
    • shouldKeepAPublicAcceptHeldAfterCode20ThroughAnEmptyPrivateReadAndAnUnsettledSync: the accept returns 20; a sync after which the read fails, and one after which the private-pending read is empty and the public hold stands, both keep the row held; a second accept is not offered, and one made anyway is refused with 76 and shows no error to retry; once the read says settled, Accept comes back.
    • shouldShowARefusedUnconfirmedPublicRequestAsBeingChecked (76).
    • shouldKeepAnUnconfirmedSubmissionAReadDidNotCover.
    • shouldReadBothHoldsAndTellAFailedReadFromNothingHeld: the read covers both holds; a failure reads as unread, and a cancellation is rethrown.
• python3 scripts/check_sdk_parity_manifest.py --write-summary: passes, with 29 capabilities.
• Not run:
  • FfiSmokeTest and DashDatabaseMigrationTest locally: they need an emulator, and both compile here; CI's emulator job runs FfiSmokeTest;
  • build_android.sh, with or without --no-shielded;
  • a test that restarts a process;
  • a UI run on an emulator, including the timed refresh;
  • a private send or accept against a protocol version 15 network.

Breaking Changes

For a host built on #5812:

• Kotlin error types. DashSdkError.PlatformWallet (a sealed class) gains subclasses for codes 68 to 76. An exhaustive when over it must handle them.
• Room schema. The Room database moves to version 16 (MIGRATION_15_16 adds two tables).
• The shielded store must open first. The Room persistence handler now declares the private scan state (bit 15) with atomic changesets. The wallet then holds every wallet loaded or created while no shielded store is configured (72). A host using the handler must call configureShielded when it activates the manager, before loading wallets, and call it again after a failure.
• Native library. The Kotlin SDK calls JNI symbols that only a native library built from this branch has.
• Wallet deletion keeps marked records. deleteWalletData no longer removes a scan state position record marked unresolved. It stays until a cleared record for the same wallet and identity replaces it.
• A public request awaiting its outcome. From feat(platform-wallet): send, receive and accept DashPay private contact requests #5810, a public send or accept that returns 20 holds the pair, and later ones get 76. A host shows the pair from publicContactRequestsUnconfirmed as well as privateRepliesPending, and runs the DashPay sync to settle it.
• Unknown identities. The readiness, pair-hold, public-unconfirmed and restore-failure reads answer an identity the wallet does not hold with code 7, from feat(platform-wallet): send, receive and accept DashPay private contact requests #5810, which Kotlin maps to DashSdkError.NotFound, where it used to be the catch-all 99.
• Bridge overrides. A NativePersistenceBridge that keeps scan state must also override onLoadPrivateContactScanStateWallets, or the JNI wires none of its scan state slots and the capability is not attested.

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
• If I added or changed a system contract's document schemas, I checked the contract viewer link posted on this pull request

For repository code-owners and collaborators only

• I have assigned this pull request to a milestone

🤖 Generated with Claude Code

PR Hygiene · ec344df

• Bots — thepastaclaw not yet — /skip-bots proceeds without the ones not yet reported
• Self-review — post /self-reviewed
• Reviewer requests paused — your 5 review slots are occupied; this PR is excluded from reviewers' queues. Required approvals still count without a slot.
• Build running
• Approvals
  • files with no dedicated owner — you own it
  • kotlin-sdk (packages/kotlin-sdk/KotlinExampleApp/app/src/main/java/org/dashfoundation/example/di/AppContainer.kt, packages/kotlin-sdk/KotlinExampleApp/app/src/main/java/org/dashfoundation/example/ui/dashpay/AddContactScreen.kt, packages/kotlin-sdk/KotlinExampleApp/app/src/main/java/org/dashfoundation/example/ui/dashpay/ClaimInvitationSheet.kt and 23 more) — HashEngineering
  • rs-platform-wallet-ffi (packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md) — HashEngineering or ZocoLini or 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]

Caution

Review failed

The pull request is closed.

• 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 ec344df. Normal review starts when eligible; priority review starts as soon as a slot is available.

[thepastaclaw]

Final validation — Phase 1 + Phase 2

Verified the findings against head 655d1e3. The acceptance fallback introduces wallet orchestration in the Kotlin example app contrary to the repository's ownership rules; native-handle cleanup also lacks nonempty regression coverage. This was a static review with no local builds or tests; current CI reports the Kotlin SDK build and emulator tests passing, with only the automated review pending.

🔴 1 blocking | 🟡 1 suggestion(s)

Review provenance

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

• Triage: normal by gpt-6.1-sol (effort low) — The change spans JNI, Kotlin wrappers, and example-app flows, but delegates private sends, signing, and acceptance to existing platform-wallet implementations rather than changing intricate funds-movement or cryptographic logic.
• 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)
• Fresh verifier: gpt-6.1-sol — final-verifier; agent sol-verifier
• Phase 2 reviewers: gpt-6.1-sol — general (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — architecture-layering (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — ffi-engineer (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — rust-quality (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — security-auditor (completed, effort high); 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/kotlin-sdk/KotlinExampleApp/app/src/main/java/org/dashfoundation/example/ui/dashpay/DashPaySyncHelpers.kt`:
- [BLOCKING] packages/kotlin-sdk/KotlinExampleApp/app/src/main/java/org/dashfoundation/example/ui/dashpay/DashPaySyncHelpers.kt:73-76: Move public-to-private acceptance orchestration into platform-wallet
  This catch re-reads the incoming request and automatically switches the Accept action from a refused public operation to a shielded-funded private operation. Rust enforces the privacy refusal, but the host still owns the subsequent workflow. The book's "Where code goes" section explicitly assigns mobile DashPay orchestration to rs-platform-wallet, and "FFI and mobile SDKs hold no business logic" requires hosts to call an existing Rust operation rather than make wallet decisions. Copying the Swift example's fallback adds another host-owned implementation; that existing implementation does not exempt the new code from the rule. Add a Rust acceptance entry point with the required spending context, resolve the incoming request and select the public/private route there, then expose it through FFI/JNI so this helper makes one call. Keep the explicitly public API's refusal. Test the unified workflow offline at its Rust owner, including public success, private acceptance, unrelated-error propagation, missing requests, and already-reciprocated requests; the current error-mapping and JNI-binding tests do not exercise this routing.

In `packages/rs-unified-sdk-jni/src/dashpay.rs`:
- [SUGGESTION] packages/rs-unified-sdk-jni/src/dashpay.rs:1520-1525: Exercise cleanup of populated request-handle arrays
  The only cleanup test supplies ContactRequestHandleArray::empty(), so neither the per-handle destruction loop nor the allocated-buffer release executes. The FFI array-free function deliberately frees only the buffer: individual requests remain in CONTACT_REQUEST_STORAGE until contact_request_destroy removes them. Removing the destruction loop would therefore leak requests on every nonempty private sync while the new tests still passed. Add a JVM-independent test that creates at least two real handles through contact_request_create, puts them in a boxed-slice allocation matching the FFI array contract, and invokes release_contact_request_handles. Assert the returned count, null pointer and zero count afterward, and that getters reject both released handles. Use real registered handles rather than fabricated values so the test verifies destruction as well as buffer cleanup.

[thepastaclaw]

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

The two prior findings are fixed: populated request-array cleanup is covered, and public/private reply selection now belongs to platform-wallet. One blocking regression remains: both example-app acceptance flows unconditionally invoke a shielded-only JNI symbol, breaking public acceptance on the documented transparent-only build. This was a static verification at 13f4784; current CI reports the Kotlin build/emulator job passing with shielded enabled, policy checks passing, and the review check pending.

🔴 1 blocking

Review provenance

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

• Triage: normal by gpt-6.1-sol (effort low) — The cross-language change is substantial, but it adds JNI/Kotlin adapters to existing private-contact operations rather than changing funds-movement, cryptographic, signature, or consensus logic itself.
• 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)
• Fresh verifier: gpt-6.1-sol — final-verifier; agent sol-verifier
• Phase 2 reviewers: gpt-6.1-sol — general (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — architecture-layering (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — ffi-engineer (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — rust-quality (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — security-auditor (completed, effort high); 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/kotlin-sdk/KotlinExampleApp/app/src/main/java/org/dashfoundation/example/ui/dashpay/DashPaySyncHelpers.kt`:
- [BLOCKING] packages/kotlin-sdk/KotlinExampleApp/app/src/main/java/org/dashfoundation/example/ui/dashpay/DashPaySyncHelpers.kt:66-67: Preserve public acceptance on transparent-only builds
  Requests and Add Contact now route every acceptance through this call, including ordinary public requests. However, `DashpayNative.acceptContactRequestReplyingInKind` has its JNI export behind `#[cfg(feature = "shielded")]` in `rs-unified-sdk-jni/src/dashpay.rs:1497`, and the underlying FFI export is similarly gated. The Kotlin README explicitly supports `./build_android.sh --no-shielded`, which disables that JNI feature. On that build, accepting a public request previously used the available public bridge but now throws `UnsatisfiedLinkError`; neither `mapNativeErrors` nor the screens' `catch (e: Exception)` handlers catches it. Make unified acceptance available without shielded support, retaining route selection in platform-wallet and returning a typed unsupported error only when a private reply requires the missing capability. Add public-acceptance coverage against the transparent-only native library: the passing emulator job builds with shielded enabled, while a Rust no-default-features compile cannot detect this missing-symbol failure at runtime.

[thepastaclaw]

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

Verified the findings against head 89d2330. All three prior findings are fixed, but one blocking issue remains: screen-local pending state allows an uncertain private acceptance to initiate another paid reply after navigation or through another screen. This was a static review; no local builds or tests were run, and the current Kotlin emulator build/test check passes.

🔴 1 blocking

Review provenance

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

• Triage: normal by gpt-6.1-sol (effort low) — The cross-language feature is substantial but primarily marshals existing private-contact operations and handles application outcomes, without changing the underlying funds movement, cryptography, or signing algorithms.
• 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)
• Fresh verifier: gpt-6.1-sol — final-verifier; agent sol-verifier
• Phase 2 reviewers: gpt-6.1-sol — general (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — architecture-layering (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — ffi-engineer (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — rust-quality (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — security-auditor (completed, effort high); 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/kotlin-sdk/KotlinExampleApp/app/src/main/java/org/dashfoundation/example/ui/dashpay/ContactRequestsScreen.kt`:
- [BLOCKING] packages/kotlin-sdk/KotlinExampleApp/app/src/main/java/org/dashfoundation/example/ui/dashpay/ContactRequestsScreen.kt:95-98: Retain unresolved private acceptances in wallet-owned state
  After `ShieldedSpendUnconfirmed`, this `remember` set prevents another acceptance only while this composition survives. Leaving and reopening Requests clears it, and Add Contact's separate `unconfirmedNotice` is not shared with Requests. The incoming-only row therefore offers Accept again before the first submission is reconciled.

  The Rust path does not prevent the second payment: `send_private_contact_request` returns at `pay(entry).await?` before recording an outgoing request, while `needs_private_reply` and `accept_contact_request_replying_with` recognize only recorded outgoing or established requests. `reserve_notes_covering` excludes the original spend's reserved notes but allows another spend from other available notes. A second acceptance can consequently seal a different entry and pay another fee while the first transition can still land. `kickDashPaySync` runs the ordinary DashPay sweep, which does not read the private request store; the native shielded-sync poke likewise does not establish the missing contact-level pending state.

  Retain the unresolved reply in `rs-platform-wallet`, keyed by wallet and identity pair and associated with its pending spend. Subsequent accepts must return the pending outcome rather than build another reply until reconciliation establishes whether replacement is safe. Expose that Rust-owned status to both screens instead of relying on their lifetimes. Add owner-level coverage where an ambiguous first payment is followed by another acceptance before private-store reconciliation, including reconstruction/re-entry, and assert that the payment callback runs only once. This PR introduces private acceptance into both screens and adds this local guard, so the gap is in scope; wallet-level retry decisions also belong in Rust under the book's mobile-orchestration ownership rule.

[thepastaclaw]

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

Verified head 2890ed8: wallet-owned acceptance routing, transparent-only exports, and populated-handle cleanup coverage address three prior findings. One blocking issue remains: process restart loses the contact-level reservation for an unresolved private reply, allowing another fee-paying acceptance before reconciliation. This was a static review with no local builds or tests; the current Kotlin SDK build and emulator check passed.

🔴 1 blocking

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

• Triage: normal by gpt-6.1-sol (effort low) — The substantial cross-language change adds JNI and Kotlin orchestration for existing wallet operations rather than changing funds movement algorithms, cryptography, signing rules, or consensus itself.
• 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)
• Fresh verifier: gpt-6.1-sol — final-verifier; agent sol-verifier
• Phase 2 reviewers: gpt-6.1-sol — general (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — architecture-layering (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — ffi-engineer (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — rust-quality (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — security-auditor (completed, effort high); 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/kotlin-sdk/KotlinExampleApp/app/src/main/java/org/dashfoundation/example/ui/dashpay/ContactRequestsScreen.kt`:
- [BLOCKING] packages/kotlin-sdk/KotlinExampleApp/app/src/main/java/org/dashfoundation/example/ui/dashpay/ContactRequestsScreen.kt:165-169: Retain unresolved private acceptances in wallet-owned state
  (existing thread: https://github.com/dashpay/platform/pull/5813#discussion_r4507144191)
  The fresh wallet snapshot fixes screen re-entry, but it reports no pending reply after process restart. `DashPayState.pending_private_replies` is memory-only, and `Dashpay.privateRepliesPending` explicitly documents the reset at `Dashpay.kt:400–407`. Restoring the persisted incoming request does not restore this reservation, so Requests offers Accept again while Rust's `needs_private_reply` still sees no outgoing counterpart.

  This can duplicate fees even when the first payment was confirmed: `send_reserved_private_contact_request` completes `pay(entry).await?`, fails to read the entry back from the private store, and returns `PrivateContactRequestPending` without recording an outgoing request. If the process then restarts before successful private-store reconciliation, another acceptance reserves the now-empty recipient slot, seals a fresh entry, and pays again. The ambiguous `ShieldedSpendUnconfirmed` path has the same gap while the original signed spend remains recoverable. Shielded note reservations protect only the selected notes; `reserve_notes_covering` can fund the second submission from other available notes. The private store is an append-only log, not contact-level deduplication.

  The #5810 restoration work must be consumed here before this newly exposed acceptance flow is safe across process death. Persist the wallet/identity/recipient reservation and its entry/spend association before broadcast, restore it before pending reads and submissions become available, and retain it until authoritative reconciliation establishes settlement or safe replacement. Keep Kotlin as a consumer of that Rust-owned status. Add owner-level restart coverage for both an ambiguous payment and a successful payment followed by failed read-back, asserting that another acceptance does not invoke payment again.

[thepastaclaw]

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

Verified the findings against head e050ab0. All four prior findings are fixed, but the new pending-state presentation helper still converts failed reads into an apparent absence of pending requests; a separate KDoc placement nitpick also remains. This was static verification only: the current Kotlin SDK build and emulator tests pass, and the review check is pending.

🔴 1 blocking | 💬 1 nitpick(s)

Review provenance

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

• Triage: normal by gpt-6.1-sol (effort low) — The cross-language implementation is substantial, but its JNI exports, Kotlin wrappers and UI state handling delegate signing and private transfers to existing wallet functionality rather than changing funds movement, cryptography or key-handling logic themselves.
• 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)
• Fresh verifier: gpt-6.1-sol — final-verifier; agent sol-verifier
• Phase 2 reviewers: gpt-6.1-sol — general (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — architecture-layering (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — ffi-engineer (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — rust-quality (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — security-auditor (completed, effort high); 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/kotlin-sdk/KotlinExampleApp/app/src/main/java/org/dashfoundation/example/ui/dashpay/DashPaySyncHelpers.kt`:
- [BLOCKING] packages/kotlin-sdk/KotlinExampleApp/app/src/main/java/org/dashfoundation/example/ui/dashpay/DashPaySyncHelpers.kt:56-57: Preserve unavailable pending state instead of reporting no pending requests
  This catch makes an operational read failure indistinguishable from a successful snapshot containing no pending replies. The SDK already returns an empty result for an unmanaged identity while propagating other failures, and accessing a closed ManagedPlatformWallet throws. If a pending-state refresh fails, ContactRequestsScreen replaces walletPendingIds with this empty set, removing the pending notice and restoring Accept/Ignore; AddContactScreen similarly sets recipientPending to false and enables Send. No successful reconciliation established that the pending submission cleared. Rust's reservation and recovery guards prevent another private payment, but they do not make this report of wallet state correct. Preserve a distinct unavailable/error result, retain the last successful pending snapshot, and keep pending-sensitive controls unavailable until a successful read. Add coverage for a successful pending snapshot followed by a failed read, separately from a successful empty snapshot.

In `packages/kotlin-sdk/sdk/src/main/kotlin/org/dashfoundation/dashsdk/ffi/DashpayNative.kt`:
- [NITPICK] packages/kotlin-sdk/sdk/src/main/kotlin/org/dashfoundation/dashsdk/ffi/DashpayNative.kt:331-338: Attach the in-kind acceptance KDoc to its declaration
  This acceptance documentation is immediately followed by another KDoc block and managedIdentityPrivateContact, while acceptContactRequestReplyingInKind appears below both managed-identity reads without its documentation. Move this block directly above the acceptance declaration's @Suppress annotation so its requestHandle/account links and reply-routing explanation document the intended API.

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

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