What Are You Approving on FraxSwap?

Pre-flight: read the request, not the button

Before an ERC-20 swap can move a token, a wallet normally asks its owner to approve one of three things: account access, a spending allowance, or a specific transaction. On the FraxSwap trading interface, the right choice depends on what the wallet actually displays—not on the button label. An approval lets a named contract spend up to a stated amount; it is not the swap itself.

Fraxswap is a constant-product automated market maker with an embedded Time-Weighted Average Market Maker (TWAMM), so a request may concern an immediate swap or an order that executes over time. As Frax documentation puts it, “Fraxswap is the first live TWAMM implementation.” That distinction matters: a long-term order is an instruction to begin execution, while an allowance is continuing permission for a contract to pull a token later.

Use this checklist before signing anything:

• Confirm the network. The wallet network, the token contract, and the contract receiving permission must all belong together. A familiar token symbol on the wrong network is not the same asset.
• Read the request type. “Connect,” “Approve,” “Permit,” and “Confirm swap” have different consequences. Do not treat every wallet pop-up as a routine confirmation.
• Check the spender or verifying contract. It should be a contract you expect to use for the selected chain and route—not the address of a random website or wallet.
• Check the amount and expiry. Exact input amount is easier to reason about than an unlimited amount; a permit with a near expiry is easier to contain than one with no practical end date.
• Stop on unreadable data. A wallet that cannot identify the token, network, contract, amount, or action has not provided enough information to sign.

An ERC-20 allowance is permission in the token standard that lets a named spender withdraw up to a set amount from the owner’s balance through transferFrom. The token contract records that permission on-chain. It does not give the spender access to every asset in the wallet, but it can remain usable after the current swap is finished if a balance remains.

A permit under ERC-2612 is a signed authorization that sets an ERC-20 allowance without first sending a separate approve transaction. Its typed message should identify the owner, spender, value, nonce, deadline, chain and token contract. The signature can be submitted by another address before its deadline, so “no gas charged for this signature” does not mean “no spending authority was granted.”

What a FraxSwap signature can actually authorize

Wallet connection is the narrowest request. It usually allows the site to see the selected public address, chain and balances exposed by the wallet. It should not move tokens, create an allowance, or cost gas. A message signature may prove address control for a session, but it still deserves inspection because a signature can carry structured instructions.

Wallet request	What it authorizes	What to inspect
Connect wallet	Account access for the interface	Correct site, selected account and network
Approve	Token allowance for one spender	Token, spender and maximum amount
Permit	Signed allowance that can be submitted later	Owner, spender, value, nonce, deadline and verifying token
Swap or create order	Execution of the trade itself	Input, output, recipient, minimum received, route and deadline

An approval transaction changes state at the token contract; the spender is commonly a router contract that later calls transferFrom. For that reason, the contract shown beside “spender” matters more than the web page’s visual branding. As of 31 July 2026, Frax’s V2 address page lists router entries across 7 networks, including Ethereum, Fraxtal, Arbitrum, Avalanche, BSC, Optimism and Polygon. Compare against the entry for the exact chain and router type, rather than copying an address from social media.

SetApprovalForAll deserves separate treatment. It is generally associated with NFT standards such as ERC-721 and ERC-1155, where it can authorize an operator over a collection. It is not the normal request for swapping an ERC-20 token. If that wording appears when the intended action is a simple ERC-20 swap, stop and establish why.

Execute the swap in the order the wallet shows it

1. Set the trade before approving. Select the input token, output token, amount and network first. Review price impact and slippage tolerance. A pool fee is part of the trade economics; network gas pays for the transaction. Neither is an extra permission.
2. Use the smallest sensible authorization. If the interface offers an exact amount, that limits the token contract’s allowance to the amount needed for this trade. If a larger allowance is chosen for convenience, the user should understand it survives the swap until spent, reduced, revoked, or replaced.
3. Review the execution call. The actual swap should show the contract destination and a transaction value. Its meaningful fields are the input amount, route or token path, recipient, deadline and amountOutMin. The minimum-output condition limits how little can be received before the transaction reverts; it does not promise the displayed quote.

The practical recommendation is to begin from the FraxSwap trading interface, which is the page used to construct the trade, then compare every wallet prompt with the transaction it proposes. A URL in a pop-up, a direct message, or a search advertisement is not a substitute for reading the contract destination inside the wallet.

For a TWAMM order, add one more check: duration. Fraxswap’s core follows Uniswap V2-style xy=k pool mechanics, but a TWAMM order spreads execution across blocks rather than completing as one immediate fill. Read the order duration, input amount, cancellation path and withdrawal path before creating it. A completed transaction can mean the order was created successfully, not that all output is already in the wallet.

After confirmation, verify both the trade and the permission

A green wallet notification only means the submitted transaction did not revert. Verify the transaction in a block explorer or wallet activity view: an approval should show the intended token, owner, spender and allowance; a swap should show the expected input leaving and output arriving. Check the actual received amount against the transaction details, not only the pre-trade quote.

Then inspect the remaining allowance. If the approval was larger than the swap input, the router may still retain permission to spend the unused balance of that token. Reducing the allowance to zero, or to an amount genuinely needed for future swaps, is the clean post-action step when broad approval is no longer wanted.

Finally, keep the distinction simple: a connection reveals an address, an allowance authorizes future token pulls, a permit signs that allowance, and a swap or TWAMM order executes a defined trade. Reading those four categories before signing turns a vague wallet prompt into a decision with clear limits.