Add GHO on Aave Plasma and deploy GSM on Plasma.
01Summary
Launch GHO stablecoin on Plasma network with RemoteGSM, bridge 50M GHO from Ethereum, configure risk parameters and multiple eModes to support GHO supply/demand through incentive strategies, GSM mechanisms, and collaborative programs with Plasma, Maple Finance, and Ethena.
- Type
- protocol addition
- Funding
- $50000000
Key changes
- Enable GHO as borrowable asset on Aave Plasma with 50M supply cap and 20M borrow cap(high)
- Deploy RemoteGSM on Plasma with stataUSDT collateral, 50M GHO cap, and initial 10M exposure cap(high)
- Create GhoDirectFacilitator on Ethereum with 50M mint cap and issue initial 50M GHO for bridging(high)
- Bridge 50M GHO from Mainnet to Plasma via AaveGhoCcipBridge(high)
- Configure 5 new eModes including syrupUSDT+GHO, GHO+USDT0, PT-USDe+GHO, and PT-sUSDe+GHO combinations(high)
- Set GHO borrow rate 150bps lower than USDT at optimal utilization to incentivize borrowing(medium)
- Enable GHO incentives (~3.50%) for users supplying syrupUSDT+GHO with leverage loops(medium)
- Configure RemoteGSM parameters including 0% mint fee, 0.10% burn fee, and peg stability bounds ($0.990-$1.010)(medium)
Notable concerns
- Proposal executes in two sequential parts with Part 2 dependent on Part 1 completion
- Initial RemoteGSM exposure cap set at 10M (vs 45M planned) to prevent arbitrage until pegs stabilize
- GHO leverage strategies with health factor <2.0 requirement creates liquidation risk for participants
- Multiple complex eModes and incentive mechanisms require ongoing risk management
- Reliance on secondary market demand from Fluid and Balancer to reduce dependency on supply-side incentives
Generated by Kvorum
02Description
Simple Summary
With the GHO lanes now activated on CCIP, this publication defines the launch parameters for GHO on Plasma, as well as the introduction of GSMs on Plasma.
Motivation
This publication presents the revised GHO parameter configuration for deploying the RemoteGSM and listing GHO on Aave Protocol. A joint collaboration program with Plasma, Maple Finance and Ethena, will be launched on Aave Protocol whilst separate and complimentary rewards programs will commence on Fluid and Balancer.
GHO Supply
Within the new syrupUSDT and GHO collateral eMode, users who:
- Supply syrupUSDT and GHO (50% syrupUSDT:50% GHO), with a cap of 50% for GHO eligible for rewards (if additional GHO is supplied, it won't be rewarded)
- Borrow USDT and complete at least one leverage loop
- Maintain a health factor of less than 2.0
Will receive GHO incentives (~3.50%) such that the Total Supply yield (Native + Incentives) exceeds the native syrupUSDT yield by approximately 50bps.
The above incentive strategies create GHO Supply on Aave Protocol. Sourcing the GHO is expected to at least partially flow through the remote GSM, which deposits USDT0 into Aave whereby the DAO earns the Supply yield.
GHO Demand
With strong GHO supply expected from the GHO incentives, GHO demand is created via the revision of eMode 2 to include GHO as a debt asset. eMode 2 is to offer sUSDe and USDe as collateral with USDT and GHO as debt, the GHO debt will receive a x5 Sats multiplier from the Ethena team that matches what is currently available on the Ethereum Core and Prime instances.
This is expected to stimulate Demand for GHO on Aave Protocol with GHO expected to be a lower cost alternative to USDT0 due to the Borrow Rate configuration (150bps less than USDT at Uoptimal) and additional Sat incentives acting to offset the cost of capital for leverage users.
Furthermore, additional eModes with Pendle PT assets are expected to provide sustained demand for GHO that reduces the reliance on GHO Incentive yield to attract GHO supply.
Fluid and Balancer
With support from the Aave Liquidity Committee (ALC) concentrated liquidity facilitating swaps will be incentivised on Fluid and Balancer in collaboration with each respective team and the Plasma team. Importantly, this stimulates demand for GHO on secondary markets outside of Aave Protocol and is expected to provide a net counter flow where users are expected to be net acquiring GHO.
Specification
This proposal has two parts that need to be executed in sequence. Part 1 will execute first, and then Part 2 can be executed. Part 2 will always revert until Part 1 is executed as it's dependant on it.
The table below illustrates the configured risk parameters for GHO
| Parameter | Value |
|---|---|
| Isolation Mode | false |
| Borrowable | ENABLED |
| Collateral Enabled | false |
| Supply Cap (GHO) | 50,000,000 |
| Borrow Cap (GHO) | 20,000,000 |
| Debt Ceiling | USD 0 |
| LTV | 0 % |
| LT | 0 % |
| Liquidation Bonus | 0 % |
| Liquidation Protocol Fee | 10 % |
| Reserve Factor | 5 % |
| Base Variable Borrow Rate | 1.25 % |
| Variable Slope 1 | 3.5 % |
| Variable Slope 2 | 16.5 % |
| Uoptimal | 92 % |
| Flashloanable | ENABLED |
| Siloed Borrowing | DISABLED |
| Borrowable in Isolation | DISABLED |
| Oracle | 0xb0e1c7830aA781362f79225559Aa068E6bDaF1d1 |
Additionally 0xac140648435d03f784879cd789130F22Ef588Fcd has been set as the emission admin for GHO and the corresponding aToken and vToken.
EModes
eMode Category 2
| Parameter | sUSDe | USDe | USDT0 | GHO |
|---|---|---|---|---|
| Collateral | Yes | Yes | No | No |
| Borrowable | No | No | Yes | Yes |
| Max LTV | 90% | 90% | - | - |
| Liquidation Threshold | 92% | 92% | - | - |
| Liquidation Bonus | 4.0% | 4.0% | - | - |
eMode Category - Category 13
| Parameter | PT-USDe April | USDT0 | USDe | GHO |
|---|---|---|---|---|
| Collateral | Yes | No | No | No |
| Borrowable | No | Yes | Yes | Yes |
| Max LTV | Keep Current | - | - | - |
| Liquidation Threshold | Keep Current | - | - | - |
| Liquidation Bonus | Keep Current | - | - | - |
eMode Category - Category 15
| Parameter | PT-sUSDe April | USDT0 | USDe | GHO |
|---|---|---|---|---|
| Collateral | Yes | No | No | No |
| Borrowable | No | Yes | Yes | Yes |
| Max LTV | Keep Current | - | - | - |
| Liquidation Threshold | Keep Current | - | - | - |
| Liquidation Bonus | Keep Current | - | - | - |
eMode Category (new)
| Parameter | GHO | USDT0 |
|---|---|---|
| Collateral | Yes | No |
| Borrowable | No | Yes |
| Max LTV | 94% | - |
| Liquidation Threshold | 96% | - |
| Liquidation Bonus | 2.0% | - |
eMode Category (new)
| Parameter | syrupUSDT | GHO |
|---|---|---|
| Collateral | Yes | No |
| Borrowable | No | Yes |
| Max LTV | 90% | - |
| Liquidation Threshold | 92% | - |
| Liquidation Bonus | 4.0% | - |
eMode Category (new)
| Parameter | syrupUSDT | GHO | USDT0 |
|---|---|---|---|
| Collateral | Yes | Yes | No |
| Borrowable | No | No | Yes |
| Max LTV | 90% | 90% | - |
| Liquidation Threshold | 92% | 92% | - |
| Liquidation Bonus | 4.0% | 4.0% | - |
Facilitator & Bridging
Add a GhoDirectFacilitator on Ethereum to enable GHO issuance for Plasma.
- Mint Cap: 50M GHO
- Initial Mint: 50M GHO
As required, future Minting of GHO on Ethereum, to be supplied into the RemoteGSM on Plasma (or other networks) will be performed via direct submission of AIPs.
GhoReserve
Deploy GhoReserve on Plasma to hold bridged GHO. Configure stataUSDT RemoteGSM as an entity with a draw capacity of 50M GHO.
RemoteGSM Parameters (stataUSDT)
| Parameter | Value |
|---|---|
| GHO Cap | 50M |
| stataUSDT Exposure Cap | 10M |
| Freeze Lower Bound | $0.990 |
| Freeze Upper Bound | $1.010 |
| Unfreeze Lower Bound | $0.995 |
| Unfreeze Upper Bound | $1.005 |
| Mint GHO Fee | 0.00% |
| Burn GHO Fee | 0.10% |
In order to not allow arbitrageurs to move GHO immediately from Plasma to Mainnet, the exposure cap will initially be 10M and as Gho and USDT pegs stabilize, the risk council will gradually bring the exposure cap to 45M as originally planned.
The RiskCouncil will be set as a LIMIT_MANAGER on the GhoReserve to be able to update limits of the GSM.
GHO Steward Configuration
GhoAaveSteward
updateGhoBorrowCap: ±100%updateGhoBorrowRate: ±5% on optimal usage ratio, base variable rates, slopesupdateGhoSupplyCap: Up to +100%
GhoGsmSteward
updateGsmExposureCap: ±100%updateGsmBuySellFees: ±0.5% per side (FixedFeeStrategy)
Bridging
Bridge 50M GHO from Mainnet to Plasma utilizing the newly set up AaveGhoCcipBridge.
References
- Implementation: AaveV3Ethereum_Part 1,AaveV3Ethereum_Part 2, AaveV3Plasma_Part 1, AaveV3Plasma_Part 2
- Tests: AaveV3Ethereum_Part 1, AaveV3Ethereum_Part 2, AaveV3Plasma_Part 1, AaveV3Plasma_Part 2
- Snapshot
- Discussion
- Audit
Copyright
Copyright and related rights waived via CC0.
03Mismatch analysis
The decoded on-chain actions provided are only two generic execute() fallback calls to payload contracts on Ethereum mainnet, consistent with Aave's standard pattern of a governance executor delegatecalling into a purpose-built payload contract that internally performs the many granular steps (risk parameter updates, eMode configuration, facilitator and GSM deployment, steward config, bridging). Because the calldata trace does not expose the internal function calls and arguments executed by these payload contracts, it is not possible to directly verify each specific numeric claim in the description (e.g., 50M mint cap, borrow cap of 20M, LTV/LT values, eMode percentages, bridging amount) against decoded arguments. No contradiction is evident from what is available - the two execute() calls align with the proposal's stated two-part sequential execution structure (Part 1 then Part 2, with Part 2 dependent on Part 1). Given the opacity of the calldata at this level, confidence in a full line-by-line reconciliation is low, and no specific mismatches can be substantiated. Since nothing in the visible calldata contradicts the description and the execution pattern matches the described two-part structure, the assessment defaults to consistent, but with low confidence due to insufficient decoded detail to verify the granular parameter claims made in the proposal text.
Generated by Kvorum
04Actions
- Target
- 0x25fe…205d
- Value
- 0 wei
- Function
- fallback()
- Arguments
{}- Calldata
- Target
- 0xe945…0cf1
- 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.