Approve the intended spender for your Flashbots protected swap first: the router needs permission to transfer your input ERC-20 token before it can trade. The Flashbots Protect route carries the transaction privately, but approval itself does not execute the swap. Once the allowance is usable, refresh the quote and submit the swap through the protected route.
Which approval should I sign?
Sign the approval only after matching its token, spender and spending amount to the swap you intend to make. In a conventional ERC-20 flow, your wallet sends an approval transaction to the input token contract. That contract records how much the named spender may take from your address; the spender is usually the application's router, not the token contract receiving the approval call.
-
Token: The contract address must identify the asset you are selling on the intended Ethereum network.
-
Spender: The address must match the router the verified application says will execute this swap.
-
Amount: A bounded allowance should cover the planned input, without granting more spending power than you mean to leave available.
Together, these fields authorize the spender's transferFrom call, up to the remaining allowance. Approval neither transfers the output nor locks the quote. Verify the application and both contract addresses before signing: using Flashbots does not establish that the spender is trustworthy. Keep ETH for both transactions; each costs gas if included.
How do I know the approval is ready?
The approval is ready when its transaction has succeeded on Ethereum and the token's on-chain allowance for your address and the intended spender covers the swap input. A wallet's “submitted” or “pending” label means the transaction has been sent, not that the permission is already usable. Use its transaction hash to inspect the receipt; a successful approval receipt and a sufficient allowance are the two relevant signals.
If the app still shows “Approve,” refresh its view after the receipt appears and compare the same token and spender addresses. A previous allowance for another router does not help this one. If the transaction failed or never landed, the allowance has not changed; resolve that state before sending the swap. The Flashbots Protect route can handle the approval's submission too, but private submission is not proof of on-chain inclusion.
How do I finish and verify the protected swap?
Once the allowance is usable, get a fresh quote, review the swap details, and submit the swap through the protected route already configured in your wallet. The approval did not reserve the earlier price. Review the expected output, minimum received after slippage, deadline, recipient, application fees and estimated network fee. If the current quote no longer suits you, you can stop; an unused allowance can remain until you change or revoke it.
For a typical attempt, you select an input ERC-20 and the app shows “Approve.” After you confirm a bounded allowance, the approval receipt succeeds and the app offers “Swap.” You refresh the quote, confirm the swap in your wallet and retain that new transaction hash. The router can now use transferFrom to take the input during swap execution, subject to the allowance and swap conditions. The swap receipt tells you whether that execution succeeded.
Inspect the swap hash once it is included. A successful receipt establishes that the transaction executed; then compare the recipient's actual output-token balance or transfer record with the amount expected under accepted slippage. A submitted hash alone is not completion. For a Flashbots Protect swap, the observable result is still the on-chain receipt and output received.
When can the approval and swap sequence differ?
The sequence changes when the required permission is already available or the app uses another authorization method. If the token's existing allowance for this exact spender covers the input, the app may go straight to the swap. A permit asks you to sign a message that authorizes spending; the app can submit it with the trade, so a separate approval transaction may not appear. A smart-account batch can execute approval and swap calls together.
Read the wallet prompt for the actual spender and amount in those flows. A permit signature still grants authority, and a batch still needs the intended calls in order. When the app asks for a conventional approval transaction, wait for successful inclusion before treating “Swap” as the next step.
A confirmed allowance means the router may spend your token; only a successful swap receipt and received output mean the protected trade is complete.