Crypto Newbie / Simulators / Bridge Drain
Bridge Liquidity Drain Simulator
Cross-chain bridges hold liquidity on both sides — chain A and chain B. Users deposit on A, withdraw native tokens on B from the bridge's pool. When everyone wants to LEAVE one side (panic withdrawals from chain B back to A), the chain A pool drains rapidly. New requests queue, then get rejected. This simulator runs the math so you can see exactly when a bridge fails under stress — and what features make some bridges (Stargate auto-rebalancing) survive scenarios that break others (basic Wormhole).
Bridge liquidity
Total bridge TVL: $20.00M
Panic-withdrawal scenario
A→B deposits flowing in despite the panic. Usually low during stress.
How locked-mint bridges work mechanically
User on chain A deposits 100 USDC into the bridge's chain A pool. The bridge MINTS 100 wrapped-USDC on chain B (which the user can claim). Days later, the user wants their native USDC back on chain A. They burn the wrapped on chain B; the bridge releases 100 USDC from its chain A pool to them. Bridge balance sheet: chain A side has user's 100, chain B side has minted 100. The pools are balanced as long as flows balance both directions.
Why bridges drain — directional imbalance
When everyone wants to LEAVE chain B (sell wrapped, get native on A), the chain A pool drains as those withdrawals happen. New A→B deposits would replenish the chain A pool — but during a panic, nobody's depositing TO chain B (they're leaving it). The result: chain A liquidity falls toward zero, while chain B liquidity grows (more wrapped sitting there with nowhere to go). At some threshold, the bridge can't fulfil any more B→A withdrawals; it starts queueing or rejecting.
Auto-rebalancing bridges (Stargate, Across) vs static (Wormhole basic)
Stargate solves directional imbalance with fee adjustments: when one side drains, fees on the opposite direction rise (attracting people to do the rebalancing trade for profit). Across uses a similar mechanism with bonded relayers. The result: auto-rebalancing bridges almost never fully drain — economic actors prevent it for profit. Static bridges (vanilla Wormhole, older Multichain) have no such mechanism — once a side drains, recovery requires the operator to manually rebalance or for natural flow to return.
Real bridge failures and what they cost users
Multichain (July 2023): drained over weeks of withdrawal pressure before the team exit-scammed with ~$1.5B locked. Wormhole hack (Feb 2022): $325M in wrapped ETH stolen by exploiting verification; Jump Crypto bailed out the bridge. Polygon zkEVM (2024): multi-day withdrawal queues during peak L2 activity, no funds lost but UX broke. Optimism native withdrawals: 7-day waiting period regardless of liquidity — different problem (not drain, but slow by design). For users: assume any bridge could freeze or fail; don't keep large balances dependent on a bridge functioning soon.
Frequently asked questions
+Are 'native' chain bridges safer than third-party bridges?
Yes, structurally. Optimism's native bridge, Arbitrum's native bridge, ZK bridges (zkSync, Polygon zkEVM) inherit the security of the underlying L1 — withdrawals are cryptographically guaranteed (with delay periods to allow fraud proofs). Third-party bridges (Multichain, Wormhole, Synapse) rely on multisigs or proof-of-stake validators who can collude or be hacked. Native > 3rd-party for security; 3rd-party often faster + cheaper.
+What's a 'withdrawal queue' on an L2?
On optimistic rollups (Arbitrum, Optimism, Base), native bridge withdrawals are subject to a 7-day challenge period — anyone can submit a fraud proof during this window. Most users use third-party fast bridges (Across, Hop) that pay the user immediately and wait the 7 days themselves. During high activity, the queue for these fast bridges can grow if they don't have enough capital to front the withdrawals. ZK rollups skip the challenge period but still have proof-generation delays.
+Can I lose money if a bridge drains while I'm using it?
Not necessarily money LOST — but your funds can be STUCK. You hold wrapped tokens on chain B; the chain A pool is drained; you can't withdraw to native. You might wait days/weeks for liquidity to replenish, or trade your wrapped tokens at a discount to someone who has more patience. If the bridge goes insolvent (Multichain), wrapped tokens become worthless because there's no underlying native to back them.
+How can I check a bridge's current liquidity?
Most bridges have public dashboards showing pool size per chain. Stargate: stargate.finance shows real-time TVL per chain. Synapse: synapseprotocol.com. For wrapped-token bridges, check the underlying reserves on Etherscan (e.g., search for the bridge contract address). If liquidity is low + utilization is high, expect queues/rejections during stress.
+Why doesn't the simulator show interest rate adjustments?
For simplicity. Real auto-rebalancing bridges (Stargate, Across) ADD a fee adjustment mechanism that's hard to visualise in a single widget. The static-bridge math we run here shows the BASE failure mode — what happens when no economic counter-incentive exists. Real Stargate would intervene earlier (raising fees on rebalancing trades) and rarely fully drain. We're modeling the worst-case (vanilla bridge) so you can SEE the dynamic; real best-in-class bridges mitigate it.