Bridge rate limiting: what it means when your transfer is throttled

02 September 2026

You try to send $10,000 across a bridge. The transaction fails. An error message tells you the transfer exceeds some limit you never heard of. It feels like the bridge just punished you for moving your own money.

It didn't. Rate limiting is a circuit breaker that caps how much value can leave a bridge within a fixed window. The goal is simple: if an attacker compromises the bridge and tries to drain the contract, the rate limit stops them from taking everything in one move. The loss is capped at whatever the limit is, not the entire pool.

How Outflow Throttling Works at the Contract Level

The mechanism is straightforward. A bridge contract tracks total outgoing transfers over a set period, usually 24 hours, and each time a transfer completes, the contract adds its value to a running tally. If the tally plus the new transfer exceeds the cap, the transfer is rejected. The tally resets after the window ends.

Some bridges use a decaying window rather than a hard reset; value decays out of the tally continuously. Others use a simple timestamp approach where, when the window expires, the tally resets to zero. The key is that the limit applies to the bridge's total outflow, not your individual transaction.

The threat rate limits exist to contain is the infinite mint vulnerability. In a lock-and-mint bridge, an attacker who compromises the validator set can mint unlimited wrapped tokens on the destination chain. Without a rate limit, they can extract the entire liquidity pool in seconds. With one, they can only bleed out the cap each day, buying time for monitoring systems to flag the anomaly and for the bridge to halt operations.

Typical refresh intervals and what you'll see

Refresh intervals vary by bridge. Many use a 24-hour window; some use shorter windows for high-value assets. The limit itself is usually set as a percentage of the total value locked in the bridge, often between 5% and 20%. These figures are not always published. You have to dig into the contract code or look for announcements.

The error messages you encounter depend on the bridge.

Wormhole returns a generic "transfer exceeds limit" error. The actual error is TransferExceedsLimit. The message gives no detail about the remaining capacity, so you have to check the contract state or wait.

Stargate is more informative. It throws a RateLimitExceeded error when the pool's outflow cap is hit. Stargate uses a decentralized network of oracles and relayers, and its rate limits apply per pool, not per chain. The error tells you the pool is temporarily exhausted.

Across uses a different approach. It returns SlowDeposit or a rejection if the rate limit is reached, because Across optimistically assumes you'll pay the slow route if the fast path is rate-limited. The user gets a choice: wait for the limit to refresh or take a slower, more expensive route.

How to React When You Hit the Limit

You hit the rate limit. What now?

First, confirm it's a rate limit and not a different error. Check the transaction revert reason. If it matches one of the patterns above, you know the problem.

Second, understand the window. If the limit operates on a 24-hour cycle, you may need to wait for the next window. Some bridges allow partial transfers if your amount is below the remaining capacity; others reject anything above zero until the full window resets.

Third, consider splitting the transfer across multiple windows. If you need to move a large sum, you can send smaller amounts each day until you're done. This only works if the bridge's rate limit is per address or per transaction - some apply the limit globally.

Fourth, check if alternative bridges have different limits. If one bridge is locked, another might have capacity, assuming the asset is supported on multiple routes.

Rate limiting is not a bug. It is not an annoyance invented to frustrate users. It is a deliberate safety mechanism with a clear trade-off: inconvenience for an individual transfer versus catastrophic loss for everyone using the bridge. The next time your transaction fails with a rate limit error, the bridge just did exactly what it was designed to do. It capped a potential exploit at a manageable number.

Back to bridges