Guide
Approve the router once: the first close takes two signatures, and the rest take one
The pool cannot pull WBTC out of your wallet until the token says it may. That permission is a separate transaction. It is not the sale. After it exists, a close is one prompt.
MONAF Blog · 26 October 2026 · 18 min
- First close
- Two signatures
- After that
- One
- Amount
- This sell, not unlimited
A swap of native MON does not need an approval. You are sending the coin with the transaction. A swap that takes WBTC, WETH, cbBTC or USDC out of your wallet does. The token contract holds a number, the allowance, for a spender. The router is the spender. If the number is below the amount of the sell, the router’s call reverts and you keep the token. The first close of a token is therefore often two signatures. Every later close of that token, from that wallet, to that spender, is one.
What you are signing, in order
The first prompt is approve. The token is the asset you hold. The spender is the router, not the desk, not a vault you do not recognise, and not an address that arrived in a chat. The amount is the size of this sell. The second prompt is the swap. They go out on consecutive nonces, so the swap cannot be mined first. You do not wait for the approval’s receipt before signing the swap. You do reject the swap if the approval prompt was not the token you hold.
If you approve and reject the swap, you have paid a small gas bill to raise an allowance and you are still in the position. That is safe. Tap Close again when you mean to sell. The allowance is already there, so the second attempt is one prompt. If you reject the approval, nothing about the position changed.
Approve is permission. The swap is the sale. Read both prompts as if they were different products, because they are.
Exact amount, not a blank cheque, on this path
This close approves the quantity it is about to sell, not the maximum integer. A later, larger sell of the same token may ask again. That second approval is cheaper than an unlimited approval you then have to remember. Unlimited is convenient for a router you use every day and dangerous for a spender you will not recognise in a month. If a prompt asks for unlimited and you did not come here to grant that, reject it. The desk’s own close does not need it.
Vault positions do not use this approval
When the tokens sit in the vault, the agent sells through the vault’s own call. Your wallet is not approving a router, because your wallet does not hold the tokens. You will not see an approve prompt for that close. If you do, you are signing something else. Stop and read the origin. A vault close that suddenly wants a wallet approval is not the vault close.
How to take the permission back
Allowance lives until you set it to zero or the spender uses it. On the token contract, approve the same spender with amount zero. That is a normal transaction, from your wallet, for a small gas bill. Do it when you are finished with a token, or when you are no longer sure which site you granted. The explorer will show the current allowance if you call it. You do not need to revoke between two closes you intend the same afternoon. You do want to know the spender’s address, and you want that address to be the router you can find in the pool’s own deployment, not a lookalike.
USDC is the same shape
Paying in USDC, or selling back to it, is an approval against USDC rather than against the wrapped coin. The decimals differ. The idea does not. A prompt that names USDC when the card says you paid MON is the wrong prompt. A prompt that names the wrapped BTC when the card is a BTC fill is the right one, on the first close only.