As the crypto ecosystem has matured, so has the proliferation of many chains, each with their own unique ecosystems and user bases. One of the core pieces of infrastructure that has enabled these differing chains to transfer value to each other is “bridges”. Just as chains have proliferated so have the mechanisms to exchange value cross-chain. In this report, we will explore the cross-chain ecosystem today and walk you through some key concepts like:
Fundamentals of bridges
Benefits/risks of bridging
The Interoperability Trilemma
Examples of cross-chain implementations and use cases
Latest developments in the cross-chain world
Essential terminology
Light Client: Allows users to sync with a blockchain in a cryptographically secure manner without having to store the entire chain. Can be used to determine the state of an account, check the status of a transaction, or watch for logged events
Relay: Contract on one chain that functions as a light client of another, using the latter’s standard verification procedure to verify block headers fed into the contract. This gives the former chain the ability to understand event changes on the latter
Relayer: Every bridge has relayers. These are intermediaries sending information from source to destination and can be on-chain or off-chain
Zero-Knowledge Proof: Method by which one party can prove to another that a given statement is true without revealing any additional information apart from the fact that the statement is valid
State: The current status of a network, including the state of all transactions, smart contracts, and other data stored on the network. The state of the network is updated every time a new block is added to the chain
Liveness: Guarantee that a protocol can exchange messages between the network nodes, allowing them to come to a consensus
Oracle: Entity that connects blockchains to external systems, allowing smart contracts to execute depending on real-world inputs and outputs
Sequencer: Processes transactions, produces rollup blocks, and submits batched rollup transactions to the L1. Has priority access to the rollup chain and is the only entity allowed to submit transactions to the on-chain contract
{{kado-ramp}}
TLDR
Bridges are an essential piece of infrastructure that enable cross-chain value transfer
Bridges can be divided into two categories: Trusted and Trustless: Trusted bridges rely on a central entity and have trust assumptions with regards to custody of funds and security, Trustless bridges function through smart contracts and algorithms, allowing users to remain in control of their funds
Benefits of cross-chain bridges include: Lower transaction fees, Access to different ecosystems and multi-chain apps
Risks of cross-chain bridges include: Smart contract risk, Censorship risk and Custodial risk
Different types of bridges include: Native Bridges, Liquidity Networks and Data Messaging Protocols
The interoperability trilemma states that bridges can only have two of the following three properties: trustlessness, extensibility, and generalizability
Building blocks of bridges include: Fraud/Watcher/Monitoring, Relayers, Consensus and Signatures
Sub-types of cross-chain protocols include: Custodial Bridges, Multisig Chain-Specific Bridges, App-Specific Bridges and Generalized Cross-Chain Messaging
Trustlessness in cross-chain bridges is determined by the group responsible for verifying the system
Bridges can be grouped into 4 categories based on the level of trust required: External validators and federations, Optimistic bridges, Liquidity networks and Light clients and relays + ZK bridges
The level of trust in bridges varies based on the mechanism used, the number of validators, and the security provided by the underlying chains
Circle CCTP introduces a new category of bridges: stablecoin bridges
Bridge aggregators along with Kado simplify UX for the end user
Intro to Bridges
Bridges generally fall into two categories: Trusted and Trustless
Trusted bridges:
Depend upon a central entity for operations.
Have trust assumptions with respect to the custody of funds and security of the bridge.
Users need to forfeit direct control of their crypto assets.
Trustless Bridges
Function through smart contracts and algorithms.
Trustless: Security of the bridge is the same as that of the underlying blockchain.
Users remain in control of their funds through smart contracts.
Ideally, trustless bridges are the preferred solution as they minimize trust assumptions, which add external verifiers that render the system less crypto-economically secure.
Benefits
Some of the benefits of living in a cross-chain world:
Lowered transaction fees: Bridges enable users to access different chains, e.g., L2s with lower fees than Ethereum mainnet
Apps with multi-chain presence: Many apps live on multiple chains and may offer differing UX that users may want to take advantage of, e.g., better rates/more liquidity
Explore ecosystems: Users can access apps that are unavailable on the chain they typically transact on. This can even extend to cross-chain applications making different combinations of chain ecosystems possible
Risks
Smart contract risk: Bugs have caused users’ funds to be lost, e.g., the $322M Wormhole exploit that took place on Feb 2, 2022
Censorship Risk: Bridge operators can prevent users from transferring assets in trusted set-ups
Custodial Risk: Bridge operators can collude to steal user funds in trusted set-ups
Bridge Categories
Native Bridges: Designed with asset transfers between two blockchains in mind. Typically intended to bootstrap liquidity on the destination chain and are mostly limited to two chains. Includes the subcategory of rollup bridges, where trust is minimized by inheriting security of the L1 it is bridging to. Examples:
Liquidity Networks: Make use of liquidity pools to exchange assets on one chain for the desired assets on the other chain using an atomic swap mechanism. These are considered more secure as they provide users with native assets versus wrapped assets. Examples:
Arbitrary Messaging Bridges (AMBs): Enable the transfer of data and messages across chains in addition to assets. This allows for more complex cross-chain strategies.
Bridge designs are constrained by the interoperability trilemma. Coined by Connext founder Arjun Bhuptani, this states that bridges or interoperability protocols can only have two of the following three properties:
Trustlessness: The security of the bridge is that of the underlying blockchain
Extensibility: Protocol’s ability to be supported by any chain
Generalizability: Protocol’s ability to process arbitrary cross-chain data
Bridge Building Blocks
These are the components that generally make up bridge and cross-chain messaging protocols with varying combinations depending on the configuration:
Fraud/Watcher/Monitoring: State monitors, e.g., validators, light clients, or oracles.
Relayers: In charge of message passing taking info from source to destination chain which operates off-chain.
Consensus: Agreement between actors monitoring the chains, e.g., a trusted third party validator set (Axelar) or an off-chain network of consensus nodes, or a multi-sig.
Signatures: Actors cryptographically sign messages, e.g., validators signing a cryptographic signature (IBC), or through a ZK Proof (Polymer) that attests to the validator signatures from the source chain.
{{kado-otc}}
Bridge Sub-Types
Custodial Bridges: Often asset specific. Provide wrapped assets that are collateralized in a custodial (third party) or non-custodial (smart contract) way, e.g., WBTC which is operated by a centralized organization in BitGo.
Multisig Chain specific: Usually two-way bridges between two chains, e.g., Avalanche Bridge, which connects to Ethereum via an Ethereum smart contract. Users typically send an asset to the protocol, where it’s held as collateral, and are issued a bridge-wrapped token on the destination chain, collateralized by the asset locked on the source chain. Often protected by a set number of validators or a multi-sig.
App-specific: Application that provides access to multiple chains but used specifically for that particular app, e.g., Thorchain. Trust assumption often lies within a single validator set that controls all messages/transactions across the network connecting to various smart contracts/addresses on multiple chains.
Arbitrary Messaging Bridges (AMBs): Allow for generalized messaging across protocols, e.g., IBC. Usually dependent on validator sets. Trust lies with the two connected chains’ validator sets.Often used in tandem with liquidity layers as they typically only handle communication and standards between chains based on their specifications, e.g., Cosmos app-chains act as liquidity layers for IBC.
Cross-Chain General Messaging: Use Cases
Cross-chain general messaging can enable new types of applications. Here are just a few of the possible use cases:
Cross-chain lending: Post your asset/NFT as collateral on Chain A, and borrow against it on Chain B seamlessly.
Governance: Cast governance votes for a multichain dApp on different chains.
Universal DeFi liquidity: Instead of fragmenting liquidity through bridges, liquidity can remain on the native chain.
NFTs and Gaming: Ability to transfer and verify ownership of NFTs across chains/games.
The Bridge Spectrum of Trust
Trustlessness in bridges is ultimately determined by who is verifying the system. This can be grouped into the following categories, which become more trust minimized as you move further along the trust spectrum as they mitigate the need for human input by distributing across the system or replacing it with code.
External validators and federations - Externally Verified: There’s a group of validators responsible for verifying any transactions. This validator set doesn’t belong to either of the two blockchains in the cross chain interaction. The bridge introduces this to enable communication between the chains. It has its own unique trust assumptions separate from the underlying chain. Users must place trust into this system instead of the more secure validator set of the underlying chains. These typically function by locking the users’ funds on the source chain and minting the corresponding amount on the destination chain.
Within the category of external validators, various crypto-economic mechanisms are implemented, which shifts these systems along the trust spectrum. For example:
Trusted systems with no staked collateral: Users must fully trust the bridge providers for the security of their funds as no collateral is posted (Binance Bridge).
Bonded systems with burned collateral: Validators post collateral that gets burned in the event of malicious activity. Trust is minimized by the disincentivization of bad actors, but users are not guaranteed their funds returned (Polygon PoS Bridge).
Insured systems with slashed collateral: Validators have to post collateral, which gets slashed in the event of malicious activity. The slashed amount goes towards making users whole if funds are ever exploited (Axelar).
Optimistic bridges - Optimistically Verified:
These operate similarly to optimistic rollups. Honest watchers are tasked with monitoring the system for safety. All that is required is one honest watcher to report fraudulent activity. This significantly increases the cost of attacking the system, thus making it significantly trust minimized if not effectively trustless. (Connext).
Liquidity Networks - Locally Verified
Locally verified systems leverage the underlying chains’ validator set in a given cross-chain swap. However, only two validators are involved in verifying transactions: one from each chain validates the other counterparty. These validators act as “routers” that hold the liquidity pools on each chain, verify each other, and facilitate atomic swaps.
These networks typically involve lock/unlock mechanisms and dispute resolution processes to ensure safety of user funds, effectively leaving no way for validators on each chain to collude and steal funds. They are effectively trustless (Hop).
Light clients and relays + ZK bridges - Natively Verified
In natively verified systems, all validators of the underlying chains are responsible for verifying the system. As users rely on the chains’ own verifiers for bridging assets, these are considered the most trustless bridging systems (Cosmos IBC).
Bridges built on Zero-Knowledge (ZK) proofs also use light clients and relays to validate cross-chain transfers. (=nil; foundation working on this for Mina protocol, Polymer)
Cross-chain Implementation Examples
Here are some examples of cross-chain protocols and how they function under the hood
IBC: This requires a light client on each other’s chain to verify consensus state between the two and a relayer to relay info between the light clients, which ensure liveness. Trust assumptions lie within the two validator sets of the connected chains and crypto-economic security is the total stake of the chains.
Polymer: An IBC Routing protocol. This can be considered an AMB. Light clients/smart contracts verify block headers. Cryptographic proofs are posted through validator signatures and ZK Proofs on non-Cosmos chains (zkIBC). zkIBC reduces the high cost of verification associated with light-based bridges. Crypto-economic security consists of the stake of the chains connected to IBC, whereas the trust assumptions depend on the smart contracts for non-IBC chains.
Axelar: This relies on an external validator set of the Axelar chain to run nodes/light clients on the chains onboarded. Allows for general message passing cross chain and targets applications to implement Axelar as a messaging protocol, similar to IBC. It also has more validators than Wormhole and can be considered more secure as it is an insured system whereby validators must post collateral at risk of getting slashed.
Layer-Zero: This is composed of two entities: an oracle and a relayer. Apps are given the flexibility to use L0’s default oracle/relayer or run their own. Used as a cross-chain messaging protocol, while bridges can be built on top of it (Stargate). If both entities are dishonest, exploitation is possible, which emphasizes the necessity of using a decentralized oracle network. Doesn’t rely on a third-party chain as is the case with Axelar, but instead on a modular architecture with varying degrees of security and trust.
Wormhole: This is a “lock and mint” AMB where users receive a wrapped asset on the destination chain. It introduces a set of external validators (watchers) responsible for verifying transactions, which adds unique trust assumptions as the validator set does not belong to the underlying blockchains. Relies more on the social factor that Wormhole validators are invested in their reputation so as to avoid engaging in malicious activity.
Connext Amarok: This builds on canonical bridges, e.g., Optimism, Arbitrum, Polygon PoS Bridges. Betting on rollup-centric future and ZK light client implementations as public goods for non-rollups. Aim to minimize risk for users by plugging into battle-tested bridges to transport and secure messages instead of building from the ground up. Modular Execution bridge: functions by optimistically relaying data between domains and falling back on the security of the canonical bridge. Use their own sequencer to aggregate messages. Essentially, Connext is an application-specific Optimistic Rollup specifically designed to synchronize the state of other rollups.
Rollup Bridges (Optimism/Arbitrum): Assets are locked in an L1 smart contract, which become available on the L2 rollup. State and proofs are verified on the L2 contract, deriving security from the L1 layer. Allow transacting via the L1 (force exit) if the sequencer fails. These are trust-minimized bridges.
Cross-Chain Transfer Protocol (CCTP)
Recently, Circle announced the Cross-Chain Transfer Protocol, which enables USDC to flow natively cross-chain. This eliminates the need for wrapped versions on various chains, thereby removing a trust assumption from the equation. Through Circle’s protocol, developers will be able to create seamless one-click, multi-chain experiences on connected chains.
The fragmentation of cross-chain UX today can generate friction for users, while layering on risks and additional costs. Users are tasked with navigating differing UIs, submitting multiple transactions, and interfacing with multiple wallets. They have to deal with various wrapped versions of USDC on different chains, which can add confusion, complexity, and risk with handling their funds. They must trust liquidity providers to fulfill swaps, which makes transferring funds capital inefficient and often comes with additional fees. These are all hindrances when it comes to encouraging adoption.
CCTP effectively uses the same burning and minting process as a commercial Circle Account to move USDC natively across chains. This allows CCTP enabled apps to empower users to never have to think about which chain they are holding USDC, which simplifies UX and increases accessibility. Cross-chain transactions are also not subject to slippage as no liquidity pools are involved - users must only pay for gas.
Here’s how it works under the hood:
Burn USDC on the source chain: User initiates a cross-chain transaction from an app on the source chain, which triggers the USDC to be burnt.
Attestation: Circle attests to the burn on the source chain, providing authorization to mint the corresponding amount on the destination chain.
Mint USDC on the destination chain: The app uses the attestation to facilitate the mint of USDC on the destination chain.
CCTP introduces a new category of bridging functionality by USDC. This has major implications for the cross-chain landscape as the majority of cross-chain volume is denominated in stablecoins.
As CCTP is expected to expand to additional chains, it will give rise to many use cases that can overhaul the cross-chain experience :
Simplified, mainstream UX: Users can explore and interact with cross-chain dApps without ever leaving their native chain or wallet. The process of navigating different chains is abstracted away so that the user can facilitate USDC positions on e.g., Cosmos app-chains from their Ethereum wallet.
Cross-Chain NFTs: USDC holders can buy and receive NFTs on various chains without directly interacting with them and interfacing with a new wallet. This can greatly reduce friction.
Seamless cross-chain swaps: Users can perform seamless cross-chain swaps across native assets from distinct chains. Example: ETH can be swapped for native SOL using USDC as the intermediary asset. The process is abstracted away from the user, and bridges are not needed as the transaction only involves native assets.
{{kado-integrate}}
Bridge Aggregation
With all the fragmentation in the cross-chain industry, bridge aggregators provide much needed simplicity for the end user. They aggregate bridges and abstract complex decision making away from users and developers leading to a significant UI/UX upgrade. LI.FI is one example that wants to aggregate all relevant bridges, inherit their features, and offer integration partners the freedom of choice. They’ve integrated multiple DEXs into one interface, bundled together multiple bridge solutions, and built a set of smart contracts that discovers the most efficient method of swapping tokens in one click.
In a sense, aggregation is another way to promote the ethos of decentralization in that it avoids a single point of failure by providing users and developers many options to choose from.
Kado is the Gateway to the Cross-Chain World
Kado’s role in all this is to simplify the UX in an end to end solution. By connecting fiat rails to crypto rails, we enable users to seamlessly interact with cross-chain applications directly from their bank accounts.
Ultimately, Kado aims to grow with the Web3 ecosystem to facilitate a wide array of use cases while abstracting away the complexity of navigating the multi-chain world. By enabling users to swiftly move funds in and out of their self-custodial wallets and dApps, Kado aligns itself with the trustless, decentralized, and open internet enabled by Web3.
