If you move tokens only a few times a year, a permit signature can remove a separate approval transaction when the token and route support it. You still need to check what you are authorizing and keep enough of the source chain’s native token to pay for the bridge transaction.
- A permit is an off-chain signature that can authorize token spending as part of a later on-chain transaction.
- It can save one transaction and its wait, but it does not make the bridge transfer itself gas-free.
- Some permit systems still need a one-time on-chain approval before the first signature-based transfer.
What changes when you sign a permit?
A permit lets a token holder authorize a spender with a wallet signature instead of first sending an on-chain approval transaction. With an ordinary ERC-20 approval, the token contract records an allowance after that transaction confirms; a later bridge transaction can use the allowance to take the approved tokens.
For a permit-enabled token, the signature carries details such as the token, spender, amount, deadline, and a nonce. The nonce is a number that prevents the same signature from being reused. The route’s transaction submits the signature to the token contract, which checks it and records the allowance before the contract moves the tokens.
This can combine approval and token movement in one on-chain transaction. If you are comparing routes with a bungee bridge aggregator, a permit may appear as part of one route’s transfer flow, but the route and token must both support the relevant permit method.
Does it remove the bridge transaction fee?
No: it can remove the separate approval transaction, while the source-chain bridge transaction still needs to be submitted and paid for. A signature itself is created in your wallet and does not use on-chain gas; the contract call that checks it does. Depending on the route, that check and the transfer can happen in the same transaction.
The practical saving is usually one transaction’s worth of source-chain gas and one confirmation wait. The amount varies with network congestion and transaction complexity, so there is no reliable fixed dollar saving. On a low-cost chain, the main benefit may be fewer steps; on a busy or expensive chain, avoiding a separate approval can matter more.
There is an important exception: Permit2-style systems can require an initial ERC-20 approval giving the Permit2 contract permission to handle the token. That approval is an on-chain transaction, though later Permit2 signatures can authorize specific transfers without a new approval each time. So “signature-based” does not always mean “no approval transaction ever.”
What should you check before signing?
Read the wallet’s signing summary and confirm that the token, spender, amount, and expiry make sense for the transfer you intend. A permit is a spending authorization, not a harmless login message. If the amount is limited to the tokens you plan to move and the deadline is short enough for the task, the permission is easier to understand and contain.
A common mistake is to treat every signature prompt as the same thing, or to sign a stale permit after changing the transfer details. Check that the displayed amount and destination match your current transfer; if you changed the route or amount, request a fresh quote or permit when the app supports it. A signature may expire or stop working if its nonce has already been used.
One edge case explains why a signed permit can sometimes fail even before its deadline: another party may submit that valid permit first, consuming its nonce. A well-designed route can account for the allowance already being set, but a wallet may still show an error if the transaction expects to submit the same permit again. If that happens, inspect the allowance and transaction state before signing a replacement.
When is a separate approval still needed?
A separate approval is needed when the token does not implement a compatible permit standard, or the route’s contracts do not support that token’s permit method. Token behavior differs, so an aggregator may use a signature for one asset and require an approval transaction for another. The route’s actual transaction plan determines which applies.
When you want to move and possibly swap tokens across chains, bungee bridge can help you find a route, while the approval mechanism depends on the token and contracts that route uses. Celer cBridge, Across Protocol, and Hop Protocol are examples of distinct cross-chain protocols; a route aggregator may compare options, but that does not make their approval requirements identical.
After the transfer, review and revoke any allowance you no longer want active, especially a large or unlimited one. My practical habit is to check the spender and amount before signing, then check the resulting allowance after the transaction; that catches the common mismatch without requiring you to study every permit standard.