Aera for Compound Service Provider Payments
01Summary
Compound DAO proposes establishing an Aera vault to streamline vendor payments by converting COMP into USDC through automated on-chain processes. The vault will deposit USDC into cUSDCv3 to generate yield while funding vendor payment streams, reducing price risk and governance overhead. This proposal initializes the vault with 133,300 COMP, with future vendor payment streams to be established through separate proposals.
- Type
- treasury allocation
- Funding
- $133300000
Key changes
- Grant 133,300 COMP to Compound Timelock for Aera vault operations(high)
- Transfer 133,300 COMP from COMP token contract to Aera vault(high)
- Accept ownership of Aera vault, hooks module, and asset registry by Compound Governor Bravo Timelock(high)
- Resume Aera vault operations to enable guardian-controlled diversification and payment stream management(high)
- Establish automated COMP-to-USDC conversion mechanism through UniV3, Bebop, and Milkman(medium)
- Deposit USDC into Compound III ETH-USDC comet (cUSDCv3) to generate yield(medium)
Notable concerns
- Guardian role assigned to Gauntlet requires trust in third party
- Vault depends on external swap protocols (UniV3, Bebop, Milkman) for COMP-to-USDC conversion
- Vendor-specific payment streams require future governance proposals
- Price fluctuation buffer adequacy depends on market conditions and annual expenditure accuracy
Generated by Kvorum
02Description
Aera for Compound Service Provider Payments
Simple summary
We propose a standard payment process to be followed by all service vendors of the Compound DAO. This new process utilizes on-chain protocols, Aera Vault and LlamaPay, to setup long-term payment streams in USDC that reduces both price-risk for vendors and governance overhead for DAO voters. This has the added benefit of improving the financial position of the DAO treasury allocated to future service costs by supplying liquidity to cUSDCv3 that earns additional yield.
We propose using an Aera vault as a mechanism for vendors to receive payments in stablecoins while also providing liquidity for key Compound markets for unvested payment streams. Specifically we propose:
- Creating an Aera vault owned by Compound Governance that deposits a lump sum of COMP based on current annual expense needs plus an additional buffer to hedge for price fluctuations
- The Aera vault will diversify out of COMP and into USDC using onchain vehicles like UniV3, Bebop, and Milkman
- USDC will be deposited into the Compound III ETH-USDC comet as cUSDCv3 to generate yield on the holdings while providing liquidity to the market
- Payment streams will be set up per vendor that uses the Aera vault as a source and the Vendor’s multisig as a sink transferring USDC to meet Compound vendor payment obligations.
- On a yearly cadence the Aera vault will be topped up with COMP via Compound governance.
This proposal will enable the first three steps by initializing an Aera vault and funding it with COMP. Payment streams to vendors will be initiated through future proposals.
This is a non custodial vault, where the Compound Governor Bravo Timelock is the owner of the vault (and thus governance votes can initiate withdraw/deposit requests at any time). Gauntlet will be the guardian for this vault.
Specification
This proposal will: 1. acceptOwnership of the Aera vault, hooks module, and asset registry 2. _grantComp to the Compound Timelock address 3. transfer COMP to the vault 4. resume the vault, allowing the guardian to operate
03Mismatch analysis
The proposal's specification lists four concrete steps: (1) accept ownership of the vault, hooks module, and asset registry, (2) grant COMP to the Timelock, (3) transfer COMP to the vault, and (4) resume the vault. The decoded calldata contains exactly six actions that map cleanly onto these four steps: a _grantComp call (action 0), a COMP transfer to the vault address (action 1), three acceptOwnership() calls to three distinct contract addresses (actions 2-4, matching vault/hooks/asset registry), and a resume() call (action 5). The COMP amount (133,300 COMP) is not specified numerically in the prose, which only describes it qualitatively as 'annual expense needs plus a buffer,' so there is no verifiable numeric mismatch. The only difference is the execution order (grant+transfer occur before the acceptOwnership calls in calldata, whereas the description lists acceptOwnership first), which is a technical necessity (grant must precede transfer) and does not affect the outcome or introduce risk. No targets, recipients, or amounts are contradicted, and no undisclosed actions (e.g., unrelated transfers, role grants) are present. Given the strong 1:1 correspondence between prose steps and calldata actions, this proposal is assessed as consistent with high confidence.
Discrepancies
- lowmisleading phrasing
The description lists the four steps in the order: acceptOwnership, grantComp, transfer, resume, while the calldata executes grantComp and transfer before the three acceptOwnership calls and the final resume. This is a purely mechanical ordering difference required for the grant-then-transfer logic to work (COMP must be granted to the Timelock before it can be transferred to the vault), and does not change the substance of what is executed.
“1. acceptOwnership of the Aera vault, hooks module, and asset registry 2. _grantComp to the Compound Timelock address 3. transfer COMP to the vault 4. resume the vault”
Generated by Kvorum
04Actions
- Target
- 0x3d98…cd3b
- Value
- 0 wei
- Function
- _grantComp(address,uint256)
- Arguments
{ "0": "0x6d903f6003cca6255D85CcA4D3B5E5146dC33925", "1": "133300000000000000000000" }- Calldata
- Target
- 0xc00e…6888
- Value
- 0 wei
- Function
- transfer(address,uint256)
- Arguments
{ "0": "0x8624f61Cc6e5A86790e173712AfDd480fa8b73Ba", "1": "133300000000000000000000" }- Calldata
- Target
- 0x8624…73ba
- Value
- 0 wei
- Function
- fallback()
- Arguments
{}- Calldata
- Target
- 0x29db…c3a7
- Value
- 0 wei
- Function
- fallback()
- Arguments
{}- Calldata
- Target
- 0xb01b…bcee
- Value
- 0 wei
- Function
- fallback()
- Arguments
{}- Calldata
- Target
- 0x8624…73ba
- Value
- 0 wei
- Function
- fallback()
- Arguments
{}- Calldata
05Tally
Summed from votes
06Voters
| Voter | Choice | % of total | Rationale | ||
|---|---|---|---|---|---|
| 8D0x8d07…a265 | For | 70K | 0.00% | — | 3y ago |
| B90xb933…8dd1 | For | 54.1K | 0.00% | — | 3y ago |
| 680x683a…6c02 | For | 50.1K | 0.00% | — | 3y ago |
| 7A0x7ae1…e585 | For | 50K | 0.00% | — | 3y ago |
| B40xb49f…7948 | For | 50K | 0.00% | — | 3y ago |
| 070x0703…961b | For | 50K | 0.00% | — | 3y ago |
| 130x13bd…8548 | For | 50K | 0.00% | — | 3y ago |
| DC0xdc1f…e432 | For | 50K | 0.00% | — | 3y ago |
| 7B0x7b3c…cc33 | For | 50K | 0.00% | — | 3y ago |
| 3F0x3fb1…4c8a | For | 25.6K | 0.00% | — | 3y ago |
| B30xb356…c826 | For | 2.1K | 0.00% | — | 3y ago |
| 5C0x5c04…dc62 | For | 454.4 | 0.00% | — | 3y ago |
| E40xe459…e666 | For | 5.2 | 0.00% | — | 3y ago |
| DB0xdb83…bb43 | For | 0.1 | 0.00% | — | 3y ago |
| E30xe364…5413 | For | 0.1 | 0.00% | — | 3y ago |
| CF0xcfb6…18c5 | For | 0.1 | 0.00% | — | 3y ago |
| FB0xfb2a…00ab | For | 0.1 | 0.00% | — | 3y ago |
| BA0xba03…b48b | For | 0.1 | 0.00% | — | 3y ago |
| 060x06c4…66a2 | For | 0.1 | 0.00% | — | 3y ago |
| 4A0x4afa…7426 | Against | 0.1 | 0.00% | — | 3y ago |
| D80xd8de…ae41 | For | 0.1 | 0.00% | — | 3y ago |
| 9E0x9ef1…fc1e | Abstain | 0 | 0.00% | — | 3y ago |
| 1D0x1d41…7fde | For | 0 | 0.00% | — | 3y ago |
| BA0xba9b…3718 | For | 0 | 0.00% | — | 3y ago |
| 120x1297…b19c | For | 0 | 0.00% | — | 3y ago |
| 200x206b…c54a | For | 0 | 0.00% | — | 3y ago |
| 0C0x0c7f…9284 | For | 0 | 0.00% | — | 3y ago |
| 240x2421…1806 | For | 0 | 0.00% | — | 3y ago |
| BE0xbefb…e70f | For | 0 | 0.00% | — | 3y ago |
| 300x30cf…7f68 | For | 0 | 0.00% | — | 3y ago |
| D00xd0a4…36e0 | For | 0 | 0.00% | — | 3y ago |
| 590x5918…6988 | For | 0 | 0.00% | — | 3y ago |
07Forum
- [Proposal] Aera for Compound Service Provider Payments ↗discourse · high confidence
Arguments for
- Paying vendors in stablecoins via an Aera vault removes COMP price risk and volatility exposure for service providers, avoiding forced sales at inopportune times.— Aera, cylon
- Structured, algorithmic execution (via CoW Swap/Milkman and Bebop) minimizes price impact from selling COMP compared to ad hoc vendor liquidations.— Aera
- Depositing generated USDC into cUSDCv3 provides Compound III liquidity and earns yield, improving the treasury's financial position while funds await disbursement.— Aera
- Switching from Sablier to LlamaPay open-ended streams is more capital efficient, avoiding the need to escrow the full payment amount upfront.— Aera
- The proposal reduces governance overhead and voter fatigue by moving vendors to a yearly renewal cadence instead of frequent quarterly proposals.— Aera, cylon
- Aera has a track record with Compound's V2 reserves pilot, successfully selling ZRX with low slippage, and has been audited by OpenZeppelin, building confidence in the mechanism.— Aera
- This is a mutually beneficial 'win-win-win' for the DAO, vendors, and tokenholders, allowing OpenZeppelin to move back to a yearly renewal model with reduced financial risk.— cylon
Arguments against
- Selling a large amount of COMP every quarter could negatively affect the token price.— dmitriywoofsoftware
Unresolved concerns
- Concern that repeated quarterly COMP sales of this magnitude could depress token price, though Aera argued volume is small relative to daily trading volume.— dmitriywoofsoftware
- Suggestion that some portion of service provider payments should remain COMP-denominated to preserve incentive alignment between vendors and tokenholders was raised but not addressed within the thread.— monet-supply
Notable participants
- AeraProposer and primary author who detailed the mechanism, responded to concerns, and posted execution updates.
- cylonRepresents OpenZeppelin, expressing strong support and intent to adopt the new payment structure.
- dmitriywoofsoftwareRaised a concern about the price impact of frequent large COMP sales.
- monet-supplyGenerally supportive but suggested retaining a partial COMP-denominated payment component for incentive alignment.