LI.FI: With Bridges, Trust is a Spectrum

Despite the term “trustless” being widely used to describe blockchains and smart contracts, people often get confused about what it really means. It’s one of those words like “decentralization” that is thrown around a lot, but rarely defined or measured.

This article is our attempt to define and measure the level of “trust” required by different types of bridge designs. And what we found is that with blockchain bridges, trust is a spectrum.

Let’s dive in!

What is a Trustless System?

In crypto, trustless means that users do not have to rely on a third party (any intermediary like banks or other individuals) to control their funds for any transaction or transfer. Instead of trusting third parties, users rely on blockchains and smart contracts that run on code to execute transactions. Thus, a trustless system is one that does not depend on external actors to facilitate transactions from point A to B. However, this is a very straightforward definition of trustless systems. On a technical level, it is much more nuanced.

In their research paper titled, “Building Scalable Decentralized Payment Systems,” John Adler and Mikerah Quintyne-Collins provide a more detailed explanation of the term trustless: “A blockchain system is trustless if and only if its state is (i.e., all its state elements are) both live and safe.”

To expand on John and Mikerah’s idea, the system’s state can be understood as ‘who owns what’ at any particular time — the owner of the state elements associated with public addresses in a system. Here, we need to take a closer look at two properties:

• Safety — This means user funds can’t be stolen, and they can’t be locked up forever. Only the owner can update the state (ex: move the funds or transfer them)

• Liveness — Liveness means that essentially, as of some bounded time, the owner of the state (ex: funds) will be able to move it or transfer it.

A trustless system can preserve both the safety and the liveness of its state. In the context of blockchain bridges, the state, for example, could be the users’ funds.

This means trustless bridges are those:

1. where users’ funds are never lost (never stolen or locked forever)

2. where the owners of the state, i.e., the users, can move or redeem their funds after a specific period of time.

Furthermore, when it comes to bridges, they can be effectively trustless if and when the security of the validator set of the bridge is higher than that of the two blockchains it’s connecting. However, this is impractical due to the significant capital required to secure such a system. For instance — a bridge is effectively trustless even if it’s possible for the validator set to censor or steal users’ funds but the amount of capital it will take to do so is greater than the amount of capital required to conduct a DDOS attack on Ethereum itself. (The critical takeaway is that systems reliant on actors not having malicious intent can also be effectively trustless as long as acting dishonestly is either impossible or does not make economic sense.)

Now that we have created a baseline understanding of trustless systems, let’s take a look at why and where trust is introduced into bridge designs. From there, we will then dive into whether or not certain bridge designs are truly as trustless as their branding may proclaim.

The Root of Trust in Bridges

Most people associated with the world of cryptocurrency claim that blockchains replace trust — eliminating the need to trust intermediaries with their funds. This is true: blockchains do replace trust. However, they don’t necessarily eliminate it. Instead, a more nuanced claim asserts that blockchains minimize trust, typically by distributing it to various actors in a system or incentivizing honest behavior (or vice versa).

Similar to blockchains, trustless bridges don’t eliminate trust. Instead, they distribute it across the system by using different designs. For instance, some bridges introduce an external distributed set of validators to process transactions. In contrast, others use atomic swaps to transfer funds and rely on the distributed validator set of the underlying blockchains.

With the help of examples, let’s try to narrow down where trust is introduced in bridge design.

A completely trustless cross-chain transaction would be — Alice on Blockchain A sends $1000 to her wallet address on Blockchain B.

If Alice wants to send her funds from one blockchain to another, she can simply send the funds from her wallet in Blockchain A to the wallet in Blockchain B. This process does not add any third party. Thus, Alice does not have to trust anyone other than the validator set of the two bridges. While this is ideal, it is not theoretically or practically possible because blockchains cannot communicate between themselves.

Another way to do such a cross-chain transfer is by swapping funds with another user who has funds on Blockchain B.

Example — Alice sends $1000 to Bob on Blockchain A. In return, Bob sends $1000 to Alice on Blockchain B.

Theoretically, two users interested in transacting with one another can do so directly. But in reality, this has many constraints:

1. Alice has to trust that Bob will send the funds

2. What if Alice cannot find someone like Bob who is interested in such a swap every time?

While constraint #1 can be addressed via smart contracts, such a model is not scalable because of constraint #2. To address constraint #2 and others, we introduce bridges between blockchains that act as the ‘man-in-the-middle’ of the two blockchains and make communication between them possible.

To overcome the communication and trust boundaries between blockchains, some bridges use off-chain actors or validators. These validators or verifiers responsible for verifying the system are the root of trust in bridges because they introduce new trust assumptions unique to the validator set (in addition to the blockchains that are being connected). In reality, these bridge designs act very similarly to a bank, as they facilitate transactions in a more centralized, trust-based manner.

The Root of Trust in Bridges

However, and this is hopefully the future of the cross-chain ecosystem, some bridge designs don’t need to add their own validators in the middle. Instead, they use the blockchains’ and their respective validator sets to make bridging possible. For instance, bridge designs that use light clients and relays or liquidity networks to validate the transactions do not add trust assumptions in the system. Therefore, the root of trust remains on the blockchains associated with the cross-chain transfer.

