We appreciate @bgdlabs for bringing this proposal forward and addressing a genuine gap in the current Risk Stewards architecture. With @bgdlabs’ and @ACI’s upcoming departures, revisiting the governance structure around delegated risk authority is both timely and necessary. The proposal makes meaningful progress on role clarity and formalizes @LlamaRisk’s involvement, which is a welcome step.
That said, we have significant reservations about the proposed design that we believe warrant further discussion before this moves to snapshot.
The 1-day timelock undermines the core purpose of manual Risk Stewards. The entire value of Risk Stewards lies in rapid response to time-sensitive conditions: capping supply/borrow to 1 during exploits, raising caps to meet sudden demand, or adjusting interest rate parameters during utilization spikes. A mandatory 1-day delay before execution renders these actions ineffective. The proposed workaround of routing emergency freeze actions through a separate SupplyBorrowFreezeSteward, limited to the Protocol Guardian, fragments authority rather than solving the problem and does not cover the full range of time-sensitive actions Risk Stewards need to perform. Similarly, the Slope2 Risk Oracle is now constrained to act within a 2% range per 8 hours, meaning a Risk Steward may need to intervene manually during severe utilization spikes, an intervention that this proposal would delay by a full day.
The proposal gives LlamaRisk a veto but not a voice. Under this design, @LlamaRisk can only cancel during the timelock window. We cannot co-propose, co-sign, or initiate parameter changes. A co-signing model where any two of three parties must affirmatively agree is a strictly superior design: it provides the same protective guarantees as a veto mechanism, but through collaborative approval rather than adversarial blocking, and without requiring any of the operational delays or additional smart contract infrastructure that a timelock-plus-cancellation architecture introduces.
Automated Risk Oracles are left unaddressed. The proposal explicitly scopes itself to manual AGRS only. The automated Risk Agents, which have required the most scrutiny in light of recent events, are left entirely untouched. We believe automated Risk Agents require their own dedicated discussion. For that context, we propose a short timelock on the order of hours, calibrated per agent type, long enough for independent monitoring and subsequent blocking action to catch incidents like the March 10th liquidations before damage occurs, but short enough to preserve the operational and speed advantages that automation is meant to provide.
What we propose instead is restructuring Risk Stewards as a 2-of-3 co-signing multisig comprising @ChaosLabs, @LlamaRisk, and @AaveLabs. Any two of three parties can approve an update, with immediate execution upon co-approval, no timelock required. This preserves the speed that makes Risk Stewards valuable, adds genuine independent oversight, and ensures it is clean, fair, and representative of the three primary parties engaged in Risk Steward operations. Most importantly, this requires no new smart contract infrastructure beyond a signer rotation on the existing multisig. The proposed timelock, veto, Permissioned Payload Controller, and GranularAccessControl architecture introduces significant and unnecessary complexity to achieve a strictly weaker result than what a simple multisig reconfiguration provides out of the box.
We invite @AaveLabs and @ChaosLabs to weigh in on this 2-of-3 co-signing configuration so that we can collectively align on the right path forward before this proposal moves to snapshot.