How We Selected Bridge Providers for MetaMask Bridges

MetaMask Bridges allows users to enter their desired starting network, destination network, and the token they want to bridge to compare options across multiple bridge providers. Bridge providers are integrated in two layers: bridge aggregators and individual bridges.

We integrate directly with two bridge aggregators: Socket and LI.FI. These partners allow us to easily search routes from several bridges, as well as provide helpful utilities for a better user experience.

Through Socket and LI.FI, we support a curated set of individual bridges: Connext, Hop, Celer cBridge, and Polygon Bridge. We did extensive research to vet these bridges, with the goal of developing an objective framework to select those that met our high bar for security and decentralization. We’re not being paid by any of these bridges to be part of this product (though we may have other partnerships with them) and have selected them purely based on our evaluation of their design.

How We Picked These Bridges

Here’s our framework for deciding which third-party bridges to integrate. All bridging involves some level of risk, and we’ve done our best to find the most decentralized and usable bridges out there. Here’s what we looked for:

Network and token support

Usability is super important to us, so we looked for bridges that support MetaMask’s most-used networks and tokens. This meant providing robust support for native tokens and canonical stablecoins across Ethereum, Polygon, BNB Smart Chain, and Avalanche.

Trust minimized design

One of the biggest challenges in bridging is how information is validated. When a user deposits tokens on one network, how does the bridge know for sure that this has occurred, so it can send them tokens on another network? Different bridges have different mechanisms to do this, and they differ significantly in their trust assumptions.

We considered bridges in the following categories, with these criteria for each:

Atomic swap: We consider this model to be highly trust minimized, as it relies on contract code rather than external parties.

Canonical: This is the native bridge of a given destination network, such as the Polygon Bridge for the Polygon network. We include these bridges because we consider the trust assumptions to be comparable to the network itself.

Optimistic: In this model, each transfer goes through a challenge period during which challengers can report fraud. In general, we like this model because only one honest party is required to maintain the integrity of the bridge. However, trust assumptions may vary depending on whether the challenger set is permissioned (i.e. a limited set of parties can challenge) vs permissionless (anyone can challenge).

External validator: In this model, a threshold number of third-party validators attest that each transfer is valid. This is the most common model for bridge validation, and bridges in this category may be risky if the validator set is not large enough. We may consider external validator bridges if validator addresses are public and a high threshold is required for validation.

Reliable and vetted

We like to see:

• Recent and regular audits of the deployed contract code
• Battle testing with time/volume on mainnets
• High liquidity and reliability
• Robust handling of failure cases

Bridges we selected

Here are the bridges that we are integrating for our initial launch, and how we categorized them based on the framework above:

1. Polygon Bridge - canonical
2. Connext NXTP - atomic swap
3. Hop Exchange - optimistic (uses canonical L2 bridges)
4. Celer cBridge - external validator / optimistic hybrid

We’ve scoped this to a short list for our initial launch but are continuing to evaluate other bridges and consider them for integration. We’re also actively monitoring the bridges we’ve selected, and will continue to analyze their security as they evolve.

If you’re building a bridge that you think would meet our criteria, please reach out and let us know!

Thank you to everyone who contributed to this article and helped evaluate bridges:

• Our partners Socket and LI.FI who shared their own frameworks for these bridges and worked with us to integrate them.
• The teams at Connext, Hop, Celer, and many others, who met with us and answered our numerous questions about their bridge.
• ConsenSys researchers who contributed to this framework: Dominik Schmid, Peter Robinson, Ermyas Abebe, and many others who supported along the way.