[ARFC]. BGD. GhoDirectMinter

[bgdlabs]

Simple summary

Introduce to the community a simple GhoDirectMinter facilitator smart contract to adopt if required for different initiatives appearing in this forum during the last months.

The codebase can be found (temporarily until gov approval) on:
https://github.com/bgd-labs/GhoDirectMinter

Motivation

Recently, various proposals/discussions have targeted GHO, including listings via minting (partially or total) like on v3 Lido HERE or minting + bridging via cross-chain GHO like HERE.

After following those posts here on the forum, we perceived the need for some type of unification and simplification of the infrastructure required for the DAO to operate efficiently, more specifically on the minting + supply to Aave side of a GHO facilitator, and base architecture.

The motivation of this post is to propose a GHO mint + supply to Aave facilitator smart contract to move on operational requirements of the DAO as soon as possible, with simplicity as a design principle.

This post deviates from the GHO Facilitator Onboarding Process and Application, as this is just a proposal for the infrastructure of contracts to use, not the activation of a specific instance.

Specifications

While the aforementioned proposals differ in the suggested parameters, what they have in common is the goal of allowing the DAO to directly mint to the pool, while at the same time allowing other entities to supply GHO as well.

This approach is fundamentally different from the existing GHO integration on the Ethereum Main instance, given that in the original implementation, there is no AToken, no index accrual, and all fees go to the treasury.

To satisfy these different goals, we developed a new GHODirectMinter facilitator smart contract.

High level design of the GhoDirectMinter

The development of the GhoDirectMinter was done with these principles:

• Following the facilitator ethos. The facilitators architecture proposed by Aave Labs on the GHO release had as its main objective modularity, for multiple use cases both on Ethereum or any other chain. Facilitators should not be monolithic, but compact and use-case specific, fast to move forward.
• Simplicity. The goal of the development was to fulfill the current needs of the DAO while having a contract very simple to audit. No extra overhead to adapt to hypothetical use cases, that can be accommodated as they appear, via upgrade or deployment of new facilitators.

In terms of logic, and access control, the GHODirectMinter works the following way:

• Upgradeable contract by Aave governance.
• 3 access control roles, with an example configuration taking as reference minting GHO on v3 Lido:
  • upgradeability admin (proxy admin): Aave DAO, but via its ProxyAdmin contract.
  • owner: Aave DAO, via the Level 1 Executor.
  • guardian: GHO council, sometimes known as GHO steward in the forum.
• 3 external functions:
  • mintAndSupply().
    • Mints GHO and supplies it into the target Aave Pool.
    • To be used by the guardian to choose when liquidity gets minted and supplied, and how much.
    • It ignores and supply cap on the Aave pool, this way giving “priority” to the DAO supplying liquidity versus others.
  • withdrawAndBurn().
    • Withdraws GHO from the target Aave Pool and burns it.
    • To be used by the guardian to choose when liquidity gets withdrawn and burnt, and how much.
  • transferExcessToTreasury().
    • Transfers to the configured Aave DAO treasury (e.g. Collector Ethereum) any excess of GHO aToken, majorly the yield accrued from supplying into the pool.
    • Permissionless, oriented to be automated.

---

Regarding a potential flow of setup & operation for a hypothetical GhoDirectMinter facilitator for GHO on v3 Lido (via governance proposal):

1. Deploy proxy contract + implementation of the GhoDirectMinter.
2. Grant RISK_ADMIN role to the GhoDirectMinter proxy, in order to skip supply caps on mintAndSupply().
3. Call addFacilitator() on GHO with the desired capacity for the facilitator.
4. Optionally, already do an initial minting in the target pool via governance proposal.
5. Once the system is active post-governance, the configured guardian entity can operate up to the capacity configured, by minting+supply and withdraw+burn.
6. Periodically, transferExcessToTreasury() can be triggered via an Aave Robot automation or Dolce Vita to send the accrued aGHO yield to the Collector. This is however not so critical, as the yield will simply keep accruing in the GhoDirectMinter, where is perfectly safe and optimal.

---

Props to the other contributors who helped us understand the potential use cases and DAO operational needs, especially @TokenLogic @ACI; and all other participants in the GHO discussion and contributions in this forum.

Next steps

• After 3 days of discussion in this forum, create an ARFC Snapshot for the community to pre-approve the facilitator contract.
• If/when the ARFC Snapshot passes, coordinate for review of the facilitator contract by Certora.
• In parallel with security procedures, sync with other service providers to create the proposal for the activation of 1 or n facilitators needed, using the GhoDirectMinter. Following the GHO Facilitator Onboarding Process and Application.
• Also in parallel with security procedures, we will coordinate with other contributors on the facilitator smart contracts (e.g. @AaveLabs) for the best location to place the code of the facilitator.

[AaveLabs]

Aave Labs recognizes the value of this proposal by @bgdlabs and supports the architecture presented for the GHO DirectMinter facilitator.

This approach aligns with core design principles that prioritize simplicity, flexibility, and efficient operational management. This design supports the protocol’s evolution by enabling independent updates and additions of new facilitators without impacting existing components.

