Skip to main content

​
Browser transaction lifecycle

  1. Resolve the active wallet through lib/wallet-adapter.ts and obtain its source account.
  2. Build the operation using the configured testnet passphrase and exact ScVal types.
  3. Prepare/simulate the transaction to derive authorization and Soroban resource requirements.
  4. Sign the prepared transaction using Freighter or the configured Privy bridge.
  5. Submit to Soroban RPC and poll the transaction hash for a terminal result.
  6. Refresh account, pool, and wallet state after confirmation.
The Privy adapter hashes the prepared Stellar transaction, requests a raw-hash signature from its bridge, and reconstructs signed XDR. A public read-source address can be used for read simulations without a wallet; it is not a funding or signing credential.

​
Status and retry behavior

A simulation result or submission response is not final confirmation. The service layer handles sequence/footprint races with bounded rebuild/retry paths. resubmitOnTryAgainLater resubmits the same signed envelope when the RPC queue declines an attempt. Inspect failed transaction diagnostics before retrying a business-rule rejection. Transaction progress is shared through lib/tx-progress.tsx and stores. Some operations pad simulated resource budgets to account for changes between simulation and execution. A timeout or missing history row does not prove the transaction failed; reconcile its hash and on-chain balances.

​
Multi-step strategies

Lite Mode tries an atomic deposit/borrow/Blend-supply path for eligible same-asset Blend strategies. It can fall back to separate transactions. Other strategies can deposit, borrow one or two assets, swap, and add liquidity in separate submissions. Confirmed earlier steps remain if a later step fails. closePosition withdraws/removes liquidity and repays available debt legs; it is not the AccountManager close_account lifecycle function. Copilot writes add their own plan approval, wallet binding, execution policy, and receipt flow. Do not assume every Copilot write uses the same browser signing path or that plan approval means on-chain success.

​
Source reference

  • mercury-stellar-backend/lib/stellar-utils.ts
  • mercury-stellar-backend/lib/wallet-adapter.ts
  • mercury-stellar-backend/lib/one-click-strategy.ts
  • mercury-stellar-backend/lib/copilot/handle.ts