Aera Extension
01Summary
Extend Compound's treasury management through Aera by deploying 2,000 ETH from the treasury, 15M DAI and 10M USDC from V2 reserves into Compound V3 lending markets to generate yield. Expected to add ~$30M TVL and generate $1M+ in additional annual treasury revenue.
- Type
- treasury allocation
Key changes
- Add DAI and cWETHv3 Pricer as new assets to the Aera vault(high)
- Deploy 2,000 ETH from Compound Treasury into Aera vault for yield generation(high)
- Deploy 15M DAI from Compound V2 reserves into Aera vault(high)
- Deploy 10M USDC from Compound V2 reserves into Aera vault(high)
- Update vault objective function from targeted volatility to yield generation for stablecoin reserves(high)
- Accept ownership of new hooks module to support cWETHv3 supply/withdraw and DAI approve functions(medium)
- Wrap 2,000 ETH into WETH for vault deployment(medium)
Notable concerns
- Proposal requires acceptance of new hooks module workaround due to Governor Bravo 10-action limit constraint
- Stablecoin reserves being deployed into lending markets introduces counterparty risk from Compound V3 borrowers
Generated by Kvorum
02Description
Aera Extension
Simple Summary
For over a year, the Compound DAO has used Aera for treasury management. This proposal builds upon prior work to further operationalize the DAO's treasury.
There is currently an excess of USDC and DAI reserves in Compound V2, which could be deployed in lending markets to generate yield for the treasury. Additionally, a portion of the ETH in the Compound Treasury can be utilized to generate yield.
This continuation of the existing programs will enable the DAO to drive a new yield source. The expected impact of this proposal is $30M~ in additional Compound V3 TVL and $1M+ in additional treasury revenue via yield generation.
Deployment details:
- Compound Treasury
- 2,000 ETH
- Compound V2 Reserve Assets
- 15M DAI
- 10M USDC
- The vault’s objective function will be updated from targeted volatility to yield generation. This ensures the stablecoin reserves do not get allocated to volatile assets.
- The vault will continue to allocate into Compound V3 lending markets to generate yield on the underlying assets.
For more details, please refer to the Forum Post.
Specification
This proposal will:
- Add new assets to the vault: a. DAI b. cWETHv3 Pricer, which prices the vault's WETH lending position
- Accept ownership of a new hooks module at address
0x8A216F2C84a3fE5a51Bf57B685864A065D14C53a. We need to deploy a new hooks module and have the Governor Bravo timelock accept ownership of it to get around a limitation in Governor Bravo that only 10 actions can be called in a single proposal. Without this workaround, adding the following function sighashes would put this proposal over that limit. This new hooks module already has all the existing hooks, plus the following new sighashes: a. cWETHv3supply&withdrawb. DAIapprove, needed to trade it for USDC - Wrap a portion of the ETH currently in the timelock into WETH
- _reduceReserves on both DAI and USDC V2 reserves
- Approve WETH, DAI, and USDC to be deposited into the Aera vault
- Deposit the assets into the Aera vault
03Mismatch analysis
I compared each numbered specification item and deployment detail against the ten decoded actions. Token amounts convert cleanly: 15,000,000 DAI = 1.5e25 (18 decimals), 10,000,000 USDC = 1e13 (6 decimals), and 2,000 ETH = 2e21 wei used in the WETH approve/deposit calls — all matching the prose figures exactly. The hooks module address quoted in the description (0x8A216F2C84a3fE5a51Bf57B685864A065D14C53a) matches the setHooks() target exactly. The sequence of actions (add DAI asset, add cWETHv3 pricer asset, set new hooks, wrap ETH, reduce DAI/USDC reserves, approve three assets, deposit into vault) lines up one-to-one with the specification's seven steps, including the reserve-reduction and approval/deposit mechanics. The one wording nuance — the proposal describes 'accepting ownership' of the new hooks module whereas the calldata shows only a setHooks() call on the vault — is a minor phrasing simplification of a multi-step process (hooks module deployment/ownership handled outside this proposal), not a material mismatch, since the net effect (vault now uses the new hooks module) is faithfully represented. No omitted, extra, or mismatched values or targets were found that would harm the DAO or mislead voters. The one odd raw value_wei of '2000' on action_index 3 appears to be a data-formatting quirk (the corresponding approve call shows the correct 2000 WETH in full wei), not a discrepancy between the description and the intended calldata effect. Overall the description accurately and completely reflects the decoded actions.
Generated by Kvorum
04Actions
- Target
- 0xc725…9d33
- Value
- 0 wei
- Function
- addAsset((address,uint256,bool,address))
- Arguments
{ "0": [ "0x6B175474E89094C44Da98b954EedeAC495271d0F", "86400", false, "0x773616E4d11A78F511299002da57A0a94577F1f4" ] }- Calldata
- Target
- 0xc725…9d33
- Value
- 0 wei
- Function
- addAsset((address,uint256,bool,address))
- Arguments
{ "0": [ "0x1722942DF424d1C27c6145a83AF195ceb1C60007", "86400", false, "0x1722942DF424d1C27c6145a83AF195ceb1C60007" ] }- Calldata
- Target
- 0x3d6e…1d6b
- Value
- 0 wei
- Function
- setHooks(address)
- Arguments
{ "0": "0x8A216F2C84a3fE5a51Bf57B685864A065D14C53a" }- Calldata
- Target
- 0xc02a…6cc2
- Value
- 2000 wei
- Function
- fallback()
- Arguments
{}- Calldata
- Target
- 0xc02a…6cc2
- Value
- 0 wei
- Function
- approve(address,uint256)
- Arguments
{ "0": "0x3D6eEf6A92b15361697698695334E98C5db91D6b", "1": "2000000000000000000000" }- Calldata
- Target
- 0x5d3a…3643
- Value
- 0 wei
- Function
- _reduceReserves(uint256)
- Arguments
{ "0": "15000000000000000000000000" }- Calldata
- Target
- 0x6b17…1d0f
- Value
- 0 wei
- Function
- approve(address,uint256)
- Arguments
{ "0": "0x3D6eEf6A92b15361697698695334E98C5db91D6b", "1": "15000000000000000000000000" }- Calldata
- Target
- 0x39aa…7563
- Value
- 0 wei
- Function
- _reduceReserves(uint256)
- Arguments
{ "0": "10000000000000" }- Calldata
- Target
- 0xa0b8…eb48
- Value
- 0 wei
- Function
- approve(address,uint256)
- Arguments
{ "0": "0x3D6eEf6A92b15361697698695334E98C5db91D6b", "1": "10000000000000" }- Calldata
- Target
- 0x3d6e…1d6b
- Value
- 0 wei
- Function
- deposit((address,uint256)[])
- Arguments
{ "0": [ [ "0x6B175474E89094C44Da98b954EedeAC495271d0F", "15000000000000000000000000" ], [ "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48", "10000000000000" ], [ "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2", "2000000000000000000000" ] ] }- Calldata
05Tally
Summed from votes
06Voters
No votes recorded yet.
07Forum
- Aera for Compound - Extension ↗discourse · high confidence
Arguments for
- The proposal lets the DAO put idle, non-yielding USDC/DAI reserves and treasury ETH to productive use, generating an estimated $1M+ in annual yield and $30M+ in additional V3 TVL.— Aera, PGov, pennblockchain, AranaDigital
- Aera's non-custodial vault design keeps assets fully controlled by the Compound Governor Timelock, allowing withdrawal at any time, so the DAO retains custody and reserves are not truly depleted.— Aera, cylon, AranaDigital
- Prior Aera programs (Reserves Vault and Vendor Payment Vault) have a track record of success—reallocating long-tail assets, generating ~4% yield, and reducing COMP sell pressure—supporting extending the partnership.— Aera, EventHorizonDAO, cylon, pennblockchain
- Gauntlet's risk simulations show Compound V2's Value at Risk is currently $0 and reserve ratios remain healthy even post-withdrawal, indicating minimal risk to protocol solvency.— Aera, AranaDigital
- The service is free during the pilot phase with no fees to Aera or Guardians, making the upside essentially risk-free from a cost perspective.— PGov, AranaDigital, pennblockchain
- The proposal does not conflict with or foreclose a potential future Compound Staking Program, since sufficient assets remain outside Aera and Aera assets remain flexible.— Aera
- Diversifying and actively managing treasury assets improves protocol robustness during weak price action and helps offset COMP sell pressure from vendor payments.— EventHorizonDAO
Arguments against
None surfaced.
Unresolved concerns
- Reserves are being pulled from the V2 reserve fund, so the DAO must ensure reserves never fall below a safe threshold covering liabilities and should proactively top up if risk metrics deteriorate.— AranaDigital
- Request for other delegates to voice any additional risks they see before the on-chain vote, which does not appear to have been followed up on in the thread.— AranaDigital
- A bug in the solc compiler/via-ir flag prevented verification of an oracle contract on Etherscan, forcing cancellation and redeployment of the original proposal.— Aera
Notable participants
- AeraProposer who outlined the plan, answered questions, managed proposal revisions/cancellations due to a compiler bug, and reported on-chain execution progress.
- PGovEarly supporter who highlighted the yield and TVL benefits and suggested future fee-sharing possibilities.
- EventHorizonDAODelegate offering broad support citing treasury robustness and COMP sell-pressure mitigation.
- AranaDigitalSupportive delegate who raised the main risk-management concern about reserve fund depletion and requested ongoing monitoring.
- cylonOpenZeppelin representative expressing personal support based on security review experience with Aera's vault system.
- pennblockchainDelegate expressing support and framing the $1M yield target as a benchmark for evaluating Gauntlet's performance.
- jbass-ozShared OpenZeppelin's formal security review of the on-chain proposal, noting one low-severity issue.