Smardex First Swap: Token Approval and Spending Limits
Smardex token approval gives a specified contract permission to transfer your chosen ERC-20 input token within an allowance. Approval alone doesn't exchange the token, reserve a quote or deliver an output asset. The swap instruction determines the trade, including its recipient and spending or output limits. A first swap may involve an approval transaction or a permit signature, while an existing allowance may make another approval unnecessary. Those authorization paths don't require an identical sequence of wallet transactions. Before signing, identify the token contract, spender and amount on the selected network, then distinguish the approval record from evidence that the swap completed.
Last updated ·An exact-input swap's allowance limits token access, while its minimum output sets a separate condition for successful execution.
The input token, spender and recipient
The input token's contract records the allowance for a particular owner and spender, so the contract's role matters when reviewing permission. Your account owns the tokens; the approved spender can request their transfer. The recipient receives the swap's output and can have a different address. With the direct router's wallet-funded ERC-20 path, the router calls the input token's
transferFrom
function to pay the pool during the swap. The pool can therefore receive your input tokens without being the spender that you approve.
A standalone ERC-20 approval transaction targets the token contract. Its arguments identify the spender and allowance, so the transaction's destination field doesn't identify the contract receiving spending authority. Read the decoded approval details alongside the swap request. The selected network must match the token balance and contract deployment. For a self-funded transaction, the account also needs the network's native asset for gas; holding enough input tokens doesn't cover that separate cost.
Direct approvals, token permits and Permit2
The authorization method can change the number and kind of wallet requests without changing the need for valid spending permission. An ordinary
approve
transaction writes an allowance on the token contract. A later router call can use that allowance, and adequate existing permission can cover another swap.
Smardex's Ethereum router exposes permit-enabled token swap functions that can apply an allowance and execute the trade in one transaction. This path requires an input token with the compatible permit format and an interface that exposes the function.
A permit signature authorizes an allowance change; signing doesn't itself record that change onchain. The transaction must successfully apply the permit, or sufficient allowance must already exist for the wallet-funded transfer. The Ethereum router catches a failed permit call and proceeds to the swap, whose wallet-funded ERC-20 transfer still needs adequate permission.
The Universal Router integrates Permit2, which adds another permission layer for transfers through that contract. The token owner needs a token-level allowance naming Permit2. In Permit2's allowance mode, a separate permission specifies the integrating spender's amount and expiration. A sufficient token-level allowance alone doesn't establish that spender's permission.
Smardex First Swap: What Token Approval Allows
- The input token, spender and recipient
- Direct approvals, token permits and Permit2
- What does a larger allowance change?
- A hypothetical swap with allowance left over
A direct-router approval doesn't automatically authorize a different spender or replace a required Permit2 approval. A permit signature can authorize future token spending even when signing itself doesn't require gas.
What does a larger allowance change?
A larger allowance expands how much the named spender can transfer from your input-token balance through the token's permission system. An ERC-20 allowance can authorize multiple transfers up to the approved amount. The swap doesn't have to consume the full allowance. A limited approval restricts the remaining authority if the spender later attempts another transfer. A maximum approval can leave much broader permission in place, including access to tokens that arrive later. Spending still requires an available token balance.
The swap's own limits determine which exchange terms you'll accept. An exact-input swap specifies the quantity to spend and a minimum output. An exact-output swap specifies the desired output and a maximum input. Permission must support the actual transfer; the allowance isn't a fee or the output amount. Increasing it won't make an expired trade valid or improve the pool's price. Approval alone also doesn't supply pool liquidity or stake tokens; those actions require their own execution.
A hypothetical swap with allowance left over
A hypothetical 83-token allowance leaves 20 tokens of spending permission after a successful 63-token exact-input swap through the direct router. Assume a compatible ERC-20 input token with ordinary finite-allowance accounting and no transfer charge. The account has enough input tokens and native currency for gas.
The approval records permission without transferring the input balance. The successful swap then pulls 63 tokens from the owner to fund the pool payment and delivers the output to the specified recipient. The token reduces the finite allowance by the amount spent:
83 - 63 = 20
input tokens. Those 20 tokens describe remaining authority, not a balance that the router holds for you.
Increasing the approval would enlarge the spending ceiling. Changing the swap's input would change how much allowance remains. Neither number determines the quantity of output tokens.
The approval record and the swap receipt
A confirmed approval establishes permission, while swap completion requires evidence of the actual exchange and its output recipient. A transaction hash alone can identify a pending submission. A separate approval transaction's success doesn't establish that a swap occurred. The direct Ethereum router rejects an exact-input swap whose output falls below its submitted minimum. A Universal Router transaction can permit selected commands to fail, so overall transaction success requires checking the intended swap's transfers and output.
A stop point before execution
Declining an unsigned request grants no new permission, although earlier approvals remain in place. Closing the browser doesn't revoke a recorded allowance. A confirmed ordinary approval can remain even when you never submit the swap. Changing that token's allowance for the same owner and spender requires an authorization update and can cost gas. Revocation doesn't reverse completed transfers or necessarily invalidate unused permit signatures. For an ordinary ERC-20 allowance reset, the replacement value is 0.
Smardex: the short answers
Will my first Smardex approval also cover a reverse swap?
An approval for a swap's input token doesn't automatically cover the token spent in a reverse swap. Reversing the trade changes which token the router must transfer. The reverse trade needs valid permission for its own input token and spender, through whichever supported authorization mechanism that trade uses.
Why can an allowance update include a zero reset?
A zero reset can reduce the ERC-20 allowance-change race when replacing existing nonzero permission. The standard recommends that interface pattern, though it doesn't require every token to enforce it. A later approval sets a replacement amount; it doesn't add that amount to the old allowance.
Can another account in my wallet use the same approval?
Another account has its own token allowances, even if the same wallet application manages both accounts. Permission attaches to the token owner's address and the spender within that token contract's state. Switching networks also changes the relevant state, so approval on one network doesn't establish spending permission on another.
Is token approval necessary for the Ethereum router's native ETH input?
The Ethereum router's native-ETH input functions can fund the swap from ETH sent with the call, without an ERC-20 approval for that ETH. The router wraps the required value into WETH for payment. A wallet-funded WETH input uses the ERC-20 authorization path instead, even though both assets relate to ETH.
What do token decimals change about an approval amount?
Token decimals change how a wallet displays the integer allowance that the contract stores. The raw amount uses that token's smallest units. Compare the approval and swap input in the same units, with the same token contract; a raw integer alone doesn't tell you the human-readable quantity. The decimals setting doesn't change the approved spender.
Does a token permit's deadline make its allowance expire?
An ERC-2612 permit deadline limits when someone can successfully apply the signed approval onchain, not how long the resulting allowance lasts. Once a valid permit sets the allowance, that permission follows the token's allowance rules. Permit2's allowance expiration is a separate field, so a token permit's deadline and a time-limited Permit2 allowance describe different constraints.