You've just completed a withdrawal from Arbitrum to Ethereum mainnet. The transaction confirmed. The funds left your account on the rollup side. And now you're staring at a seven-day countdown timer like it's a parole hearing.
That delay isn't a bug. It's the security model.
Blockchain bridges solve a genuinely hard problem: two separate chains don't share state, don't trust each other, and can't natively verify what happened on the other side. The bridge has to convince Chain B that something real occurred on Chain A. How it builds that conviction determines almost everything: speed, cost, trust assumptions, and what happens when someone lies.
Two dominant approaches have emerged. Optimistic verification and zero-knowledge proofs. They are not interchangeable, and the tradeoffs are starker than most explanations admit.
The Fraud Window: How Optimistic Bridges Actually Work
An optimistic bridge doesn't verify that a transaction is valid before accepting it. It assumes the transaction is valid, posts that assumption publicly, and waits to see if anyone proves otherwise.
The mechanics work like this. A relayer (sometimes called a validator or watcher, meaning a third party whose job is to watch the chain and report lies) observes an event on Chain A, say a deposit of 10 ETH into the bridge contract. It posts a claim to Chain B: "10 ETH was deposited, release the equivalent funds." Chain B's contract doesn't run the math. It starts a challenge window, typically seven days, during which any third-party watcher can submit a fraud proof if the claim was false.
If nobody objects, the claim is accepted and funds release. If a watcher catches a lie and submits valid cryptographic proof of the fraud, the malicious relayer's bonded stake gets slashed, and the claim is rejected.
The seven-day window exists because that's roughly how long it takes to guarantee that an honest watcher, anywhere on earth with any reasonable internet connection, has had time to see the claim and respond. Shorter windows mean faster withdrawals but give fraudsters a tighter gap to exploit if watchers are slow or offline.
Optimism's canonical bridge uses exactly this model. So does Arbitrum's. The cost is low because you're not doing heavy cryptography on-chain. The tradeoff is that you are trusting the liveness of the watcher network, and you're waiting.
Consider two users: Maya and Tariq, both bridging 5,000 USDC from Arbitrum to Ethereum mainnet on the same afternoon. Neither is doing anything wrong. Both wait the full seven days. Maya had planned ahead, no problem. Tariq needed funds for a time-sensitive DeFi position and missed the window entirely. Same bridge, same security, completely different outcome. The delay isn't theoretical friction, it's a real cost that lands unevenly, and for anything time-sensitive it is a structural liability, not a minor inconvenience.
Proof First, Then Settle: The ZK Approach
A zero-knowledge proof bridge flips the order entirely.
Instead of posting a claim and waiting for objections, it generates a cryptographic proof that the claim is mathematically correct before Chain B will accept anything. The proof is generated off-chain by a prover, a piece of software that takes the transaction data from Chain A and produces a succinct cryptographic certificate: a validity proof, usually a SNARK or STARK (two flavors of zero-knowledge proof, differing mainly in their underlying math and verification cost), that says "this batch of transactions satisfies all the rules, and I can prove it without revealing the underlying data." Chain B's verifier contract checks the proof. If it passes, funds release. No waiting period. No challenge window. No reliance on watchers being awake.
ZKSync's bridge to Ethereum uses this model. Starknet's bridge uses STARKs. Verification happens in roughly minutes rather than days, and the security guarantee is mathematical rather than economic.
Think of the optimistic model as a notarized document that anyone can contest in court for a week. The ZK model is closer to a mathematical theorem: once the proof checks out, there is no court, no appeal, no seven-day window for someone to object. The truth is settled at the moment of verification.
So why doesn't every bridge use ZK proofs? Because generating those proofs is expensive and slow to build correctly. Proof generation requires significant computation, and the circuits that encode a blockchain's rules, meaning the formal specification of every valid state transition, are extraordinarily complex engineering. A single mistake in the circuit design means the proof system validates invalid state transitions, which is arguably worse than no proof at all. The auditing surface is enormous and specialized, and the tooling is still maturing.
There's also a cost dimension that surprises people. On-chain ZK proof verification, while cheaper than it used to be thanks to EIP-4844 and dedicated precompiles, still consumes meaningful gas. For small transfers, that fixed cost can make ZK bridges more expensive per transaction than optimistic ones.
The Trust Assumptions Hidden in Both Models
This is where the analysis gets sharper.
Optimistic bridges are secure under one condition: at least one honest watcher must be online and capable of submitting a fraud proof within the challenge window. That's a 1-of-N honesty assumption, meaning out of all the watchers, only one needs to be honest and awake. In practice, large bridges like Arbitrum's have multiple independent watchers, making collusion difficult. But it's still a liveness requirement. A targeted attack that knocks watchers offline during the challenge window is theoretically exploitable.
ZK bridges are secure under a different condition: the proof system itself must be sound, and the circuit must correctly encode the rules. If it does, no amount of collusion among relayers changes anything. The math either checks out or it doesn't. This is a much stronger guarantee, closer to "trustless" in the rigorous sense of the word.
But ZK bridges still have trust surface in the prover infrastructure. If the prover is centralized (one company runs it), you're trusting that company not to go offline, censor transactions, or have undiscovered bugs in their software. Decentralizing the prover network is an active engineering problem most ZK bridge teams are still solving.
Neither model is unconditionally trustless. Anyone who tells you otherwise is selling something.
Speed vs. Soundness: Picking Your Poison
So which model should you build on or build with? The practical decision tree looks roughly like this.
If you're building infrastructure that moves high-value assets infrequently and finality is the priority, ZK verification is architecturally cleaner. The math-based guarantee ages better than an economic incentive structure that depends on token prices keeping watchers honest. That's not a neutral observation: I think optimistic bridges are structurally underrated for their current track record and structurally overrated for their long-term security properties.
If you're building something that needs to move large volumes of smaller transactions cheaply, and you can tolerate the withdrawal delay on the way back to mainnet, optimistic bridges offer lower per-transaction costs and a longer production track record.
ZK proof generation is getting faster every year. Hardware acceleration, better proving algorithms, and purpose-built chips are compressing what used to take minutes into seconds. The cost advantage of optimistic verification narrows as proving gets cheaper. Several teams are already building hybrid systems that use optimistic assumptions for speed but can fall back to ZK proofs if a challenge is raised.
The seven-day wait probably has an expiration date. The math-first approach will likely win on security properties as the tooling matures. But "likely" and "as the tooling matures" are doing a lot of work in that sentence, and production systems running billions of dollars in daily volume don't wait for eventually.
The bridge you choose is a bet on which constraint bites harder right now: the cost of waiting, or the cost of trusting.