Unlimited approvals during a bridge transfer

An unlimited token approval lets a bridge contract spend any amount of one token from your wallet on that network until the allowance changes. It does not move tokens when you grant it, but it leaves the contract with permission to request transfers later. If you are used to a centralised exchange, think of it as giving a particular service ongoing access to one asset, rather than depositing your whole balance with the exchange.

An approval is a standing spending permission

For a standard ERC-20 token, you approve a specific spender address and set an allowance: the maximum amount that address can take from your wallet. The token’s contract records the allowance. Later, the spender can call transferFrom to move tokens within that limit. The EIP-20 standard defines this approve-and-spend pattern.

The permission is tied to both the token and the network. Approving a token contract on Ethereum does not approve that token on Polygon PoS, and it does not give every contract access to your wallet. When you use Polygon Bridge to move a supported token, the source-network bridge contract may need permission to take the amount you intend to deposit. The route itself is a separate choice; how Polygon Bridge routes a transfer is explained in the route guide.

Unlimited means the allowance does not match your transfer

An unlimited approval sets the allowance to the token’s maximum value, often displayed as “unlimited” or a very large number. That saves you from approving again for later transfers to the same spender. But the permission is not limited to the amount in your current bridge transaction, and it usually has no automatic expiry.

For example, suppose you hold 500 units of a token and plan to bridge 100. An approval capped at 100 lets the spender take at most 100 units under that allowance. An unlimited approval lets it request up to your available balance, including tokens you receive later, while the approval remains active. The amount actually exposed is bounded by both your balance and the remaining allowance.

The risk depends on the spender address. A faulty or compromised contract, or an approval granted to the wrong contract, could use the permission to take tokens. An approval alone does not let a website or an unrelated wallet address withdraw them; the token contract checks that the spender is the approved address. The danger is that the permission remains available if that address later behaves badly.

A bridge transfer can involve two onchain transactions

In a typical wallet flow, the approval transaction comes first and the bridge deposit transaction follows. Both are signed from your wallet and recorded on the source network. Once the approval is confirmed, the bridge contract can take the approved amount as part of the deposit. The bridge then handles the cross-network transfer according to its mechanism; the allowance itself does not travel to the destination network.

Imagine you want to move 100 token units from Ethereum to Polygon PoS. Check that the wallet is on the network where those tokens are held, then review the approval request: it should name the expected token and spender, and its amount should make sense for the transfer. If you choose a 100-unit cap, the contract cannot take 101 under that allowance. After it confirms, review and sign the separate deposit transaction.

For another transfer, you may need to grant more allowance if the first transfer used it. If you approved 100 but deposited only 80, the remaining 20 may still be available to that spender. A later deposit may use that remainder without another approval. This is why the allowance shown in a wallet is more useful than remembering only the amount from your last transfer.

A narrow allowance limits what remains exposed

For a one-off bridge transfer, a cap close to the amount you plan to deposit is a straightforward way to limit the permission. Some wallets, including MetaMask, let you adjust the spending cap when an approval is requested. If you expect repeated transfers to the same contract, a larger allowance can reduce future approval transactions, but it also leaves more permission in place between uses.

After bridging, check the token’s allowance for that spender on the source network. If you no longer need it, set the allowance to zero where the token and wallet support that action. Revoking is an onchain transaction and costs network gas; it prevents future spending through that allowance, but it cannot reverse a transfer already made. Some tokens require setting the allowance to zero before changing it to a new nonzero amount. Native POL used to pay Polygon PoS gas is not an ERC-20 allowance: approvals concern token contracts, not the network’s native gas balance.

Does approving a bridge move my tokens?

No. Approval records permission in the token contract; the bridge deposit is a separate action that moves the tokens. You can see an approval confirmed while your token balance stays the same. The deposit transaction is the one to review for the amount and destination you intend to use.

Can I revoke an unlimited approval after bridging?

Usually, yes: you can submit a transaction setting the allowance for that token and spender to zero on the network where you approved it. The revocation takes effect after confirmation and uses gas. It does not undo a completed bridge transfer, and it does not revoke permissions you granted to other spender addresses.

Takeaway: Approve only the amount you need for a transfer unless the convenience of a standing allowance is worth the added exposure.