A decoded on-chain record published to Aave's governance forum documents three RISK_ADMIN_ROLE grants executed on the Aave V3 Ethereum ACLManager contract between September 2 and September 30, 2026. According to the record, all three grants originated from the protocol's governance Executor address, and one of them is directly linked to the proposal that activates Risk Stewards on Aave V4.

What the decoded record shows

The on-chain decoded governance post (ACLManager RISK_ADMIN_ROLE grants, Sep 2026 — decoded) identifies three discrete grant events recorded in the ACLManager contract, Aave's central access-control registry for the V3 architecture. The ACLManager is the contract through which Aave V3 assigns and manages administrative roles across the protocol, so entries recorded there define who holds delegated authority over risk parameters. In Aave's governance architecture, the Executor contract carries approved proposals out on-chain. All three transactions originated from 0x5300A1a15135EA4dc7aD5a167152C01EFc9b192A, the governance Executor, according to the decoded post.

Two grants landed at block 25,891,729 on September 2, 2026, targeting addresses 0xbe28...7744 and 0x529e...F6c5. The exact contract identities of these two recipients were flagged as unconfirmed in the primary source; according to the on-chain decode, their role and purpose were not fully verified at the time of publication.

The third grant, at block 26,089,561 on September 30, 2026, went to a verified RiskSteward contract carrying approximately 20,061 bytes of deployed code. That grant is directly tied to AIP-523, "Activate Aave Risk Stewards on Aave V4" (governance proposal), which executed around the same date.

Why RISK_ADMIN_ROLE matters for protocol oversight

The RISK_ADMIN_ROLE sits below the full governance tier in Aave's access-control hierarchy. Holders can update reserve factor settings, supply and borrow caps, loan-to-value ratios, liquidation thresholds, liquidation bonuses, and E-Mode category configurations without triggering a separate governance vote for each adjustment. Taken together, these controls determine how much of an asset can enter a market, how collateral is treated during liquidations, and how assets with correlated price behavior are grouped for higher borrowing efficiency. What RISK_ADMIN_ROLE holders cannot do is pause or unpause reserves, or activate and deactivate them entirely; those actions remain with higher-privilege roles.

The practical implication is speed. Protocol risk managers operating under RISK_ADMIN_ROLE can respond to market conditions, liquidity shifts, or oracle anomalies within hours rather than waiting out a multi-day governance cycle. The role is exercised frequently in practice: as of the April 2026 post-mortem on the rsETH incident, the Aave V3 Risk Stewards had already executed approximately 295 individual parameter changes across V3 reserves.

AIP-523 extends the architecture to Aave V4

AIP-523 extends this model to Aave V4 on Ethereum, Avalanche, and Base. The proposal grants bounded, revocable RISK_ADMIN_ROLE authority that is constrained by hard parameter limits rather than relying solely on the reputation of the grantee, and the Aave V4 Risk Stewards framework was designed to formalize those constraints on-chain.

Supply and borrow caps may be increased by no more than 50% in a single Risk Steward update under the V4 framework, according to the AIP-523 governance thread.

Cooldown periods add a second layer of constraint. Hub interest rate and cap changes carry a 36-hour cooldown; spoke and collateral parameters require 72 hours; and oracle price cap updates fall in the 48-to-72-hour range. These intervals are designed to prevent rapid-fire adjustments that could be exploited or accumulate into significant structural changes without community visibility.

Governance considerations and open questions

The design question raised by the September grants is not whether the role is useful — it clearly is — but whether the governance community retains meaningful review capacity once the role is in place. Forum contributor MconnectDAO asked directly: "how will Aave ensure that community discussion remains meaningful and not only a formal approval process?" The concern is structural: a governance vote that grants an open-ended role to a contract effectively pre-authorizes all future parameter changes within that contract's encoded bounds.

Contributor Roch33 outlined a transparency baseline that would address part of this concern, calling for each parameter change to log the previous value and new value, the governance-approved bound being applied, the data source used, and the rationale behind the update. That level of on-chain and forum disclosure would let the community audit whether Risk Steward actions are defensive responses to market data or incremental boundary-pushing.

The two September 2 grantees, 0xbe28...7744 and 0x529e...F6c5, remain an open question. The on-chain decode post flagged their identity as not fully confirmed, and no existing coverage has resolved which contracts or service providers these addresses represent. Until that is established, the community cannot fully assess the scope of delegated authority associated with the September 2 grant event at block 25,891,729. The most concrete follow-up points are therefore confirmation of those recipients, disclosure of subsequent parameter changes against their approved bounds, and any later governance action involving the grants.

For the September 30 RiskSteward grant linked to AIP-523, revocability is a core feature of the design. The governance Executor that granted the role can revoke it through a subsequent proposal, and the bounded parameter caps encoded in the contract itself provide a circuit-breaker against parameter drift even if the role is not revoked. The combination of revocability and encoded limits is intended to keep delegated risk authority subordinate to governance. Aave's 2026 overview of the V4 architecture covers in detail how the protocol handles cross-chain risk delegation under the new framework.