# ACLManager: RISK\_ADMIN\_ROLE grants, Sep 2026 — decoded **URL:** \ **Category:** Risk\ **Created:** [November 9, 2026, 12:45am UTC](https://governance.aave.com/t/aclmanager-risk-admin-role-grants-sep-2026-decoded/26139 "2026-11-09T00:45:03Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![UpdradeTrail](https://avatars.discourse-cdn.com/v4/letter/u/b9bd4f/32.png) [@UpdradeTrail](https://governance.aave.com/u/UpdradeTrail)\ **Post date:** [November 9, 2026, 12:45am UTC](https://governance.aave.com/t/aclmanager-risk-admin-role-grants-sep-2026-decoded/26139/1 "2026-11-09T00:45:03Z")
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?