---

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

1. Gather feedback from the community.
2. If consensus is reached on this ARFC, escalate this proposal to the Snapshot stage.
3. If the Snapshot outcome is YAE, this proposal will be implemented.

Copyright

Copyright and related rights waived via CC0.