Intro
GHO Flashloans on Polygon can follow the original idea of minting and burning GHO tokens directly from the GHO ERC20 L2 Smart Contract, without bridging. The only way this can be done is by providing the correct limitations set by the Aave Governance. This is where zk-storage proofs help us to forward and prove voted values from Ethereum to Polygon.
Before Reading
Please note that this is not the full working project, just an idea that has been built during the hackathon on the testnet.
- GHO is an ERC20-like stablecoin with a supply limited by the decision of Aave Governance.
- A Facilitator is the entity that executes the minting or burning of GHO Tokens.
- A Flashminter is the only Facilitator that provides flash loans on the Ethereum network.
- Noir is a Domain Specific Language (DSL) designed for SNARK proving systems.
Problem
Here, we are talking about the GHO stablecoin token, which has to follow market conditions and needs to be as flexible as possible, without any bridging, wrapping restrictions, or locks. Sometimes, this seems like the only possible solution, but it is very inefficient, especially if we want to enable original GHO flash loaning on L2.
In the case of wrapped tokens, we must provide liquidity that may not meet market demands.
Additionally, we need to manage the distribution of rewards to the Aave Treasury after a flash loan occurs. This management must be handled across every protocol where GHO is available.
Solution
The most elegant way to solve these problems is to create a global supervisor that:
- Tracks relevant data changes in AAVE Governance
- Combines the supply of GHO across every protocol into a single value
- Uses zk-storage proofs of the Governance SC and GHO SC for cross-chain trustless data forwarding
In such a case, the GHO stablecoin can function and serve as it should, without any bridges or wrappers. Governance will work as before, and flash loans will become available in every rollup in their original form.
Bonus!
If we have global, trustless control over GHO supply, we can forward rewards for flash loans by burning them on L2 and minting the same value on L1 directly for the AAVE Treasury.
Architecture
The major role in this system is highlighted for the Relayer; it is an all-in-one instance that makes everything work.
Actually, it can be motivated by its service from the bridging rewards value, which upgrades the system to a distributed level. In such a case, it will transform into the ZkOracle.
To ensure everything works, we need to add one more Smart Contract on the L2 side that has the rights to update the L2 GHO ERC20 Smart Contract limits and add a mintForTreasure() function to the L1 GHO ERC20 Smart Contract, which can accept zk-storage proof of burned GHO Tokens on the L2 side.
Hackathon Results
During the hackathon, Maxim wrote and launched:
- An updated GHO ERC20 for L2,
- A Relayer that tracks changes on L1,
- Circuits in Noir that generate zk-storage proofs,
- A Verifier that validates zk proofs.
All the source code can be found here: https://github.com/Resolfinity/lfgho-hackaton
We haven’t launched the Flashminter Facilitator to mint flash loans yet, as it is the simplest but most time-consuming part.
We’ve been selected as Round 1 finalists, and we’re very happy to have discovered another ZK use-case and to have built a Proof of Concept for it.
Idea Evolution
It’s a very good and amusing idea to build one zk-storage proof based on the Governance decision and spread it across multiple chains. The benefits here are:
- Time-effective: Governance votes once, as it likes to do.
- Cost-efficient: only one proof is needed for every rollup/blockchain.
- Trustless: the relayer can maintain reliability due to the simplicity of the system.
And if we follow the GHO context, we truly believe that AAVE can distribute the GHO token much more efficiently with a solution similar to the one we’ve made.
Thank you for reading!