AVALANCHE / Build
Frontend transaction UX
Build Avalanche wallet interfaces that distinguish approvals, execution and confirmed state changes.
Open raw MarkdownMARKDOWN SOURCE
--- name: avax-frontend description: Build Avalanche wallet interfaces that distinguish approvals, execution and confirmed state changes. --- # Frontend transaction UX Source review: 2026-09-06. Recheck network-dependent facts before use. 1. Display the selected network and asset identity before the primary action. Revalidate the connected chain and invalidate stale quotes when account, chain, input amount or token changes. 2. Model connection, network switching, allowance and execution as distinct stages. Read allowance before showing approval. Give each action its own pending/disabled state and prevent a double click from creating a second transaction. 3. Simulate the intended call before requesting a signature where the integration permits it. Explain expected asset movement, recipient, spender and fee budget. Never treat a simulation as a guarantee against intervening state changes. 4. Keep wallet rejection, submission, pending receipt, replacement, revert and confirmed success distinct. A returned hash starts tracking; it does not complete the flow. Reconcile the receipt and then refresh the relevant balances or application state. 5. On C-Chain use the intended network's explorer links; mainnet address links can use SnowScan. For an L1 use its operator-verified explorer instead of manufacturing a C-Chain link. 6. For interchain flows, show source confirmed and destination executed separately, with a recoverable pending/error state. Verify keyboard and mobile operation, including long addresses and wallet-return behavior. **Evidence to return:** observed state transitions, duplicate-submission protection, correct explorer/network links and tests for rejection, revert and stale data. Show fiat values only when the price and its freshness are available. ## Approval-to-swap sequence Read allowance → if needed, approve the intended spender and wait for its successful receipt → re-read allowance → refresh the quote and recheck account/chain → simulate the swap with current parameters → submit within authorization → wait for the successful swap receipt → reconcile token deltas. Abort or re-quote when the wallet, network or relevant quote inputs change during either wait. ## Primary sources - [Viem contract simulation](https://viem.sh/docs/contract/simulateContract) - [Avalanche Primary Network](https://build.avax.network/docs/primary-network) - [ICM delivery example](https://build.avax.network/docs/tooling/interchain-kit/icm-messaging) ## Exercise actual asynchronous and canonical state Inspect `examples/core/web/wallet-machine.mjs` and app.mjs. Run `node --test examples/core/wallet-machine.test.mjs` plus `node examples/core/verify.mjs` from the executable bundle root. The controlled adapter drives actual local deposits/withdrawals, mined reverts, nonce replacement/cancellation and reorg/orphaned-receipt reconciliation. Bind asynchronous reads to request/account/chain/input identity. Disable only actions with unmet current prerequisites and prevent duplicate sends. Preserve submitted activity under its original account after wallet changes. Reread allowance and simulate after approval rather than carrying old evidence forward. With the demonstrated ethers version, populate contract calldata then use signer.sendTransaction to preserve replacement-tracking metadata. A timeout is not permission for blind new-nonce retry. Resolve the original and any replacement, check receipt status and reconcile canonical state before success. `node examples/core/demo.mjs` serves the educational UI on loopback chain43113, not public Fuji. It implements custody, not yield/ERC4626, and does not test real wallet extensions. Use [Frontend Playbook](../frontend-playbook/SKILL.md) for hosting/deep links and [QA](../qa/SKILL.md) for accessible mobile/keyboard completion and explicit failure states.