Aave DAO is voting on a plan to let Risk Stewards freeze markets instantly in emergencies but not unfreeze them without further approval, raising new questions about protocol control and accountability for users and developers
Aave's latest governance proposal would hand select Risk Stewards the power to freeze lending markets on Ethereum and Avalanche at a moment's notice-yet leave them unable to reverse those actions without a separate, slower process. This one-way emergency authority, if approved, would be in place before the technical ability to use it even exists, setting up a new layer of protocol risk management that is both immediate and incomplete.
Emergency Powers Without the Off Switch
The core of the proposal is stark: Risk Stewards could instantly halt or freeze assets and reserves if a threat emerges, but they would not be able to unfreeze or reactivate those markets. That reversal would require a separate governance process and Security Council intervention. The emergency permissions themselves are not yet active in the current steward software, but the roles would be assigned now so that future upgrades could enable them without waiting for another governance vote. This approach aims to reduce response time in a crisis, but it also means that powerful permissions would exist in the system before the code to use them is fully deployed or audited.
Redesigning Protocol Control
The proposal would split Aave V4's risk and emergency controls into five granular roles, including two for flag control, one for listings, one for emergencies, and one for risk management. Existing domain admins would retain their reach by receiving the new roles. Routine parameter changes-such as interest rates, collateral factors, and liquidation settings-would be subject to minimum cooldowns of 36 to 72 hours and strict movement caps, but emergency actions would bypass these delays. Notably, the emergency role is strictly one-way: it can pause or freeze, but not unpause or unfreeze. The more flexible flag-control roles, which allow toggling states in both directions, would not be given to Risk Stewards.
Accountability and Activation
Assigning these roles now means that, once the steward software is upgraded, Risk Stewards could act immediately in a crisis. Yet the proposal does not require public rationales, post-action reports, or periodic reviews of steward actions. Forum participants have called for more transparency and oversight, but these measures remain optional. The proposal's Snapshot vote opened on September 3 and closes September 6, but even if it passes, the system would not activate until the Security Council executes the payloads. The underlying contracts are still undergoing a Certora audit, with Aave Labs stating that the process is nearing completion but not yet finalized.
Market Impact and Precedent
If enacted, the immediate effect would be to grant Risk Stewards no-delay access to bounded parameter controls, while the one-way emergency freeze powers would be pre-positioned for future use. This structure is designed to let Aave respond faster to threats, but it also introduces a new accountability gap: emergency permissions would exist before they can be exercised, and without mandatory reporting. The move comes as DeFi protocols face increasing scrutiny over who can intervene in markets and how quickly. Similar concerns about thin liquidity and market access have surfaced in other contexts, as reported earlier when tokenized stock markets struggled to function during U.S. market closures.
As of September 6, Aave's total value locked (TVL) across all networks stands at over $10 billion, according to DeFiLlama. The protocol's Ethereum deployment accounts for the majority of this figure, with Avalanche representing a smaller but still significant share. Aave's governance token, AAVE, has seen daily trading volumes between $50 million and $100 million on major exchanges in the past week. The outcome of the current Snapshot vote could affect how quickly Aave can respond to future security incidents or market disruptions, especially as the protocol expands its risk management framework.
Emergency controls in DeFi protocols are a double-edged sword. While rapid intervention can limit losses during an exploit or oracle failure, the existence of powerful admin roles-especially those that can only restrict but not restore functionality-raises questions about decentralization, user trust, and operational resilience. Assigning permissions before the supporting code is fully live or audited may speed up future responses, but it also creates a window where authority exists without clear checks. For users and developers, understanding who holds these keys and under what conditions they can act is essential to evaluating protocol risk and governance maturity.
