Cross-chain best practices and hidden pitfalls
Cross-chain bridge hacks have caused billions in losses, but new research out of UC San Diego reveals something surprising: all major bridge hacks have boiled down to basic accounting errors. This research—led by PhD student Enze Alex Liu in collaboration with Professor (and Cubist co-founder) Deian Stefan—offers an extensive post-mortem, and proposes accounting-based defenses to protect against canonical bridge hacks. At Cubist, these findings have inspired the design of our Bascule Drawbridge bridge security layer, which Lombard uses to safeguard LBTC mints and withdrawals.
Understanding bridge architecture
Cross-chain bridges transfer assets between different blockchains. Consider, for example, a Bitcoin-to-Ethereum bridge. Users deposit BTC to a specific address on the Bitcoin side and receive an equivalent amount of “wrapped BTC” on Ethereum. A typical bridging workflow looks like this:
- A user deposits BTC to a specific address.
- A relayer observes this deposit and signs a receipt confirming it.
- A contract on the destination blockchain verifies the receipt and mints the proper amount of wrapped tokens for the user.
Though the process appears simple, it’s riddled with opportunities for subtle and serious errors.
Where bridges tend to fail
Liu's research identified a crucial insight: nearly all major bridge hacks, despite their complexity, originate from straightforward accounting errors—for example: allowing repeated mints for the same deposit, failing to correctly track withdrawals, or incorrectly verifying receipts. All these accounting errors mean that attackers are able to withdraw more assets than they actually deposited.
Accounting errors can arise at every step of the bridging process. If the relayer is buggy, it could be tricked into signing receipts for undeposited funds; if the contract on the destination chain doesn’t check the relayer signature properly, it could be tricked into minting wrapped tokens for nonexistent deposits. There are also more subtle errors: if the accounting on the deposit side doesn’t properly track the destination address on the minting side, for example, it’s possible for attackers to redeem wrapped tokens in exchange for other peoples’ funds.
Why Bitcoin bridges are especially vulnerable
Secure bridging is uniquely challenging on Bitcoin, because the chain doesn’t support smart contracts. Smart contracts make it easy to do accounting on both sides of the bridge: the contract on the minting side verifies the relayer’s signature and mints funds, while the contract on the deposit side keeps track of details like the destination address on-chain. In a BTC-to-Ethereum bridge, though, there is no such contract on the deposit side. This makes it tough to associate Bitcoin deposits with Ethereum addresses.
There are several ways to associate Bitcoin deposits with users’ Ethereum addresses:
- Bad (but easy): Generate individual deposit addresses per user stored in the bridge (or relayer's) database. This is easy but means an attacker who compromises the database can just put their address as the destination address—and we've seen these kinds of hacks going back to Mt. Gox days.
- Ugly (but secure): Require OP_RETURN metadata specifying the recipient address. This is secure (if you verify the metadata), but many custodial services don’t support crafting such transactions. This means users using the custodial services can’t deposit or, more likely, the bridge will take the easy route.
- Good (and secure): Generate deposit addresses by tweaking keys cryptographically with recipient details.
The recommended “good (and secure)” method ensures that each Bitcoin deposit address cryptographically commits to its intended recipient address and destination blockchain. This means users, given a deposit address, can verify that their deposits are destined to their address—and can't be phished into sending funds to an incorrect address.
Our design specification is open source and used by multiple customers, including Lombard.
Independent verification as an additional security layer
But what about the accounting-based defense proposed by Liu’s work? The research recommends independently verifying every bridge transaction: having a separate system that checks each mint/withdrawal against the history of existing deposits. If an attacker attempts a mint/withdrawal without a single corresponding deposit, the transaction should be automatically rejected. Our Bascule Drawbridge is one example of such an independent verification layer.
Key takeaways for secure Bitcoin bridges
To effectively mitigate the most common bridge vulnerabilities, it’s important to independently verify that mints are backed by equivalent deposits. And in Bitcoin bridges, it’s best to generate deposit addresses that are cryptographically tied to recipient details. By applying these technical best practices, cross-chain bridges can defend against the basic—yet pervasive—accounting errors responsible for most bridge hacks.