Aave Labs will offer technical support for this initiative and stands ready to provide assistance throughout the governance process to facilitate the successful implementation.

[LlamaRisk]

Summary

LlamaRisk supports the creation of a GhoDirectMinter facilitator smart contract and believes that it will serve as an efficient tool to directly mint and deploy GHO on Aave’s lending pools in different markets where GHO is deployed as a supply-and-borrow asset.

The minting amounts would be agreed upon via the governance in dedicated ARFCs. This Facilitator would then deploy the pre-agreed amount of GHO fully or in parts, as deemed fit by the GHO Stewards. This process would enable controlled GHO deployment while achieving desired market outcomes.

Minting GHO Directly to Aave’s Lending Pools

While this newly created Facilitator would mint unbacked GHO, the stablecoin would only reach the open market when borrowed using provided collateral. Therefore, the stablecoin would become liquid only if backed by collateral at an over-collateralized ratio. This process is de facto equal to the usual on-demand mint of GHO as executed on the Ethereum market.

Flexibility for GHO Stewards

This facilitator structure would enable GHO Stewards to deploy pre-agreed amounts of GHO with full flexibility:

1. Fully or in parts, using the mintAndSupply() function;
2. Only when market conditions are suitable for it, contrary to minting and deploying as soon as the corresponding AIP is executed;
3. Timed to achieve needed market effects, e.g., respond to a sharp increase in borrow interest.

In addition, GHO Stewards could also use withdrawAndBurn() if such a need is presented. All of that would ensure a risk-balanced strategy to be applied with the consensus of GHO Stewards.

Bucket Capacity Limit

Although GHO Stewards would have full flexibility in deploying the capital, the amount of GHO to be deployed would still be pre-determined through dedicated ARFCs before activating a corresponding GhoDirectMinter. This ensures complete transparency and discloses the rationale behind any proposed GHO minting.

Disclaimer

This review was independently prepared by LlamaRisk, a community-led non-profit decentralized organization funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work.

The information provided should not be construed as legal, financial, tax, or professional advice.

[ChaosLabs]

Overview

Chaos Labs strongly supports the creation and use of the GhoDirectMinter facilitator module, which represents a significant step toward improving GHO’s adaptability, efficiency, and growth within Aave.

Motivation

As previously detailed in this ARFC, recent history demonstrates the difficulty of attracting meaningful GHO deposits in new instances and chains without offering substantial incentives. On Arbitrum, for example, GHO remained underutilized until liquidity rewards were introduced. A direct minting facilitator allows the DAO to bypass the initial friction of limited liquidity, depositing GHO directly into pools without costly external campaigns.

Directly supplying minted GHO into the target instance ensures the asset never enters circulation unless backed by approved collateral. Furthermore, this approach reduces the need to bridge liquidity back and forth with Ethereum, thus enhancing operational efficiency. GhoDirectMinter ensures that liquidity stays localized, cutting down on cross-chain transfers and, in this way, providing relief to the GHO Bridge Limits.

Furthermore, it enables more granularity in controlling how much GHO is minted per chain or instance deployment, tailoring exposure to the relevant assets and, as such, also reducing risk.

GHO Steward

Thanks to this new facilitator framework, the GHO Steward gains the ability to quickly react to market changes in order to provide or remove liquidity from a GHO market. This approach allows GHO Stewards to strategically time GHO deployment, for example, to counteract sudden increases in borrowing costs.

While the GHO Facilitator can mint and burn GHO without going through the AIP governance process, the maximum amount of supply mintable by each facilitator is still determined by governance at the time of creation and can be adjusted in the future through the governance process.

Supply Caps

The mintAndSupply function in the GhoDirectMinter smart contract bypasses the standard supply cap mechanism of the pool. It achieves this by temporarily removing the supply cap, allowing GHO to be minted and deposited directly into the pool. Once the deposit is complete, the supply cap is reinstated to its original value.

This introduces the following effect: if the reinstated supply cap is lower than the new total supply (previously present supply plus the GHO minted and deposited through mintAndSupply), normal user deposits into the pool will become impossible. This restriction remains in place until sufficient withdrawals reduce the total supply below the supply cap.

  // @inheritdoc IGHODirectMinter
  function mintAndSupply(uint256 amount) external onlyOwnerOrGuardian {
    IGhoToken(GHO).mint(address(this), amount);
    IERC20(GHO).forceApprove(address(POOL), amount);
    DataTypes.ReserveConfigurationMap memory configuration = POOL.getConfiguration(GHO);
    // setting supplycap to zero to disable it
    POOL_CONFIGURATOR.setSupplyCap(GHO, 0);
    POOL.supply(GHO, amount, address(this), 0);
    // setting supplycap back the original value
    POOL_CONFIGURATOR.setSupplyCap(GHO, configuration.getSupplyCap());
  }

Disclaimer

Chaos Labs has not been compensated by any third party for publishing this recommendation.

Copyright

Copyright and related rights waived via CC0