Caps Plus Risk Steward
01Summary
Grant the RISK_ADMIN role to CapsPlusRiskStewards smart contract on Aave v3 networks, enabling the RISK_COUNCIL (Gauntlet and Chaos Labs) to adjust asset borrow/supply caps upwards without full governance voting. Caps can only increase by up to 100% and only once every 5 days per asset.
- Type
- governance change
Key changes
- Grant RISK_ADMIN role to CapsPlusRiskStewards contract across all Aave v3 networks(high)
- Enable RISK_COUNCIL to unilaterally increase asset caps without governance overhead(high)
- Implement safeguards: caps can only increase (not decrease), maximum 100% increase per adjustment, and 5-day cooldown between adjustments per asset(medium)
Notable concerns
- Centralization of cap adjustment authority to risk providers through RISK_COUNCIL
- Removal of community voting on cap increases despite historical unanimous support
- Requires trust in Gauntlet and Chaos Labs decision-making for cap management
Generated by Kvorum
02Description
Simple Summary
This governance proposal grants the RISK_ADMIN role to a CapsPlusRiskStewards smart contract on each network with an active instance of Aave v3.
Once the CapsPlusRiskStewards has received the RISK_ADMIN role, the RISK_COUNCIL can adjust asset borrow/supply caps upwards without voting overhead. The RISK_COUNCIL is a Gnosis Safe controlled by the DAOs risk-providers (Gauntlet, Chaos Labs).
Motivation
During the last months, for the broad majority of proposals regarding caps updates, the support of the community has been almost unanimous, with 1 or 2 exceptions. The rationale of this is pretty clear: caps updates usually simply depend on the “green light” from the risk providers (Gauntlet, Chaos Labs) As both providers have historically been in agreement with the updates proposed, the community has just followed that recommendation by supporting on-chain.
Therefore, it seems that the community has important voting overhead in this scenario, which could be almost completely automated and simplified. It is quite common to have a proposal with unanimous support on day 1 of voting but given all other time considerations, execution is 3 to 5 days after.
This proposal gives the necessary RISK_ADMIN role to the CapsPlusRiskSteward introduced in this governance forum thread.
After execution, the RISK_COUNCIL will be able to perform cap increases through the CapsPlusRiskStewards under the following conditions for each asset listed:
- the cap can only be adjusted upwards
- the cap can never be increased by more than 100%
- the cap can only be adjusted once every 5 days
Specification
This proposal's payload executes ACL_MANAGER.addRiskAdmin(STEWARD) where STEWARD is the CapsPlusRiskStewards pre-deployed on the respective network.
Security procedures
The CapsPlusRiskStewards is unit tested.
The proposal execution is simulated within the tests.
Deployed Contracts
- CapsPlusRiskSteward: arbitrum, avalanche, mainnet, metis, optimism, polygon
- Payloads: arbitrum, avalanche, mainnet, metis, optimism, polygon
References
- Snapshot
- Discussion: CapsPlusRiskSteward
- Discussion: caps update framework
- Discussion: fast track process
- Code: ProposalPayload
- Code: Payload Tests
- Code: CapsPlusRiskSteward
- Code: CapsPlusRiskSteward Tests
Copyright
Copyright and related rights waived via CC0.
03Mismatch analysis
I compared the six networks and payload/steward addresses explicitly named in the description's 'Deployed Contracts' section against the five decoded calldata actions. Actions 0-4 correctly correspond, by address, to the Mainnet, Polygon, Arbitrum, Optimism, and Metis payloads listed in the description (action 0 executes the Mainnet payload directly via fallback, while actions 1-4 route through bridge/executor contracts to the respective L2/sidechain payloads). All five matched addresses are consistent with what the description claims for those networks. However, the description states the RISK_ADMIN role will be granted to the CapsPlusRiskStewards contract on Avalanche as well, and even lists a specific deployed Avalanche steward and payload address, but no action in the provided calldata targets or references Avalanche in any way. This means the on-chain actions do not fully execute what the description promises — the Avalanche cap-increase capability described would not actually be enabled by this proposal's execution. This is a concrete, checkable gap between claimed scope and actual on-chain effect, so I classified it as a material discrepancy (extra claim in description not backed by calldata) rather than a severe one, since no funds or control are misdirected — one network's automation feature simply would not go live as claimed.
Discrepancies
- mediumextra in description
The description explicitly lists Avalanche as one of the six networks receiving the CapsPlusRiskStewards RISK_ADMIN grant, and provides both a deployed CapsPlusRiskSteward address (0xd2c92b...) and a corresponding Payload address (0x7e1f23bdfc7287af276f77b5a867e85cf0377a31) for Avalanche. However, none of the five decoded on-chain actions reference the Avalanche payload address or an Avalanche bridge/executor contract. The calldata only covers Mainnet, Polygon, Arbitrum, Optimism, and Metis — Avalanche is missing entirely.
“grants the `RISK_ADMIN` role to a `CapsPlusRiskStewards` smart contract on each network with an active instance of Aave v3”
Generated by Kvorum
04Actions
- Target
- 0x9012…3fd4
- Value
- 0 wei
- Function
- fallback()
- Arguments
{}- Calldata
- Target
- 0x158a…d45b
- Value
- 0 wei
- Function
- execute(address)
- Arguments
{ "0": "0x4C0633Bf70fB2bB984A9eEC5d9052BdEA451C70A" }- Calldata
- Target
- 0xd1b3…cfa3
- Value
- 0 wei
- Function
- execute(address)
- Arguments
{ "0": "0xE79Ca44408Dae5a57eA2a9594532f1E84d2edAa4" }- Calldata
- Target
- 0x5f5c…6711
- Value
- 0 wei
- Function
- execute(address)
- Arguments
{ "0": "0xA3e44d830440dF5098520F62Ebec285B1198c51E" }- Calldata
- Target
- 0x2fe5…c08f
- Value
- 0 wei
- Function
- execute(address)
- Arguments
{ "0": "0xd91d1331db4F436DaF47Ec9Dd86deCb8EEF946B4" }- Calldata
05Tally
Summed from votes
06Voters
| Voter | Choice | % of total | Rationale | ||
|---|---|---|---|---|---|
| 320x329c…3ed4 | For | 231K | 0.00% | — | 4y ago |
| 620x62a4…816a | For | 82.4K | 0.00% | — | 4y ago |
| B80xb83b…cf5c | For | 81K | 0.00% | — | 4y ago |
| B90xb933…8dd1 | For | 41.7K | 0.00% | — | 4y ago |
| 180x1855…98ba | For | 3K | 0.00% | — | 4y ago |
| A00xa06c…61f7 | For | 678.8 | 0.00% | — | 4y ago |
| EA0xea17…6676 | For | 39.6 | 0.00% | — | 4y ago |
| F60xf614…a116 | For | 0.8 | 0.00% | — | 4y ago |
| E40xe459…e666 | For | 0.5 | 0.00% | — | 4y ago |
| 8D0x8d52…6f34 | For | 0.1 | 0.00% | — | 4y ago |
| 450x45b7…e322 | For | 0 | 0.00% | — | 4y ago |
07Forum
- [ARFC] Aave V3 Caps update Framework ↗discourse · high confidence
- [ARC] V3 Supply/borrow cap management Fast-track process ↗discourse · high confidence
Arguments for
- A direct-to-AIP process for cap changes/FreezeReserve reduces governance delay and helps the protocol adapt quickly to market conditions.— MarcZeller
- Introducing 'Risk Steward' smart contracts controlled by a 2-of-2 Gauntlet/Chaos Labs multisig would automate routine cap updates and cut voting overhead while speeding execution.— bgdlabs, MarcZeller, dtalwar, ChaosLabs, fig
- Historical data shows cap-update proposals have been near-unanimously supported by the community, justifying automation of these routine decisions.— bgdlabs
- Aave governance retains full sovereignty and can revoke Risk Steward permissions at any time, preserving ultimate DAO control.— bgdlabs, MarcZeller
- A leaner, simpler governance structure for routine risk-parameter changes aligns with Aave's broader governance philosophy and improves efficiency.— fig
Arguments against
None surfaced.
Unresolved concerns
- Decreasing supply/borrow caps could in some cases effectively freeze a reserve, and the community's view on allowing this outcome was not settled in the thread.— ChaosLabs
- Whether the Risk Steward multisig should be expanded beyond Gauntlet and Chaos Labs to include entities like ACI, Llama, or governance coordinators remained an open question, with MarcZeller preferring to wait until the pilot matures.— fig, MarcZeller
- The long-term solution of an elected Risk Council with broader risk-management authority was acknowledged as technically possible but still immature, leaving the Risk Steward as only a temporary measure.— MarcZeller
Notable participants
- MarcZellerOriginal proposer of the Caps Update Framework and vocal supporter of the subsequent Risk Steward proposal, responding to community suggestions.
- bgdlabsProposed the Risk Steward smart contract mechanism to automate cap changes via a Gauntlet/Chaos Labs multisig.
- dtalwarRepresented Gauntlet, expressing support for reducing governance overhead through automation.
- ChaosLabsRepresented Chaos Labs, supporting the proposal while flagging a concern about cap decreases effectively freezing reserves.
- figRepresented Flipside, endorsing the leaner governance approach and suggesting future expansion of the multisig.
- Kene_AnodeAgreed to incorporate the new framework into the broader Aave governance process documentation.
Generated by Kvorum
08Similar proposals
- aaveexecutedCaps Risk Oracle Activation on Base, Avalanche84%
- aaveexecutedAave Generalized Risk Stewards (AGRS) activation84%
- aaveexecutedCaps Risk Oracle Activation on Optimism, BNB, Gnosis, Polygon82%
- aaveexecutedCaps Risk Oracle Activation on Arbitrum81%
- aaveexecutedRisk Stewards Cooldown Reduction & Umbrella Pauser Role Reassignment78%
- aaveexecutedSteward Deployment: MainnetSwapSteward and RewardsSteward76%
- aaveexecutedActivate Capo Risk Agent and expand Rates Agent on more networks75%
- aaveexecutedClinic steward activation75%
- aaveexecutedFreeze Stewards73%
- aaveexecutedDiscount Rate Risk Oracle Activation and update manual AGRS73%