BGD. Technical high-level review of cross-chain GHO
Introduction
The following is an analysis/review of cross-chain GHO, from a high-level point of view focusing on architectural points, to complement the more low-level security reviews performed by security contributors to the DAO like Certora.
Given that software architecture can be pretty subjective, we try to present our conclusions in a neutral manner, with the following goals:
- How well the architecture of the new system fits into all existing Aave infrastructure.
- Finding any potential high-level problems, from bugs, to problematic usage flows of the system in both DAO and user operations.
- Provide our subjective opinion as experts on all-Aave, while being constructive to the main contributor of this project (Aave Labs).
Props to the @AaveLabs team for sharing the necessary resources used in this analysis and answering all our questions.
Analysis
Ethereum ↔ non-Ethereum: lock/release ↔ mint/burn
The approach of using Ethereum as a “custody” network for bridged GHO is elegant in our opinion, and following similar architecture as other multi-chain systems of the Aave DAO, like its governance: Ethereum is the core where more security assumptions are deposited, while the other networks connected to Ethereum act as additional environments to more optimal use cases.
It is also good to have Ethereum as “source-of-truth” from where the aggregated size of minted GHO can be queried any time.
Implementation-wise:
- Evaluation of the third-party technology used (CCIP) is outside of this analysis, but the usage of the
UpgradeableLockReleaseTokenPoolandUpgradeableBurnMintTokenPoolseems correct. - Adding upgradeability to the pool contracts is a reasonable choice, and our recommendations are:
- Disable initialisation of the implementation (if not creating any problem to CCIP, which should not) on the constructor of the pool contracts.
- Given the contracts have at least a proxy admin and
ownerroles, set as proxy admin theProxyAdmincontracts already in use for the other systems of the Aave DAO. They can be found on https://search.onaave.com/?q=proxy_admin
- We did some minor recommendations on the code pull request.
non-Ethereum ↔ non-Ethereum: burn/mint ↔ mint/burn
While to transfer GHO from/to Ethereum the lock/release ↔ mint/burn model is used, the current cross-chain GHO architecture also covers the case of non-Ethereum to non-Ethereum transfer, even if initially only Ethereum and Arbitrum will be deployed.
In this case, the flow of funds happen via pure burn/mint ↔mint/burn: to hypothetically bridge 100 GHO from Arbitrum to Optimism, the 100 GHO would get burnt on Arbitrum and minted on Optimism.
Similar as with the approach on Ethereum ↔ non-Ethereum, this is perfectly legitimate. The pool contract used in this case will be limited to UpgradeableBurnMintTokenPool, and our previous implementation recommendations apply the same.
GHO token contract on non-Ethereum networks
Given that non-Ethereum networks (e.g. rollups) are by general rule more prone to changes, we agree with Aave Labs that making the GHO token smart contracts upgradeable is a perfectly reasonable decision, with upgradeability being managed by the Aave governance.
As a small suggestion, we recommend to expand the documentation (potentially with code diffs) about the differences between Ethereum’s GHO and non-Ethereum’s, complementing the PR.
The non-rollback problem and bridge-limit
In the presented cross-chain GHO architecture, there are mainly 2 entities with different types of permissions in the system:
- Aave DAO, via its governance contracts. Acting as “super-admin” of the system, capable of giving/revoking permissions, update GHO token configurations (e.g. bucket-sizes) or of cross-chain GHO infrastructure (e.g. rate limit, bridge limit)
- Chainlink CCIP infrastructure. Whenever an user “signals” a bridging by locking or burning GHO in one network, the CCIP infrastructure handles listens/verifies the action, and processes the minting/release on the destination network.
To do that, the CCIP infrastructure itself has appropriate permissions on the token pools.
This architecture is completely legitimate, following an Actor model approach: the Aave DAO and CCIP act asynchronously and independently. We will not go into the theoretical details of the model or its application in networking, but the cross-chain GHO system, similar as others like a.DI, follows a fire-and-forget principle approach on the surface: once tokens are locked/burnt to “send” to a different destination, it is assumed that or 1) they will “arrive” somehow (will get minted/released to the user) or 2) it is responsibility of the underlying bridging infrastructure (CCIP) to manage retries.
Both ourselves during the review and the @AaveLabs team realised an architectural problem related with the (current) lack of a rollback mechanism on CCIP, which can be better illustrated with a practical example:
-
Let’s assume that bucket capacity of cross-chain GHO on Arbitrum is 1000 GHO and on Optimism another 1000 GHO, and both are filled.
-
Now, 2 actions happen at almost the same time by different actors:
- An user decides to bridge 500 GHO from Optimism to Arbitrum.
- The Aave DAO (on Ethereum) via governance executes a payload to reduce bucket size capacity of cross-chain GHO on Arbitrum to 500 GHO.
Something very important in this scenario: the token pool contract on Optimism used by the user to bridge to Arbitrum has no knowledge at all that the bucket size of the recipient network (Arbitrum) is getting lowered.
-
Given that there is no sequentiality assurance on what action happen first, let’s assume the DAO “mandate” to lower the bucket size on Arbitrum arrives first, and gets executed.
-
CCIP has picked the 500 GHO bridge request from the user (tokens have been burnt on sender side) and should mint on Arbitrum 500 GHO. However, bucket size on Arbitrum at the moment is filled; there is no further capacity.
-
The problem (without the mitigation applied by Aave Labs that we explain afterwards) is that, from our understanding, CCIP has no mechanism to “rollback” the bridging from Optimism → Arbitrum. Meaning that most probably the correct behaviour would be: the user burns his tokens on Optimism → CCIP listens that “request” → CCIP understand that bucket capacity is full on Arbitrum → CCIP manages somehow the minting back of 500 GHO on Optimism, as Arbitrum is not an option.
But without rollback management, that means the funds of the user trying to bridge could end temporarily locked, until retrying directly on CCIP (if the bucket size was raised), or worst case scenario, until the Aave DAO/CCIP manages the situation ad-hoc.
Roll-back management in systems like this is extremely important, and cases like the previous could be even more complex. For example, it could be the case that both Arbitrum and Optimism bucket sizes got reduced at the same time, but just before the user burnt tokens to bridge.
In that case, the 500 GHO “claim” would be in some type of limbo situation, as 1) Arbitrum can’t mint them and 2) Optimism can’t mint them back either.
This could be solvable for example by having Ethereum as last-resort fallback, given that by design there is always GHO backing there.
Trying to solve this problem, Aave Labs introduced the concept of a Bridge limit in Ethereum. Bridge Limit is a constraint applied on Ethereum whenever trying to bridge GHO to another network, which enforces amount to bridge + current total bridged amount <= bridge limit .
The objective is to have a way on Ethereum to control that the previous case of user funds getting locked simply can’t happen, and this is effectively achieved by introducing an strict procedure to always be respected: whenever the minimum bucket size on any network with cross-chain GHO is raised, the bridge limit should be raised to that value.
Even if this works works, it creates what we think it is a major consequence on the system:
- Let’s assume cross-chain GHO Arbitrum starts with an hypothetical capacity of 1’000’000 GHO. That means that bridge limit needs to be configured to 1’000’000.
- Progressively, the Aave DAO or some type of steward contract decides to increase it in multiple steps up to let’s say 20’000’000. Again, that means that bridge limit needs to be increased to 20’000’000 too.
- Now, let’s assume that a new expansion of cross-chain GHO is decided to any other network, like Avalanche. Ideally, the approach would be to follow the approach of Arbitrum, and start with a relatively small bucket size, like 1 or 2 million GHO.
However, the limitation of the bridge limit is there:amount to bridge + current total bridged amount <= bridge limit. With current 20’000’000 bridge limit configured, and as bridge limit can’t be reduced to not create lock-up problems, it means that only a 20’000’000 bucket size capacity can be configured initially to any new network.
If we imagine GHO working at scale, with some networks having bucket sizes of maybe 100 million, it is not really acceptable to be limited to only start on any new network with minimum of 100 million bucket size.
This is a complicated problem and we agree that the bridge limit solution proposed by Aave Labs at least solves the lock-up scenario for users, however the side effect operational-wise to the DAO is quite major.
Our recommendations are the following:
- CCIP must have a roll-back mechanism. We don’t think it is an optional feature, we think it is mandatory on any system dealing with assets.
- Not expand to any extra non-Ethereum network apart from Arbitrum until this is solved.
- Most probably, remove the bridge limit constraint. Important to point that if not expanding to further networks, its presence will not “hurt” the DAO, only requiring to update the bridge limit just after the bucket capacity on Arbitrum is increased. From our discussions with them, Aave Labs is keeping that into account, but in our opinion, the back-and-forth behaviour required probably is not worth it to implement.
Another option to study is to directly disabled non-Ethereum to non-Ethereum communication, which factually would remove any need to bridge limit and will make rollback management simpler (always rolling back to Ethereum).
GHO as non-payment currency for bridging
From the UX point of view, we believe that GHO should have been enabled as payment currency for bridging on day 0, for the following reasons:
- GHO on Ethereum was appropriately implemented by Aave Labs with support for meta-transactions (
permit()), envisioning use-cases of GHO as payment currency. - CCIP seems to support already both native and ERC20 payment methods.
- It simply feels very strange that with cross-chain GHO having the goal of being an innovative cross-chain stablecoin, users can’t use the same stable-coin to pay for bridging costs.
This is purely a limitation of CCIP, not of the implementation of cross-chain GHO by Aave Labs.
Emergency procedures
For our understanding, the cross-chain GHO layer doesn’t provide any emergency mechanism similar to EMERGENCY_ADMIN-controlled actions in for example the Aave pools, apart from rate limiting on CCIP (not enabled initially) and probably some others internal to CCIP.
No matter the entity in control of those, we strongly recommend to have some type of emergency mechanism active at least during the release phase, and document the procedure on how to exercise it, both if on the cross-chain GHO contracts themselves, or in CCIP.
Additionally, some type of usage of Chainlink Proof-of-Reserve could be valuable security-wise to the system.
Activation proposal for cross-chain GHO
Same as with any other Aave governance proposal, we will review the activation payload for cross-chain GHO and Certora will do the same once on-chain.
Before that, we only recommend to map as much as possible permissions configuration, constraints (e.g. bucket size) and ordering of activation actions, given the multiple layers involved.
We will be adding coverage to cross-chain GHO on https://github.com/bgd-labs/aave-permissions-book, for total visibility of the community on the system.
Conclusion
In summary, from our analysis:
- The basic lock/release/mint/burn architecture by Aave Labs is sound, and aligned with other Aave DAO projects.
- GHO upgradeable in non-Ethereum networks is a good decision. Same applies for token pools on all networks.
- A proper rollback management mechanism must be implemented by the bridge provider (CCIP). Highly recommended to not expand to any other network apart from Arbitrum until then, or not enable non-Ethereum to non-Ethereum communication. Potentially deprecate the bridge limit mechanism.
- Not a blocker from our perspective, but GHO should have been prioritised as payment currency for bridging.
- Add or/and document the emergency mechanism/procedures of cross-chain GHO.
None of the previous items are technical/security blockers on the current status, but not addressing them could create some technical debt for future upgrades. We really think that any further expansion apart from Arbitrum should only be done after the rollback problematic is addressed.