To verify a FraxSwap swap worked, the trader needs its transaction hash; the expected proof is a confirmed receipt with status 0x1 and a matching output-token Transfer event to the trader’s wallet, while pending, reverted, and TWAMM orders require separate checks.

Four inputs make a FraxSwap check unambiguous

The trader should keep four details before judging the result:

• Transaction hash: the hexadecimal identifier created when the wallet submits the swap.
• Network: Ethereum, Fraxtal, or another supported EVM chain selected in the wallet.
• Wallet address: the account that should receive the output token.
• Trade terms: the input token, expected output token, amount, and minimum received after slippage.

The FraxSwap web app prepares a smart-contract transaction for the connected wallet; it does not itself become the final record of settlement. Frax Finance describes Fraxswap as a permissionless AMM built on Uniswap V2 with an embedded TWAMM, so the selected route and order type matter when interpreting what appears on-chain. The protocol’s official overview establishes that distinction.

A missing hash means there is nothing definitive to inspect yet. A hash on the wrong network can look absent even when the wallet did submit a transaction. The wallet address matters because a transfer to a different recipient can produce a successful receipt without delivering tokens to the intended account.

The route explains what the FraxSwap interface can and cannot prove

A green “submitted” or “processing” message proves only that the interface and wallet passed the transaction to the network. It does not prove that a validator included it in a block or that the contract call completed.

“A validator must pick your transaction and include it in a block in order to verify the transaction and consider it ‘successful’.” — Ethereum.org,

Transactions documentation

That is why the transaction hash is the key input. It lets the trader move from an app notification to an explorer record containing the receipt, block number, status, gas used, and emitted logs.

One receipt plus two token movements prove a normal fill

For a standard one-transaction AMM swap, the strongest practical check has two layers.

1. Read the receipt status. A mined receipt with status: 0x1 indicates that the EVM execution succeeded. A receipt with 0x0 indicates a reverted call. Etherscan’s transaction-receipt documentation shows the status field alongside the transaction logs.
2. Read the token movements. The logs should show the input token leaving the trader’s wallet and the output token moving to it, or to the recipient specified in the transaction. The token contract address, sender, recipient, and raw amount should match the intended trade.

The second layer prevents a common mistake: treating any successful transaction as a successful swap. ERC-20 approvals are separate contract calls. An approval can return 0x1 while moving no output token at all. Ethereum’s ERC-20 documentation explains that users can verify state-changing token actions through the transaction receipt or the Transfer event.

Amounts need attention because ERC-20 values are stored in base units. An explorer may show a raw integer while the wallet displays decimals. The trader should compare the decoded token amount, not the unconverted hexadecimal or integer field. The output recipient is equally important: the event should point to the intended wallet, not merely mention the correct token somewhere in the transaction.