Multichain/L2 Ethereum is here, and it’s here to stay. This has spurred the creation of dozens of new bridges and interoperability protocols as projects have scrambled to enable this functionality for DeFi.

As can be expected, this has also brought on a number of high profile hacks and scams:

The multiple Thorchain hacks.
The PolyNetwork hack.
Despite these examples, every bridging system out there markets itself as trustless, secure, and decentralized (even if that’s not at all the case). This means big challenge for developers and users is now, “how can I figure out which bridging mechanisms are actually cryptoeconomically secure?”

In other words, how can users discern between types of bridges to determine who they are trusting when moving funds between chains?

Natively Verified
Natively verified protocols are ones where all of the underlying chains’ own verifiers are fully validating data passing between chains. Typically this is done by running a light client of one chain in the VM of another chain and vice versa.


Examples include Cosmos IBC, and Near RainbowBridge. Rollup entry/exits are a special form of this as well!

Advantages:

Most trustless form of interoperability because the underlying verifiers are directly responsible for bridging.
Enables fully generalized message passing between domains.
Disadvantages:

Relies on the underlying trust and/or consensus mechanisms of the domain to function, so it must be custom built for each type of domain.
The Ethereum ecosystem is highly heterogenous: we have domains that are everything from zk/optimistic rollups to sidechains to base chains which run a large variety of consensus algorithms: ETH-PoW, Nakamoto-PoW, Tendermint-PoS, Snowball-PoS, PoA, and many others. Each of these domains requires a unique strategy for implementing a natively verified interoperability system.

Externally verified protocols are ones where an external set of verifiers is used to relay data between chains. This is typically represented as a MPC system, oracle network, or threshold multisig (all of these are effectively the same thing).


Examples include Thorchain, Anyswap, Biconomy, Synapse, PolyNetwork, EvoDeFi, and many many many others.

Advantages:

Allows for fully generalized message passing between domains.
Can easily be extended to any domain in the Ethereum ecosystem.
Disadvantages:

Users and/or LPs fully trust the external verifiers with their funds/data. This means the model is fundamentally less cryptoeconomically secure than the underlying domains (similar to our Arbitrum to Optimism example above).
In some cases, projects will use additional staking or bonding mechanisms to try to add security for users. However, this typically does not make a lot of economic sense. In order for the system to be trustless, users have to be insured up to the maximum ruggable amount, and that insurance must come from the verifiers themselves. This not only significantly increases the capital required in the system, but also defeats the whole purpose of having minted assets or liquidity pools in the first place.

Examples include Connext, Hop, Celer, and other simple atomic swap systems.

Advantages:

Locally verified systems are trustless — their security is backed by the underlying chain given some reasonable guarantees shared by rollups (e.g. the chain cannot be censored for more than X days).
They are also very easy to extend to other domains.
Note: not every locally verified system is trustless. Some take trust tradeoffs to improve UX or add extra functionality.

For example, Hop adds some trust assumptions through their need for a fast arbitrary-messaging-bridge (AMB) in their system: the protocol unlocks bonder liquidity in 1 day rather than waiting a full 7 days when exiting rollups. The protocol also needs to rely on an externally verified bridge if no AMB exists for a given domain.

Disadvantages:

Locally verified systems cannot support generalized data passing between chains.
What the above means is a bit nuanced and comes down to permissioning: it is possible for a locally verified system to enable cross-domain contract calls but only if the function being called has some form of logical owner. For example, it is possible to trustlessly call a Uniswap swap function across chains because the swap function can be called by anyone who has swappable tokens. However, it is not possible to trustlessly lock-and-mint an NFT across chains — this is because the logical owner of the mint function on the destination chain should be the lock contract on the source chain, and this is not possible to represent in a locally verified system.

Now we get to the thesis of this article, and the mental model that should drive user and developer decisions around bridge selection.


Similar to the Scalability Trilemma, there exists an Interoperability Trilemma in the Ethereum ecosystem. Interop protocols can only have two of the following three properties:

Trustlessness: having equivalent security to the underlying domains.
Extensibility: able to be supported on any domain.
Generalizeability: capable of handling arbitrary cross-domain data.