Retrying deposit after wallet rejection causes invoke_host_function: trapped

[cupicmarko]

Description

After rejecting a deposit in the wallet, retrying the same deposit causes the on-chain transaction to fail with:

Deposit failed: transaction failed (resultXdr: AAAAAAABfxD/////AAAAAQAAAAAAAAAY/////gAAAAA=)

Decoding the result XDR shows:

{"fee_charged":"98064","result":{"tx_failed":[{"op_inner":{"invoke_host_function":"trapped"}}]},"ext":"v0"}

invoke_host_function: trapped indicates the Soroban contract panicked during execution. This happens consistently when retrying a deposit that was previously rejected at the wallet signing step.

The likely cause is that local app/SDK state is mutated during transaction preparation (e.g., nullifiers computed, notes marked spent, Merkle tree updated) before the wallet confirms signing. When the user rejects, those local changes are not rolled back, so the retry builds a proof against an inconsistent state and the pool contract rejects it.

Acceptance criteria

• Rejecting a deposit in the wallet must be a no-op with respect to local state (notes, nullifiers, Merkle tree, indexes).
• Retrying a deposit immediately after a wallet rejection succeeds, assuming on-chain state is otherwise valid.
• Local state mutations happen only after a transaction is successfully submitted/confirmed, or are rolled back on rejection/failure.
• Add a regression test or e2e scenario covering reject-then-retry for deposits (and ideally transfers/withdrawals).

Documentation link(s)

• Deposit/transfer flow: app/js/ui/transactions.js
• State management / tx-planner: sdk/tx-planner/, sdk/state/
• Architecture overview: app/ARCHITECTURE.md

[cupicmarko]

Closed — opened prematurely before author review.