How Across prioritizes security: Canonical Asset Maximalism and intents
Tldr; Cross-chain interoperability protocols frequently make security trade-offs when facilitating value transfers. Across, meanwhile, prioritizes security by leveraging an intents-based architecture to transfer canonical assets. This approach is safer for users because relayers take on the risk when they front their capital.
Key takeaways:
- The advent of cross-chain interoperability has led to an explosion in bridging solutions but many make security trade-offs.
- Designs that use representative assets or messaging burden users with risks.
- Across’ approach, where relayers lend out canonical assets to fulfill user intents, prioritizes security by ensuring the user does not take on unnecessary risk.
Crypto is now unequivocally a cross-chain world. There are multiple active Layer 1 ecosystems, new Layer 2 chains keep emerging, and even Layer 3 is a thing now. This climate has led to the emergence of numerous interoperability protocols that support cross-chain transfers.
These systems are most commonly referred to as “bridges” and they come in many different forms. Bridges face several challenges in supporting their users’ needs, not least ensuring that they stay secure. Users typically go to a bridge when they want to transfer value to a new chain. They ideally want a quick and cheap transfer, and they definitely want their funds to be safe.
As evidenced by the abundance of high-value bridge hacks, many solutions create significant security risks. For part one of our series on Across security, we examine the most common security issues and explore why Across’ focus on canonical assets and intents makes for a safer solution.
Representative assets and new trust assumptions
Bridges can either use canonical assets or representative assets to facilitate transfers. Across uses canonical assets to maintain security but many solutions use representative assets.
Most bridges that use representative assets are known as third-party bridges. As they use representative assets, third-party bridges introduce a new validation mechanism, which introduces security risks.
With such solutions, the user locks up a canonical asset at the origin and a representative asset gets minted at the destination. This introduces several trust assumptions:
- The user must trust the protocol that they lock their funds in, including the robustness of its smart contract code.
- The user must also trust the protocol’s validation mechanism. They must trust the protocol to mint the representative asset and let them redeem it for their deposited funds.
- The user must trust the consensus of the chain they’re interacting with.
In other words, third-party bridges that use representative assets are not trustless. This design poses several risks:
- Third-party bridges have a honeypot effect when they lock up user funds, creating a high incentive to attack.
- If the code contains bugs, attackers could drain the user’s locked funds.
- The validation mechanism could allow attackers to mint an infinite number of representative assets.
- The user takes on a risk that they’ll be able to get their canonical assets back.
With third-party bridges, the user is burdened with risk because no other party (such as LPs) pays for security. There’s no one to front capital or commit canonical assets to a pool: the user must simply accept the minted asset and the mechanism validating their transfer.
Most major bridge hacks involve third-party bridges, including major incidents like the $590 million theft on Ronin Network and $320 million Wormhole exploit that shook the space in early 2022.
How AMM-based mint-and-burn bridges minimize security risks
Despite its flaws, the lock-and-mint design is popular in the bridging space. Some alternatives offer security benefits over traditional third-party bridges. Some solutions mint representative assets through an AMM, allowing the user to make a swap for a token and receive a canonical asset provided by LPs.
This approach is more secure in that it does not create a honeypot effect and the user receives canonical assets. However, it relies on LPs having liquidity available at every destination to serve users.
How liquidity layers use canonical assets to transfer value
Bridges that do not use representative assets can be thought of as liquidity layers for transferring canonical assets. These bridges use delivery vs. payment (DvP) or intents mechanisms.
DvP bridges use liquidity pools to transfer canonical assets. This approach offers benefits over third-party bridges as the user is not required to trust a new asset. DvP bridges typically use messaging systems to verify transfers, where the user receives a canonical asset at the destination once their deposit is verified. This approach has trade-offs:
- While DvP bridges may use trustless verification mechanisms such as Zero-Knowledge Proofs, in many cases the user has to trust the mechanism.
- Messaging systems are often secured by validator multisigs. These entities are responsible for securing that messages are valid, but they are not as secure as the underlying chain, with just a handful of co-signers responsible for securing the protocol.
- Verifying messages tends to be gas intensive and users must wait for finality at both the origin and destination. This results in more expensive, slower transfers.
Other bridging approaches and their drawbacks
Third-party bridges and delivery vs. payment systems each introduce their own security risks when facilitating cross-chain transfers. But there are many other types of risks associated with bridging:
- Bridges may be secured by validators, which requires relying on a group of entities to approve transactions. Validators can collude to act maliciously or be compromised, as was the case with the $590 million attack on Ronin Network in March 2022.
Reducing dependency on a small number of validators, prioritizing private key management, and monitoring network activity can mitigate the risks of such attacks. However, such approaches do not eliminate the risks associated with using representative assets.
- Bridged token standards such as LayerZero’s OFTs and Connext’s xERC20 aim to improve the cross-chain interoperability user experience by offering representative assets that can be used across multiple protocols. However, introducing them creates isolated security standards that rely on trusting one (LayerZero) or several (Connext) parties.
Although many builders have touted bridged token standards as the next big innovation for cross-chain interop, they are not as secure as canonical assets because they introduce trust.
Using lock and minting to transfer canonical assets
While most lock-and-mint bridges transfer representative assets, burdening the user with risk, some use canonical assets. Canonical bridges (also known as native bridges) let users transfer funds without trusting a new contract; they only need to trust the chain’s security. Similarly, stablecoin bridges do not ask the user to trust anything other than the stablecoin and the underlying chain.
Canonical bridges and stablecoin bridges are more secure than other lock-and-mint bridges because they use canonical assets. The user is not asked to trust a new solution with a canonical bridge or stablecoin bridge.
Across and the case for Canonical Asset Maximalism
So far, we’ve explored how different bridge designs make security and other trade-offs. These can be summarized as follows:
- Third-party bridges introduce security trade-offs by asking the user to take on risk. They must trust representative assets and the validation mechanism.
- Third-party bridges create honeypots for hackers.
- AMM-based lock-and-mint bridges offer security benefits at the cost of UX.
- DvP mechanisms typically ask the user to trust the validation mechanism and make UX trade-offs, including slower transfers and higher costs.
- Bridged token standards aim to address the problems associated with using third-party bridges but they are a flawed solution.
- Canonical bridges and stablecoin bridges let users securely lock and mint canonical assets.
Like DvP bridges, canonical bridges, and stablecoin bridges, Across uses canonical assets to let users transfer value.
Bridges that use representative assets introduce trust assumptions and burden users with risks. For that reason, we can conclude that canonical asset bridging is the only trustless way to transfer value. That’s why we like to call ourselves Canonical Asset Maximalists.
Similar to DvP bridges, Across is a liquidity layer that requires external capital to serve users’ needs. However, it does not rely on a new validation mechanism because it uses an intents-based framework.
How intents power Across
In Across’ system, the user makes a deposit at the origin and expresses their intent, i.e. they signal what they want to happen when they arrive at the destination. This could be a transfer or an action such as a token swap.
When a user expresses their intent, relayers compete to fill the order. The user then receives the canonical asset at the destination. If they deposit 1 $ETH on mainnet, they receive 1 $ETH at the Layer 2 they’re moving to.
As Across is powered by intents, the user is not required to take on additional risk. Rather, the relayer takes on the risk when they front their capital. They must wait to be repaid and they take on finality risk on the user’s behalf. These repayments are optimistically verified with UMA’s Optimistic Oracle.
There are some small trade-offs to Across’ intents-based design. Firstly, Across is limited to deploying to chains with their own canonical bridge (though this is not an issue with the most widely used chains). Secondly, the relayers expect a return on their capital. They effectively make a short-term loan to earn interest.
However, the cost of this loan is extremely low. Let’s assume relayers are willing to lend out their capital at a 10% interest rate for a duration of one hour (this figure is an approximation based on market rates).
The 10% rate is annualized, and there are 8,760 hours in one year. That brings the cost of the loan to roughly 0.1 basis points. We can use the below formula to calculate the cost of a relayer loan:
Annualized loan rate ÷ (number of days in a year x number of hours in a day) = Cost of a one-hour loan
10% ÷ (365 x 24) = 0.001%
This means the cost of a $1,000 loan for one hour would be roughly $0.01.
Across also makes significant gas optimizations such as batched repayments, further reducing costs.
Why intents-powered interoperability is the future
In summary, we’ve unpacked how cross-chain interoperability protocols take different approaches to support their users’ needs. In enabling cross-chain transfers, bridges frequently make security trade-offs.
Many solutions introduce new trust assumptions such as representative assets or validation mechanisms. With such systems, the user takes on the risk when they make the transfer.
Across shares some similarities with other designs that focus on canonical asset bridging. But it stands out through its intents-based architecture. Across minimizes security risks by using canonical assets and optimizing for a smooth user experience with intents. In this design, the relayer takes on the risk to fulfill the user’s intent.
Across is an elegant solution that uses canonical assets with intents to offer users the most convenient and secure bridging experience possible. Users get fast and cheap fills and they do not need to worry that their funds are safe. That’s why we’re so sure that intents-powered interoperability is the future.
In the next edition of our security series, we’ll explain how Across’ modular-based architecture maximizes security and decentralization. Keep an eye out for more in the coming weeks.