As we dig deeper into bridge designs, we see that trustlessness in bridges does not exist in an absolute form — rather, some systems are more trust minimized than others. If trusted and trustless were two extremes, most bridges would lie somewhere in between.

Trust as a Spectrum in Bridges

Let’s look at how with bridges, trust is a spectrum.

Note: For this article, we’ve considered bridges as anything that can enable the transfer of assets from one blockchain network to another.

Trust as a Spectrum in Bridges

When it comes to trustlessness in bridges, the main question is: who is verifying the system? By answering this question for different types of bridge designs, we can see that trust as a spectrum in bridges comes down to the following:

• External validators and federations — Externally Verified

• Optimistic bridges — Optimistically Verified

• Liquidity networks — Locally Verified

• Light clients and relays + ZK Bridges — Natively Verified

Here’s a graphic showing where each bridge design falls in the trust spectrum.

Code has no trust assumptions; only humans do. As we move from left (trusted or trust the human) to the right (trustless or trust the code) in the above graphic, the systems become more trust minimized as they remove the need for users to rely on humans and either distribute it across the system or replace it with code.

Let’s look at how these different systems function and why one is more/less trust minimized than the other.

External Validators and Federations — Externally Verified

With externally verified systems, there is a group of validators responsible for verifying any transactions. This set of validators does not belong to either of the two blockchains in the cross-chain interaction. Instead, it is introduced by the bridge to enable communication between the two chains. The bridge’s validator set has its own unique trust assumptions, different from the underlying blockchains. As a result, users are required to trust a new system instead of the generally more secure validator set of the underlying blockchains.

Typically, these bridging systems work by locking the users’ assets in a wallet on the source chain and minting an equivalent amount on the destination chain. This wallet and consensus to mint new assets are controlled and operated by external validators and federations. Examples:

• Multichain has a multi-party custody system.

• Ronin Bridge had a 5/9 threshold multi-sig before the $625 million hack.

Even within the subset of systems that use external validators, different crypto-economic mechanisms can be used to further minimize trust (moving closer to the effectively trustless end of the spectrum). In increasing order of trust minimization, here are a few examples:

Trusted Systems With No Staked Collateral

Validators don’t have to post any collateral. Users essentially have to trust the bridge builders for the security of their funds — relying on their reputation and general goodness that all validators will act honestly. In case of malicious activities, users cannot recover their funds. Example — Binance Bridge

Bonded Systems with Burned Collateral

Validators have to post collateral — which gets burned in case of malicious activities. Disincentivizing malicious activities minimizes trust. However, the system does not guarantee that user funds will be reimbursed if things go wrong. Example — Polygon’s PoS Bridge.

Insured Systems with Slashed Collateral

Validators have to post collateral — which gets slashed in case of malicious activities. This slashed collateral is used to reimburse users if funds are stolen due to the malicious actions of the validators. Trust is minimized by disincentivizing malicious activities and reimbursing users if things go wrong. Example — Axelar.

Edge Case: Systems with Native Token as Collateral

Some bridge systems use their native token as collateral. These systems work similarly to insured and bonded systems but differ by the type of collateral used. In such systems, in the case of malicious activities, the bridge system experiences cascading failures throughout the architecture because, typically, the token plays an integral part in the entire system’s security. With token-based bridges, trust is essentially levered up, where the bridge’s security also relies on the price of a token, making them less trust minimized.

Example — Thorchain requires validators to stake RUNE tokens to ensure the economic security of the system. This collateral is slashed in case of malicious activities and then used to reimburse users. As a result, RUNE, the native token of Thorchain, which was being staked as collateral, will have to be distributed to reimburse the affected users. In such a scenario, it is possible that the selling pressure increases on RUNE and there are cascading effects throughout the Thorchain architecture because of the dropping price of RUNE.

Optimistic Bridges — Optimistically Verified

Optimistic bridges operate similarly to Optimistic Rollups. They use honest watchers in the system to monitor the operations and report fraud. There is a different trust vector with optimistic bridges: a single honest verifier. Optimistic bridges need one watcher in the system to verify updates. As a result, while optimistic bridges permit fraud, an attacker can never be guaranteed to steal funds because there is no way to tell when a single honest watcher is monitoring the system at any given time. This type of design mechanics highly increases the economic cost of attacking the system, making it significantly trust-minimized if not effectively trustless. Example — Nomad

Comparison: Optimistic vs. Externally Verified Systems

Optimistic bridges are fundamentally different and inherently more trust minimized than bridges with external validators. Let’s break this down with the help of an example.

Suppose there’s a security breach and the private keys of a majority of validators in an externally validated system are compromised (ex: Ronin bridge hack). In that case, the attacker will be able to steal all the funds of the bridge because he is now in control of the system. However, in an optimistically verified system, even if the attacker manages to get the private keys of all the validators, he can still not be guaranteed to steal the funds as long as there is one honest watcher in the system that can ‘catch the fraud’ and revoke the attacker’s access to the funds. Thus, the assumptions in both setups are fundamentally different, and, as a result, optimistic bridges are inherently more trust minimized than externally verified bridges.

