Introduction

Blockchains are islands. Ethereum knows nothing about Solana, and Bitcoin cannot read an Arbitrum block header. To move value between them, we build Bridges.

But “moving” is a lie. Assets never actually leave their native chain. They are trapped in a vault on one side and cloned on the other. This “Lock and Mint” mechanism creates the largest honeypots in crypto history.

In this lesson, we will ignore the marketing fluff of “interoperability” and strictly examine the widely different security commitments made by Trusted, Optimistic, and ZK bridges.

---

The Core Mechanic: Lock and Mint

When you “bridge” USDC from Ethereum to Solana, the physical bit-sequence representing that USDC does not travel.

1. Source Chain (Ethereum): You send 100 USDC to a Bridge Contract. The contract locks the funds. They are effectively stuck there.
2. The Void (Relayers): Off-chain actors observe this event and carry a message to the destination chain.
3. Destination Chain (Solana): The bridge contract on Solana verifies the message and mints 100 “Wrapped USDC” (wUSDC) to your wallet.

The Critical Risk: If the Eth Vault is drained, the wUSDC on Solana becomes worthless (unbacked).

---

Verification: Who Do You Trust?

The only difference between bridges is how the destination chain knows the source event actually happened.

1. The Multi-Sig (Trusted)

Mechanism: A committee of 5 people run servers. If 3 of them sign a message saying “Nikhil deposited 10 ETH,” the bridge believes them.

• Pros: Cheap, fast, low engineering complexity.
• Cons: If 3 people get hacked (or collude), they can steal billions.
• Examples: Ronin Bridge (Hacked for $600M), Harmony Horizon.

2. The Light Client (Trust-Minimized)

Mechanism: The destination chain runs a “Light Client” of the source chain in a smart contract. It verifies block headers and Merkle proofs.

• Pros: Trustless (mathematically verified). You trust the source chain’s consensus, not a middleman.
• Cons: Extremely expensive (gas) to verify headers. Hard to engineering between different consensus mechanisms (e.g., PoW to PoS).
• Examples: Cosmos IBC, BTC Relay.

3. The Optimistic Bridge

Mechanism: Someone submits a header/message. The bridge assumes it’s true but waits 30 minutes (or 7 days) for someone to prove it’s fraud.

• Pros: Cheap execution.
• Cons: Slow latency (withdrawal delays).
• Examples: Nomad (Hacked due to implementation bug), Optimism Bridge.

---

Anatomy of a Hack: The Nomad Incident

The Nomad bridge hack ($190M) wasn’t a cryptographic failure. It was a failure of initialization logic.

The bridge relied on a Merkle Tree of messages. When verifying a message, it checks effectively: root == calculated_root

During an upgrade, the developers accidentally initialized the “trusted root” variable to 0x00. Now, attackers could submit invalid messages. If the calculation failed and returned 0 (or if they crafted a path to 0), the contract checked: 0x00 == 0x00 -> True.

The Result: A “copy-paste” hack. Once users realized authentication was bypassed, hundreds of wallets effectively copy-pasted the exploit transaction to drain the bridge in hours.

Lesson: Security models don’t matter if the implementation has a logic bug.

---

Comparison: Wrapper vs. Native (Liquidity Networks)

Some bridges avoid minting “wrapped” assets. Instead, they use Liquidity Pools on both sides.

Mechanism:

• Alice deposits USDC on Ethereum.
• Bob (a Liquidity Provider) gives Alice USDC on Polygon from his own pocket.
• Bob eventually unknowingly claims Alice’s deposit on Ethereum.

Feature	Lock & Mint (Wrapper)	Liquidity Network (Native)
Asset Type	Synthetic (wETH)	Native (USDC)
Liquidity Risk	Unlimited (can mint infinite wrappers)	Limited (can only swap what’s in pool)
Example	Portal (Wormhole)	Across, Stargate (LayerZero)
Failure Mode	Depegging (Worthless tokens)	Stalled/Reverted transfers

---

Code Logic: A Simplified Bridge

Here is the pseudocode for a simple multi-sig bridge endpoint.

contract SimpleBridge {
    mapping(bytes32 => bool) public executed;
    address[] public signers;
    uint threshold = 3;

    function receiveMessage(
        bytes memory message,
        bytes[] memory signatures
    ) public {
        // 1. Prevent Replay
        bytes32 msgHash = keccak256(message);
        require(!executed[msgHash], "Already processed");

        // 2. Verify Signatures
        uint validSignatures = 0;
        for (uint i = 0; i < signatures.length; i++) {
            address signer = recover(msgHash, signatures[i]);
            if (isSigner(signer)) validSignatures++;
        }
        
        // 3. Check Threshold
        require(validSignatures >= threshold, "Not enough signers");

        // 4. Mint/Release
        executed[msgHash] = true;
        (address recipient, uint amount) = decode(message);
        token.mint(recipient, amount);
    }
}

Critical Vulnerability Check:

• Does signatures allow duplicates? (e.g., passing the same valid signature 3 times).
• Does executed get set before the external call to avoid reentrancy?
• Is signers modifiable by a compromised admin key?

---

Practice Exercises

Exercise 1: Trust Profile (Beginner)

Scenario: You investigate a new “SuperFast Bridge.” The docs say it uses “a decentralized network of Guardians.” Task: Find the number of guardians. If it’s less than 20 and they are all anonymous, classify the risk level.

Exercise 2: Trace the Path (Intermediate)

Scenario: Transfer ETH from Arbitrum to Ethereum (L2 -> L1). Task: Explain why this takes 7 days using the native bridge, but only 15 minutes using a third-party liquidity bridge like Hop or Across.

Exercise 3: Implementation Audit (Advanced)

Scenario: Look at the code block above. Task: If the recover function does not check that the signer is unique in the loop, how would you exploit it with only 1 private key?

---

Knowledge Check

1. What is the “honeypot” problem in bridges?
2. Why can’t Ethereum just read Bitcoin blocks directly?
3. In a Lock-and-Mint bridge, what happens if the source chain vault is hacked?
4. How does a Light Client bridge verify a transaction without trusting a signer?
5. What is a “replay attack” in the context of bridging?

Answers

1. Bridges store massive amounts of assets in a single contract (the “vault”). A single bug allows stealing billions, creating an immense incentive for attackers.
2. Blockchains are passive databases. They cannot initiate network requests. They can only read data explicitly submitted to them in a transaction.
3. The “minted” tokens on the destination chain become unbacked liabilities. Their value typically crashes to zero as everyone tries to dump them.
4. It mathematically verifies the consensus proofs (e.g., PoW nonce or PoS signatures) of the block header itself, effectively running blockchain verification inside a smart contract.
5. Taking a valid signed message (e.g., “Mint 100 USDC”) and submitting it twice to double the money. The bridge must track a nonce or hash to prevent this.

---

Summary

• Illusion of Movement: Bridges simulate movement by locking reserves and issuing IOUs (wrappers).
• Trust Spectrum: Ranging from “Trust this 5-person multisig” (Ronin) to “Trust the math” (ZK / Light Client).
• Risk: The bridge is almost always less secure than the blockchains it connects. Bridging degrades your security to the weakest link.

---