security(frontend): transaction simulation before submission

[samjay8]

Problem

When a user submits a transaction (accept offer, repay invoice), the transaction is broadcast directly to the network. If the parameters are wrong or the state has changed since the page loaded, the transaction fails on-chain and the user loses the network fee. There is no way to preview the effects before committing.

Proposed Solution

1. Before broadcasting, call simulateTransaction on the Soroban RPC
2. Parse the simulation result to show: expected state changes, token movements, and success probability
3. Show a confirmation dialog with the simulation results before final submission
4. If simulation indicates failure, block the submission and show the error
5. Cache simulation results briefly (5 seconds) to avoid duplicate RPC calls

Files to modify

• invofi/apps/frontend/src/lib/simulate.ts (new) — simulation helper
• invofi/apps/frontend/src/components/common/SimulateConfirm.tsx (new) — confirmation dialog
• invofi/apps/frontend/src/lib/contract.ts — wrap calls with simulation

Acceptance Criteria

• Every high-value transaction (accept, repay, cancel) shows simulation results before submission
• Simulation shows expected token movements and state changes
• Failed simulations block submission with error explanation
• Simulation cached for 5 seconds to avoid duplicate calls
• Works on testnet and mainnet

Complexity: high-complexity

[Rayhab2000]

Please assign this issue to me

[Fury03]

Hi Maintainer, I'd like to take this up.

Proposed approach.

A framing point that shapes this: on Soroban you already have to simulate before submitting — simulateTransaction is how you get the footprint and resource fees. So the value here isn't adding a simulation call; it's surfacing what that call already returns and interpreting it correctly.

• Parse effects, don't just check success. Read the simulation's return value, stateChanges/ledger-entry diffs, and events to derive concrete token movements (who pays/receives what) and state changes for the confirmation dialog — not a vague "looks ok." This is the part that makes the preview trustworthy.
• Honest failure vs "probability." A simulation error is a hard block with the decoded contract error surfaced (accept/repay/cancel each have distinct failure modes). I'd avoid presenting a false "success probability" number — simulation is deterministic against current ledger state; the real risk is state drift between simulate and submit, so I'd re-simulate immediately before broadcast (or bound it tightly) and warn if the footprint/result changed, rather than imply a passing sim guarantees success.
• Caching that can't go stale-dangerous. The 5s cache keyed on the exact call params, invalidated the moment inputs change, so a cached "ok" never masks changed parameters.

Wiring: simulate.ts helper wrapping the RPC, SimulateConfirm.tsx dialog rendering the parsed effects, contract.ts routing accept/repay/cancel through simulate-then-confirm. Works testnet + mainnet via the configured RPC.

[grantfox-oss]

🦊 GrantFox — @Fury03 has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #216)
2. Your PR will be reviewed by the Stellar-VaultLink maintainers

Good luck! Track your progress on GrantFox.