Discover the engineering behind Across’ latest innovation in interoperability, the Universal Bridge Adapter. Bridging Across to more communities and their ecosystems.
Introduction
The Across team has been dedicating itself to building innovation in interoperability in advance of the inevitable surge in cross-chain traffic. Across’ bridge design employs a hub and spoke model to efficiently facilitate value transfer between various networks. A key requisite in any cross-chain liquidity network is the ability to rebalance capital, ensuring there is enough liquidity on each chain to support the needs of users.
Across’ current architecture relies on a central HubPool to connect with multiple peripheral SpokePools on Layer 2s, with native, protocol level rebalancing via canonical bridges. The use of canonical bridges is a nuanced and differentiating advantage to Across — it allows the protocol to natively rebalance assets between mainnet and Layer 2s at no cost, without having to rely on, and pay for, rebalancing from external parties like arbitrageurs. While this design has been effective in streamlining cross-chain communication and reducing complexity, it presents certain limitations, particularly in supporting high volume EVM chains which do not have native canonical bridges.
The implementation of the Universal Bridge Adapter (UBA) aims to overcome these constraints, by providing a standardized and modular framework for connecting any EVM-compatible blockchain using a novel incentivized rebalancing mechanism when canonical bridges aren’t available. In effect, the UBA combines the best of both models: Across can efficiently rebalance at the protocol level when canonical bridges are available, and via external incentives when they aren’t.
For current Across users, on the surface this product upgrade will enable the ability to add support for any EVM chain at a much faster pace, and further reward depositors who bring the protocol closer to its target liquidity balance on each chain. However, on a deeper and longer term level, this upgrade includes the ability to include any message with a bridge transfer and opens up a fundamental shift for Across to push the boundaries on interoperability (stay tuned for a future piece on Composable Bridging 😀).
In this technical deep dive, we will explore the engineering design and principles behind the UBA, demonstrating how it progresses interoperability to optimize value transfer across blockchain networks.
Core Components of the Universal Bridge Adapter (UBA)
The UBA comprises two main components:
Trustless message passing via the Telepathy protocol from Succinct
Incentivized quoting system to reward or penalize flow depending on the global liquidity state of SpokePools
Trustless Message Passing via Telepathy
Across requires the ability for the HubPool on mainnet to send messages to SpokePools. This is a fundamental aspect of protocol operation, and Across currently uses canonical bridges to instruct SpokePools to release refunds to relayers on the chain they desire, enables users’ deposits to be filled when there isn’t sufficient relayer fast capital (“slow relays”), and rebalancing between different SpokePools.
But when a chain doesn’t have a canonical bridge, as many high usage EVM L1s do not, Across needs a different solution to perform these operations.
The most important factor when evaluating potential solutions was to maintain the trustlessness of the message passing system. Canonical bridges are generally trustless implementations involving light clients on the L2 running consensus to verify transactions on L1 (and vice versa), meaning these types of bridges share the same security guarantees as the consensus mechanisms of the chains they connect. To maintain this level of security and trustlessness, Across has harnessed the power of Succinct’s zkSNARK proof of consensus, Telepathy. At a high level, this can be thought of as swapping out the canonical bridge for Succinct’s Telepathy ZK message bridge when no canonical bridge exists. This works perfectly for our use case given Across only requires message passing from L1 to L2 (unidirectional).
To understand the details of how Telepathy works, we’ll walkthrough an example. As previously mentioned Across’ relayers take the finality risk and release funds to the user optimistically, which requires them to request a refund from The HubPool. To function correctly, the HubPool on Ethereum needs to send a bundle of data to a SpokePool on a connected spoke blockchain (e.g., Avalanche C-chain), so that these refunds can be issued to relayers.
The HubPool integrates its Ethereum contract with the Telepathy Router, which acts as a bridge between Ethereum and other blockchains. This router has a send function that requires destinationChainId, destinationAddress, and data parameters to determine the SpokePool contract on the spoke blockchain and the bundle data content.
After the HubPool’s contract calls the “send” function, it waits for up to 12 minutes for the transaction to finalize on the Ethereum hub (Ethereum network speed limitation). To trustlessly verify Ethereum state on another chain, a Light Client checks if a block header has signatures from a significant percentage of Ethereum validators. However, this is expensive, so Telepathy uses a zkSNARK to provide a much more affordable validity proof.
The Telepathy Light Client verifies zkSNARKs, which contain validity proofs of Ethereum’s Light Client Protocol, to securely access Ethereum’s block headers on the spoke blockchain (Avalanche C-Chain, in this example). An off-chain relayer then provides merkle proofs, which are verified inside the Telepathy Router contract.
Lastly, the Telepathy Router assumes that the SpokePool contract on the spoke blockchain implements the “handleTelepathy” function, allowing the SpokePool to process refunds based on the received bundle data. The SpokePool is designed to only accept refund instructions from the HubPool, ensuring secure and controlled processing of refunds to relayers.
The security of this hub and spoke design relies on the honesty of the Ethereum validator set, as block headers are only approved if they have enough validator signatures. The protocol is secured by on-chain checks, and core contract functions are permissionless.
Integrating Telepathy within Across bridge’s hub and spoke design model enables seamless interaction between the HubPool on Ethereum and the SpokePool on connected blockchains for refund processing.
Incentivized Quoting
In the current architecture, Across uses canonical bridges to rebalance pools at the protocol level, removing the need to pay any external actors or arbitrageurs to bring pools back into balance. But, similar to the message passing problem when no canonical bridge exists, Across also needs a way to send tokens across chains to rebalance pools.
Succinct’s Telepathy system is a message passing system from L1 to L2 (unidirectional), and is not currently set up to be used as a token bridge for L2s (requiring bi-directional messaging). So while Succinct solves the L1 to L2 messaging passing problem, Across still needs a way to send tokens bi-directionally between L1 and L2 to rebalance pools.
The solution is to incentivize external actors to keep pools balanced via a pricing mechanism that rewards or penalizes users depending on the global state of all pools. This is a nuanced change and evolves Across into a hybrid model where we combine the benefits of protocol level rebalancing where canonical bridges exist, with the flexibility of external incentives when canonical bridges don’t exist, all on top of our novel interest rate bridging model.
The incentivized pricing system involves tracking the state of pools against a target balance for that pool, and then rewards users (end users or relayers) who move the pool’s balance closer to its target, and penalizes those who move the balance further away.
For example, consider:
A user, Alice bridging away from Chain A
A relayer, Bob taking a refund on Chain A
A user, Susan bridging away from Chain A
To start, Chain A’s SpokePool balance is lower vs. its target, and when Alice bridges away, she deposits her tokens into Chain A’s SpokePool. This increases the SpokePool’s balance past its target balance, incurring both a reward (for the portion Alice is bringing the pool balance closer to target) and a penalty (for the portion Alice is bringing the pool away from target). Both rewards and penalties are represented as a change to the underlying bridge fee (lower fee when rewards are incurred, higher fees for penalties).
Then Bob, a relayer, elects to take his repayment (remember relayers front money to end users and then get repaid later by liquidity providers) on Chain A, which reduces the SpokePool balance as it is used to repay Bob. This brings the pool balance closer to its target, and Bob is entitled to a reward in the form of an increased relayer fee.
Lastly, user Susan bridges away from Chain A, increasing the pool balance far above its target. Susan incurs a penalty for this in the form of an increased bridge fee.
Generalizing the above, each SpokePool has a target balance, and when it gets out of balance, the underlying bridge fees change relative to the direction an event moves the balance. If an event (an end user deposit, or a relayer refund) moves a SpokePool balance away from its target, a penalty is applied, and if the event moves the balance closer to its target, a reward is applied.
By incorporating an incentivized quoting system, the UBA ensures a more efficient allocation of resources within the SpokePools, promoting a sustainable and capital efficient cross-chain liquidity system. This feature not only optimizes asset distribution but also contributes to a seamless and cost-effective user experience by enabling a hybrid approach to maximizing capital efficiency of pool rebalancing.
Conclusion
The Universal Bridge Adapter (UBA) is a testament to Across’ commitment to innovation and the pursuit of a more interconnected, accessible, and secure decentralized finance ecosystem. By diving into the engineering ingenuity behind the UBA, we hope that it is now clear how its core components and design principles solidify the security behind token asset transfers to new destinations at Across.
Across Protocol is an intents-based interoperability protocol, capable of filling and settling cross-chain intents. It is made up of the Across Bridge, a powerfully efficient cross-chain transfer tool for end users, Across+, a chain abstraction tool that utilizes cross-chain bridge hooks to fulfill user intents and Across Settlement, a settlement layer for all cross-chain intent order flow. As the multichain economy continues to evolve, intents-based settlement is the key to solving interoperability and Across is at the core of its execution.