GHO Stability Module
01Summary
Deploy the GHO Stability Module (GSM) with two contracts enabling conversions between GHO and USDC/USDT at 1:1 ratio with 0.2% fees, exposure caps of 500,000 each, automated swap freezing via Chainlink keepers, and DAO-controlled last resort liquidation to maintain GHO peg stability.
- Type
- protocol addition
- Funding
- $160
Key changes
- Deploy GSM USDC contract facilitating GHO-to-USDC conversions at 1:1 ratio with 0.2% buy/sell fees and 500,000 USDC exposure cap(high)
- Deploy GSM USDT contract facilitating GHO-to-USDT conversions at 1:1 ratio with 0.2% buy/sell fees and 500,000 USDT exposure cap(high)
- Establish price-based swap freezing mechanism via Chainlink keeper that freezes swaps when USDC/USDT prices fall outside [0.99-1.01] range and unfreezes within [0.995-1.005] range(high)
- Grant Aave DAO exclusive last-resort liquidation authority over GSM funds during worst-case scenarios(high)
- Enable ERC4626 asset support for yield generation to GHO Treasury(medium)
- Register both GSM contracts in GSM Registry and fund OracleSwapFreezer keepers with 80 LINK each via AaveRobot(medium)
Notable concerns
- Exposure caps of 500,000 USDC and 500,000 USDT may limit GSM capacity during high demand periods
- Swap freeze mechanism relies on external Chainlink oracle price feeds and keeper automation which introduces operational dependencies
- Fixed 1:1 pricing with 0.2% fees may not account for market volatility in extreme scenarios
Generated by Kvorum
02Description
Simple Summary
This AIP proposes the deployment of the GHO Stability Module (GSM), a system facilitating the conversion between GHO and two governance-accepted stablecoins, USDC and USDT, at a predetermined ratio.
The GSM has undergone thorough iterations of design, development, testing, and implementation with Aave Labs driving this process and actively seeking community feedback. Additionally, the security aspect was carefully addressed through collaboration with DAO service providers SigmaPrime and Certora for code reviews. Furthermore, an extra layer of security was added by commissioning an independent review from a security researcher (Emanuele Ricci @stermi).
Following extensive community discussion and multiple phases of Aave DAO governance, this AIP suggests deploying two GSM contracts for seamless conversions between GHO and USDC as well as GHO and USDT.
Motivation
The GHO Stability Module (GSM) is a contract designed to facilitate conversions between two tokens with its primary purpose being to help further maintain GHO's peg. The module allows swaps between GHO and other governance-accepted stablecoins, offering a variety of functionalities that make it paramount in the fields of security and risk management.
Summarizing the functionality offered by the GHO Stability Module (GSM), here is a list of these features and their planned implementation for this proposal:
- Exposure Cap: Denominated in token units, it limits exposure to the exogenous asset.
- Price Strategies: Utilizing a fixed price strategy with a 1:1 ratio for stablecoins.
- Fee Strategies: Employing a flat basis point (bps) approach, differentiated by direction (sell/buy).
- Last Resort Liquidation: Aave DAO is the exclusive entity granted with the role of last resort liquidation, empowering it to take control of GSM funds in worst-case scenarios.
- Swap Freeze: Aave DAO and a chainlink-automated keeper contract have the authority to freeze the swap functionality. The chainlink-automated keeper contract bases its actions on the price of the exogenous asset, freezing if the price is outside the range and unfreezing if inside the range.
- Capital Allocation: Supporting this feature by allowing ERC4626 assets as underlying assets. This enables redirecting the yield generated by the ERC4626 asset, while residing in the GSM contract, to the GHO Treasury.
Specification
The proposed payload entails the comprehensive activation of GSM USDC and GSM USDT, involving the following steps:
- Incorporate GSM USDC and GSM USDT as facilitators of the GHO Token on Ethereum.
- Adjust the Fee Strategy for both GSMs to implement a 0.2% flat fee for both directions (buy/sell).
- Add both GSMs to the GSM Registry.
- Designate OracleSwapFreezer contracts and Aave DAO as SwapFreezer entities in each GSM contract, respectively.
- Activate these OracleSwapFreezer contracts as keepers of the Aave DAO through AaveRobot with a funding of 80 LINK for each.
The table below outlines the initially proposed risk parameters for each GSM contract, as approved through the snapshot:
GSM USDC
| Parameter | Value |
|---|---|
| Underlying Price Range for Swap Freeze | [0.99 - 1.01] |
| Underlying Price Range for Swap Unfreeze | [0.995 - 1.005] |
| Buy Fee | 0.2% |
| Sell Fee | 0.2% |
| Exposure Cap | 500,000 USDC |
| Facilitator Bucket Capacity | 500,000 GHO |
| Swap Active | True |
GSM USDT
| Parameter | Value |
|---|---|
| Underlying Price Range for Swap Freeze | [0.99 - 1.01] |
| Underlying Price Range for Swap Unfreeze | [0.995 - 1.005] |
| Buy Fee | 0.2% |
| Sell Fee | 0.2% |
| Exposure Cap | 500,000 USDT |
| Facilitator Bucket Capacity | 500,000 GHO |
| Swap Active | True |
References
- Implementation: Gho
- Tests: Gho
- Snapshot
- Discussion
- GSM Repository
- GSM Audit Reports
Copyright
Copyright and related rights waived via CC0.
03Mismatch analysis
The decoded calldata consists of exactly one action: a bare execute() call to a payload contract address, with no decoded internal arguments or sub-calls. This is the standard Aave governance pattern where a dedicated payload contract (referenced in the proposal's 'Implementation' link) is deployed to bundle multiple internal actions (adding GSM facilitators, setting fee strategies, registry additions, freezer role assignments, and keeper activation with LINK funding). Because the calldata does not expose the internal logic of this payload contract (no decoded sub-action list, parameter values, or target addresses beyond the payload contract itself), it is not possible to directly verify whether the specific numeric parameters (0.2% fees, 500,000 exposure caps, 80 LINK funding, price ranges) described in the prose match what execute() will actually do on-chand. Nothing in the visible calldata contradicts the description, and a single execute() call is entirely consistent with the described multi-step specification being implemented in an off-chain-reviewed, audited payload contract. Given the lack of granular visibility into the payload's internal actions, confidence in this comparison is low rather than a specific finding of consistency or discrepancy. No values, targets, or omissions could be confirmed as mismatched.}],
Generated by Kvorum
04Actions
- Target
- 0x81e6…17ea
- Value
- 0 wei
- Function
- fallback()
- Arguments
{}- Calldata
05Tally
Summed from votes
06Voters
No votes recorded yet.
07Forum
No forum thread is confidently linked to this proposal.