Twitter Post by James Prestwich

Liquidity Networks — Locally Verified

Locally verified systems leverage the underlying blockchains’ validator set in a given cross-chain swap. Instead of the entire validator set on both chains verifying a transaction, two validators (one from each side) verify the counterparty on the other chain.

Locally Verified — Liquidity Networks

These two validators act as the “routers’ in the liquidity networks that:

a) hold the liquidity pools on each chain,

b) verify each other (the counterparty), and

c) facilitate the atomic swaps.

Such systems typically function using lock/unlock mechanisms and dispute resolution processes to ensure the safety of the users’ funds and effectively leave no way for the validators on each chain to collude and steal funds. Locally verified systems are effectively trustless. Examples — Connext and Hop.

Trustlessness in bridges is not absolute, and this can be seen even with bridges that fall in the same category. For instance, trustlessness between different liquidity network systems, like Connext and Hop, is not the same.

While Connext and Hop both use liquidity networks, Connext has a liveness assumption that achieves scaling by having its Sequencer compute everything off-chain and match Routers to transactions. In contrast, Hop makes trust tradeoffs because of their need for a fast arbitrary messaging bridge (AMB). As a result, it inherits the security assumptions of underlying native bridges of blockchains (ex: Arbitrum native bridge) which often have an externally verified bridge design.

Comparison: Optimistic Bridges vs. Liquidity Networks

Both optimistic bridges and liquidity networks enable the transfer of assets across chains. However, they are different in terms of functionality. Liquidity networks enable fast cross-chain transfers but have limited generalizability, i.e., the ability to transfer messages across chains. In contrast, optimistic bridges allow cross-chain messaging in a trust-minimized manner.

For cross-chain protocols, the ability to pass messages across chains is beneficial and, in many ways, a necessity to offer more functionality. To overcome this limitation, bridges adopt different methods. For instance, Connext, in their Amarok network upgrade, formed a close partnership with Nomad to inherit its trust-minimized communication (with a 30 minutes latency tradeoff).

Another method is to use native bridges of blockchains (ex: Avalanche Bridge, Arbitrum Bridge). However, this method adds trust assumptions to the system because the native bridges of non-rollup blockchains are generally externally verified. For example, Hop uses native bridges of blockchains to fulfill their need for a fast arbitrary messaging bridge (AMB). Similarly, this method is also used by many widely used liquidity network protocols like Stargate, Synapse, etc.

While this method works in a trust-minimized manner for rollups since rollups leverage the security of the Layer 1 blockchain (ex: Arbitrum uses Ethereum’s security), there is a trust tradeoff for non-rollup blockchains given that they are externally verified. Hence, one can argue that optimistic bridges are more trust minimized than some liquidity networks.

Light Clients and Relays + ZK Bridges — Natively Verified

With natively verified systems, all the validators of the underlying blockchains are responsible for verifying the system. Since users rely on the chains’ own verifiers for bridging, these are considered to be the most trustless bridging systems. Example — Cosmos IBC.

Natively Verified — Light Clients and Relays + ZK Bridges

Bridges built on Zero-Knowledge (ZK) proofs also use light clients and relays to validate cross-chain transfers and are considered another trustless option. However, there are not any trustless ZK bridges in production yet. Moreover, building bridges based on ZK proofs is a concept that has not been extensively researched yet, and it’s possible to find new tradeoffs, trust assumptions, and drawbacks as we go further down the rabbit hole.

Closing Thoughts

Once again, we see that the one size fits all approach to “trustlessness” doesn’t apply to bridges. Trustlessness in its absolute form does not exist. With bridges, trust is a spectrum, and there are tradeoffs made for specific use cases that impact trust minimization.

While trust is a spectrum, and one bridge could be more trust minimized than the other, all bridges have their unique strengths and weaknesses. For example, some bridges can offer faster and cheaper cross-chain swaps by having a more trusted approach.

LI.FI wants to aggregate all relevant bridges, inherit their features, and offer our integration partners different options; encouraging them to use certain bridges based on factors such as — use-case, required features, target group, average transfer sizes, expected transfer frequency, supported chains, and others. At LI.FI, while we strive for trust-minimization, we recognize that there’s a need and demand for all types of bridges and thus take a bridge-agnostic approach towards integrations.

If you want a closer insight into how we approach bridge integrations, please read this thread.

We’ve partnered up with the brightest minds and aim to build the best abstraction and aggregation solution available on the market. If you’re a blockchain network, bridge builder, or dApp developer, come talk to us and let’s work together!

Huge thanks to Mark Murdock for all the edits + brainstorming and Pranay Mohan for the insightful feedback. 😄

Get Started With LI.FI Today

Enjoyed reading our research? To learn more about us:

• Head to our link portal at link3.to
• Read our SDK ‘quick start’ at docs.li.fi
• Join the official Discord Server
• Subscribe to our newsletter on Substack
• Follow our Telegram Newsletter
• Follow us on Twitter & LinkedIn

Disclaimer: This article is only meant for informational purposes. The projects mentioned in the article are our partners, but we encourage you to do your due diligence before using or buying tokens of any protocol mentioned. This is not financial advice.