title: [ARFC] June - Update Signers and SAFE Configuration
author: @TokenLogic
created: 2026-06-02
Summary
This proposal follows the March 2026 signer update and achieves two key goals.
- Refreshes the signer composition across the seven budget / asset-holding SAFEs as the Aave service provider roster consolidates.
- Strengthens the configuration of these SAFEs so that each is controlled by a 2-of-3 signer set in which every signer is an independent, organisation-controlled Nested SAFE.
Motivation
With the number of Aave service providers consolidating, this publication proposes consolidating the SAFE signers among the remaining active service providers to govern the movements of the Aave DAO’s funds.
In addition to updating the signers, this proposal aligns the budget/asset-holding SAFEs with the structure that utilises Nest Safes, introducing a model in which the entities holding signing power are themselves multi-signature accounts, rather than a flat list of individual keys. Adopting this now, while the roster is being refreshed, avoids a second disruptive change later and brings the budget / asset-holding SAFEs in line with current best practice.
The emphasis of this update is the security architecture rather than the composition of any individual signer group. In line with established treasury security practice, individual signer identities have been omitted.
Security Architecture Overview
Treasury operations managed through these SAFEs follow a two-layer model.
Layer 1, the budget / asset-holding SAFEs (anchors). These SAFEs receive funds from the Aave Collector. They are the security anchors of the structure and are each configured as a 2-of-3 signer set, where each of the three signers is an independent, organisation-controlled Nested SAFE. Funds at this layer are protected by the combination of an organisation-level quorum and each organisation’s own internal signing controls.
Layer 2, the Operations SAFEs. The Operations SAFEs do not hold idle treasury. Each draws only the funds it needs, when it needs them, by pulling capped amounts from its associated budget SAFE through on-chain spending-limit allowances. This keeps the value held in working wallets to a minimum at all times.
The configuration rests on the following principles, drawn from established security frameworks:
- Hot and cold separation, defence in depth. Value concentrates at a single, well-protected anchor, while day-to-day operations run through tightly scoped wallets that hold little or nothing at rest.
- Organisation-controlled Nested SAFEs. Each signer on a budget SAFE is a multi-signature account operated by one organisation. This decouples the organisation-level quorum (2-of-3) from each organisation’s internal key management. An organisation can rotate its internal signers locally without requiring a DAO-level signer change, and no single individual can act on behalf of the organisation.
- Separation of proposal and signing. Transaction creation is delegated to proposer addresses, held on personal cold wallets, that can queue transactions but carry no signing authority. This keeps day-to-day transaction preparation simple and low-friction, while approval and execution remain exclusively with the organisation-controlled Nested SAFEs. Preparing a transaction and authorising it are deliberately kept as separate privileges.
- OpSec by construction. Because signing power sits at the organisational level, individual signers are not exposed on-chain or in governance documentation, reducing the personal targeting surface for those involved.
- Just-in-time, capped funding. On-chain spending-limit allowances govern how much each Operations SAFE can draw and how often, so the amounts moved are bounded and auditable, and the treasury is never left idle in operational wallets.
- Redundancy and continuity. The 2-of-3 threshold preserves execution reliability if any single organisation is temporarily unavailable, without lowering the bar for unilateral action.
Specification
Signing Organisations
Each budget / asset-holding SAFE is signed by the same three independent organisations, each operating its own Nested SAFE:
| Name | Address |
|---|---|
| Signer 1 | 0xa2DCdD6e0b5e0d118E2Fa8922552AC0Fe26EFe58 |
| Signer 2 | 0xb291232F480F41c75802C4a60F1D2AC03404Afef |
| Signer 3 | 0x4b752551fC6345A7de82F76fd7a5015CA16d1a74 |
Consistent with the security objectives above, the individual signer address and name within each organisation’s Nested SAFE have been omitted, whilst the signing addresses across the Operational SAFEs have been included in this proposal.
| Name | Address |
|---|---|
| Signer 1 | 0x25044f197127209b397987f387A5680A485F15eF |
| Signer 2 | 0x8f28a95CDded08C36883477D96d751412915DCD4 |
| Signer 3 | 0xCAC616Fffb687cBDDD250b2aE6F672449462985C |
| Signer 4 | 0xb647055A9915bF9c8021a684E175A353525b9890 |
| Signer 5 | 0x45d11217458aEE68A4D976A8f17e2E24Fc5898A1 |
| Signer 6 | 0x009d13E9bEC94Bf16791098CE4E5C168D27A9f07 |
| Signer 7 | 0x606dC57cd166643760E049609bfd1D8a698D3bAc |
Budget / Asset-Holding SAFEs
Each of the seven active budget / asset-holding SAFEs is configured as 2-of-3, with each signer being one of the three organisation-controlled Nested SAFEs listed above:
| Name | Address |
|---|---|
| Aave Protocol Embassy (APE) | 0xAA43203167317DeeF8288095C44b84a686918d2E |
| Aave Liquidity Committee (ALC) | 0xA1c93D2687f7014Aaf588c764E3Ce80aF016229b |
| Aave Helper Asset Budget (AHAB) | 0xAA2461f0f0A3dE5fEAF3273eAe16DEF861cf594e |
| Aave Finance Committee (AFC) | 0x22740deBa78d5a0c24C58C740e3715ec29de1bFa |
| Aave Rewards | 0x66Ac7223048037826e12cef9a848199e31AEFabE |
| CEX Earn | 0xAA12BAd4a501d45A5b771e49C2Fd415BA8BFc79d |
| Aave v4 Security | 0xAAf400e4Bbc38B5E2136C1a36946Bf841A357307 |
| Aave Liquidity SAFE | 0xAAA973Fe8A6202947e21D0a3a43d8E83ABE35C23 |
| Frontier | 0xCDb4fA6ba08bF1FB7Aa9fDf6002E78EDc431a642 |
| Merit Program | 0xdeadD8aB03075b7FBA81864202a2f59EE25B312b |
Note: The Frontier SAFE (winding down) and the Merit Assets SAFE (sunsetting) are to be updated where practicable.
Operations SAFEs
The Operations SAFEs continue to be funded by drawing on their associated budget/asset-holding SAFEs via on-chain spending-limit allowances, with each SAFE maintaining the configuration appropriate to its function. Signing authority across the Operations SAFEs is provided by the same three organisations, ensuring a consistent and accountable signing layer across the structure.
| Name | Signer | Address |
|---|---|---|
| APE Vote | 2 of 5 | 0xa9e777D56C0Ad861f6a03967E080e767ad8D39b6 |
| ALC Vote | 2 of 5 | 0xAA484Ba6a7f51f00A3f82a11e73b741AE1dEAB58 |
| ALC Incentives | 3 of 5 | 0xAAB6f926DCDaE536F54ce58478Dbc1a0d0f98871 |
| Rewards Incentive | 3 of 5 | 0x89587ebe7cFF64c6527fE2Deccc3521D75763E8D |
| Merit Incentive | 3 of 5 | 0xAA870e4B82deaDa3727235f34183Ec9B728714C8 |
| Ahab Incentives | 3 of 5 | 0xAAd742dd9111373ec3C1E53b005e870d4CfF3be2 |
| CEX Earn Incentives | 3 of 5 | 0xaa7A1910BA79B6A2E385ebA26185aA2dCB9B8eAd |
Toward Standardised Fund-Movement Frameworks
With standardised frameworks and policies governing how funds are moved and processed across the protocol’s SAFEs. Clear, repeatable processes for proposing, verifying, and executing treasury transactions make operations more consistent, more auditable, and less reliant on any single participant.
The architecture outlined in this proposal is designed to fit comfortably within these frameworks. Organisation-level signing, capped just-in-time funding, and a clearly defined hierarchy provide a foundation on which transaction runbooks, verification checklists, and reporting standards can be layered over time. TokenLogic is aligning with this approach and is glad to support the DAO in refining these frameworks.
Execution Note
Each SAFE update should be executed as a single batched transaction (swapOwner, addOwnerWithThreshold, removeOwner) so that the SAFE does not transit through a state with insufficient signers relative to its threshold.
Disclaimer
TokenLogic is an active service provider to the Aave DAO, the beneficiary of stream 100072 and the KPI as outlined in this publication. The scope of this engagement is available via this forum proposal.
TokenLogic supports and maintains an independent delegate voting platform within the Aave community.
TokenLogic and associated entities have no undisclosed material conflicts of interest at the time of submission.
Next Steps
- Gather feedback from the community.
- If consensus is reached on this ARFC, escalate this proposal to the Snapshot stage.
- If the Snapshot outcome is YAE, this proposal will be implemented.
Copyright
Copyright and related rights waived via CC0.