Hello,
This is a discussion to describe the design for Angle bridge and cross-chain setup for agTokens we had thought of within the Core team.
Context
With the upcoming Polygon launch of the Borrowing module and the planned deployment of Angle on other chains after that, it is time to think about a scalable setup for agEUR to be bridgeable and easily exchangeable between many different chains.
So far, Angle relied on only one bridge solution per chain. This docs page summarizes how you can get agEUR and ANGLE across different chains.
The problem with this approach is that agEUR contracts on other chains are not necessarily controlled by the Angle DAO and do not have the right interfaces to plug the Borrowing module on it.
Consequence if we were to stay like that would be that most likely we would have different versions of agEUR on a given chain and would need a Curve pool to reconcile standards and easily trade from one version to another.
On Optimism for instance, we could have a native agEUR and a Multichain (Anyswap) agEUR, which correspond to two different contracts.
UX could potentially become a nightmare as users interacting with agEUR would have to constantly swap between different agEUR versions. Liquidity would be even more fragmented.
Other issue with this approach is that it makes the protocol dependent on a single bridge for each chain. This year, with all the bridge hacks that happened, showed that bridges are probably one of DeFi riskiest components.
Depending all on one bridge drastically increases the surface of exposure of the protocol in case a hack happens.
With this in mind, we propose here an alternative setup for agEUR cross-chain setup.
Overall goals
The end goals we should look for in our bridge setup are the following:
- Keep only one standard for agEUR across any chain so that there’s no problem of swapping between one representation of agEUR to another
- Make the UX for bridging from one chain to another seamless and hide to reduce the friction of interacting with agEUR
- do not depend only on one bridge to reduce the exposure of the protocol to what could happen in case a bridge gets hacked.
Design Proposal
Proposal here is the what would be implemented on Polygon, and more generally all subsequent chains that are voted by the DAO.
The idea is to rely on a single native token that can be minted either:
- from the protocol (like through the borrowing module)
- or from other bridge tokens
Let’s say that I bridge agEUR using Multichain (Anyswap) on Optimism: I get any-agEUR. Then any-agEUR can be used to mint at a 1:1 rate (and with potentially small fees) the native agEUR on this chain.
This would work with Anyswap, but with any other bridge solution. This would allow agEUR to be bridgeable from different bridges and reduce the frictions for users trying to get agEUR on a given chain.
Implementation for this design of cross-chain agEUR can be found here.
This responds to the first goal stated above but how does it fit with the 2nd and 3rd goal?
Diversifying exposure to bridges
Let’s begin with the 3rd goal of diversifying the exposure of the protocol to different bridge solutions.
This solution allows the protocol to support multiple bridge solutions for agEUR. While in the previous design, a bridge hack meant that all the tokens on the chain where the bridge is hacked would be worth 0, now it is possible for the protocol to control through limits the exact amount of bridge tokens that can be used to mint of the native agEUR.
We could for instance choose to have 30% exposure to Anyswap, 10% to Celer, 30% to Synapse and 30% to Layer Zero. A bridge hack of Celer would mean that only 10% of the total supply of bridged agEUR is impacted: instead of having the bridged agEUR worth 0, it’s now worth only 0.9€.
On top of that, we propose to add multiple safeguards to mitigate the way the hack of a bridge could impact the protocol. The way a hacked bridge could impact the protocol is that the attacker could mint a lot of bridge tokens get the canonical token and bridge back using the other supported bridges. An attacker could simply directly bridge back to Ethereum mainnet, in which case it would be capped by what has already been bridged from this chain.
Having an hourly limit of mints allows to mitigate the impact of a hack and leaves enough time for the mint/burn functionality to be paused before everything is drained.
We have so far a strong preference for LayerZero in terms of bridge solution since the contracts for the bridge tokens would also be deployed and controlled by the DAO.
Keeping a simple UX
While this solution works well to diversify exposure to bridges, how can we still make the UX simple for our bridge users?
From what was described, UX could be as follows: bridge using a bridge solution (like Anyswap or LayerZero) and then wrap the obtained bridge tokens.
This requires two transactions which is far from ideal.
We are currently working with some bridge solutions like LayerZero to have all this done under the hood in a single transaction. Flow that happens during the bridge transaction is then as follows when bridging from Eth to Polygon
- Create bridge transaction on Ethereum
- Bridge mints, on the destination chain, bridge tokens (called OFT or omnichain fungible tokens in the case of Layer Zero) to the bridge token contract itself which then calls the native token contract and sends the tokens it minted on itself to get native tokens to send to the destination address.
There are several sub-tx happening in the destination chain, but all of these are hidden to the user which ends up getting native tokens directly.
When bridging back, flow is as follows:
- call the bridge token contract
- the bridge token contract pulls the native tokens from the user address
- It then asks the native token contract to burn its tokens and in return the native token contract sends bridge tokens to the bridge token contract which burns it.
- create transaction on the destination chain
In our LayerZero implementation, we have also paid attention for the transactions never to revert on the destination chain (because of a require or so), otherwise funds could be stuck on the source chain.
As such, if there were to be too many tokens to mint on the destination chain, users would end up getting bridge tokens they could later convert to native tokens.
This is a bit technical but this is by preparing this kind of calls across all our bridge tokens that we’ll get a simple interface. Eventually, we should have a simple bridging interface in our app.
Risks and UX comments
Overall, the approach we are proposing is designed to optimize UX and reduce frictions while keeping something as safe as possible for the protocol.
But this does not go riskless.
First, even with the limits and hourly limits, the hack of a bridge may impact a protocol:
- if ETH mainnet is the base chain, an attacker could drain all the agEUR that were used to bridge to other chains from this bridge
- On the destination chains, one hack could be that the attacker mints a lot of bridge tokens to get native tokens, to get the bridge tokens associated to other bridges and then mint back to mainnet. With limits, it is possible to prevent such attacks and prevents attackers from drain everything related to other bridges as well in case of a hack.
One invariant that is important to keep in mind is that there should never more agEUR on Ethereum than what has natively been minted there. As such the hack of a bridge on a chain should not impact the way agEUR behaves on Ethereum mainnet, and bridge risk is only restricted to agEUR issued on other chains. The failure of one bridge won’t lead the protocol to get under-collateralized or agEUR to lose its peg.
This invariant creates some small limitations: let’s say lots of agEUR are issued on Polygon and the owner wants to bridge them to mainnet, then the owner will have to wait for enough agEUR to have been bridged from Eth mainnet to Polygon to do the reverse move.
On the same topic, if a new bridge is launched, then to bridge back to a chain using this new bridge, users would have to wait for others to have done the bridging from ETH mainnet to the destination chain using this bridge.
For some bridges there will be a small exception for transactions that do not have anything to do with ETH mainnet.
Let’s say LayerZero is launched as a bridge solution between Optimism/Polygon and ETH mainnet. At the bridge initialization, it is going to be possible to bridge from Optimism to Polygon and Polygon to Optimism without any prior transaction because the native contract will be seeded with some amount of bridge tokens to reduce frictions that would otherwise make such movements impossible.
Conclusion
Thanks for having taken the time to read this pretty technical description of what can be a crucial step in making sure agEUR is available smoothly and everywhere with deep liquidity.
A good cross-chain and bridge setup is needed to make agEUR a base money layer for DeFi
If you have any thought, comment, question, please feel free to share it here, happy to collectively think in how to improve this infrastructure!
