How to Integrate ParaSwap Token Approvals Without Swap Failures

To add a ParaSwap token-swap flow to a dApp, treat it as three separate stages: identify the chain and token contracts, obtain a quote for the user’s address, then verify the input token’s allowance for the correct spender before building the swap transaction. Native assets do not use ERC-20 approvals; ERC-20 input tokens do. A safe default is to approve only the amount being sold and request a fresh quote after approval confirmation. This sequence prevents the common mistake of approving one contract and submitting the transaction to another.

Keep quoting, approval, and execution separate

A swap integration usually involves more than one blockchain transaction. The quote is an off-chain calculation that describes a possible route. The approval allows a contract to transfer the input token. The swap transaction then attempts to execute the quoted route under a minimum-output condition.

These stages should share the same core inputs:

• the connected wallet address;
• the active chain ID;
• the input token contract;
• the output token contract;
• the exact input amount; and
• the spender or router expected to transfer the input token.

If any of these values changes, treat the previous quote or allowance check as potentially stale. A user switching from one network to another is the obvious example, but changing accounts, token addresses, trade direction, or swap mode can create the same problem.

Use the token type to choose the first transaction

For a native asset such as the chain’s main currency, there is no ERC-20 allowance to read or set. The transaction must instead carry the correct native value, while the application verifies that the wallet has enough balance for both the swap amount and network gas.

For an ERC-20 token, read allowance(owner, spender) before asking the user to approve anything. The owner is the connected wallet. The spender is the contract that will pull the input token, not necessarily the contract that ultimately routes the trade to a liquidity venue.

Do not derive the spender from a remembered address or from a route’s exchange list. Obtain it from the current integration configuration or the relevant SDK method, then compare it with the address used in the transaction you are about to send.

Recheck the spender before building the swap

If the route has changed because the chain, token, account, amount, or execution mode changed, the prior allowance check no longer proves that the transaction can spend the intended asset. At that point, consult the protocol reference for this swap flow to re-establish the ParaSwap context before selecting an integration path. That reference does not replace a chain-specific allowance read, transaction simulation, or contract verification performed by your own application.

The implementation should then follow this order:

1. Read the wallet’s current chain and account.
2. Validate the input and output token addresses against the selected chain.
3. Request a quote using the same account that will sign the transaction.
4. Determine the spender associated with that quote or swap path.
5. Read the input token allowance for that spender.
6. Request approval only if the allowance is below the intended input amount.
7. Wait for the approval transaction to be mined.
8. Request a fresh quote or rebuild the transaction after approval.
9. Simulate or estimate the swap transaction before presenting the final signature request.

The final quote matters because approval consumes time and may alter the market conditions under which the original route was calculated. A quote that was valid before the approval transaction can become less attractive or fail its minimum-output requirement afterward.

Limit approvals and verify the transaction payload

Approving the exact trade amount reduces the amount a compromised or misconfigured spender could transfer later. Some applications choose a larger allowance to reduce repeated approval prompts, but that is a security and usability decision rather than a technical requirement. If a larger allowance is used, provide a clear reason and give users a way to review or revoke it.

Before the wallet signs the swap transaction, check that:

• the transaction’s chain ID matches the wallet’s active network;
• the sender matches the account used in the quote;
• the input amount is the intended raw token amount;
• the transaction value is correct for native assets and zero or otherwise expected for ERC-20 inputs;
• the recipient and beneficiary fields are not being replaced by untrusted input; and
• the minimum received amount reflects the user’s selected slippage policy.

Never treat a successful approval as proof that the swap will succeed. Approval only grants spending permission. The swap can still revert because the quote is stale, liquidity has changed, the minimum output is too strict, the wallet lacks gas, or the selected token behaves differently from a standard ERC-20.

Use a small test trade to isolate integration errors

For a new token or newly supported chain, test with an amount small enough that a failed transaction does not create material loss. First confirm the approval receipt, then inspect the swap transaction’s sender, destination, calldata, value, and chain before broadcasting it.

If the test fails, do not immediately increase slippage or retry repeatedly. Check the transaction receipt and revert reason, confirm the nonce is not already pending, reread the allowance, and compare the token decimals used by the quote with the decimals used to encode the transaction amount. Only after those checks pass should you request a new quote and attempt the flow again.

The practical decision rule is simple: if the spender, chain, account, token, or amount changes, restart the quote-and-allowance sequence. If none changes, still verify the allowance and transaction payload immediately before signing.