Posting a factual decode of recent ACLManager role activity on Aave V3 Ethereum, in the dated-report style already used in this category.
Three RISK_ADMIN_ROLE grants since 2 September 2026:
2 Sep 2026, block 25891729 — granted to 0xbe28…7744 and 0x529e…F6c5 (two grants, same transaction)
30 Sep 2026, block 26089561 — granted to 0x6f48d9cdb8ee6e17c96b2d8aec128af426a295c1
The 30 Sep recipient is a verified contract named RiskSteward, 20,061 bytes of deployed code.
All three grants were sent by 0x5300A1a15135EA4dc7aD5a167152C01EFc9b192A, which is the governance Executor. So these passed governance rather than originating from a standalone admin key — worth stating explicitly, since a RISK_ADMIN grant from an EOA would read very differently.
Practical scope: RISK_ADMIN can change supply and borrow caps, LTVs, liquidation thresholds and reserve configuration without a full governance vote. Routing it through a RiskSteward contract constrains what the holder may change, which is the safer pattern, but each grant still widens the set of actors who can move risk parameters between votes.
Context: the ARFC “Activate Aave Risk Stewards on Aave V4” thread is now closed with AIP #523 executed, so I’m posting this separately rather than reverting that thread.
Method note: this is decoded from ACLManager’s RoleGranted logs plus the role constants read off the contract itself. I have not diffed storage layouts or reviewed the RiskSteward contract’s internal constraints — so I’m not making any claim about what that specific steward is or isn’t able to do.
Question for anyone closer to it: is the 30 Sep grant part of the V4 Risk Steward rollout, or a separate V3 steward deployment? And is the intended steady state one steward contract or several?