Thanks for the updated proposal.
While I don’t think it’s perfect, I want to differ from colleagues who argue it hasn’t addressed the previous criticisms. It has, in several meaningful ways, and I came into this vote leaning toward support. I spent time verifying the deployed contracts before voting, and what I found is why I ultimately can’t — I’ll show my work below so anyone can check it.
Board process. I would have preferred the board be elected in a separate discussion rather than appointed and ratified in one vote — likely a formality given vote distribution, but better process. Terms should also be staggered so all three independent seats don’t expire simultaneously, and I’d note the Founder and ED seats carry no terms at all: the seats with the most structural weight are the only ones exempt from any renewal cycle. So this is really more a complaint than a blocker.
Endowment ownership (or “what the code actually does”). This feels like it should have been a social proposal but is already an executable, and the second transaction swaps the sole owner of the Endowment Safe (1-of-1, ~$65M) from the DAO’s governance timelock to a new EndowmentTimelock (0x0bcC…406C). That timelock’s only proposer is the Foundation’s 3-of-5 Safe; the only check is an EndowmentSecurityCouncil contract (0x0A93…3EdD) that lets the 5-of-8 Security Council cancel queued transactions — and which expires on Aug 7, 2028, after which anyone can strip its role. To their credit, the safeguard is real and correctly built on the audited Blockful pattern. But note two things: none of these addresses appear in the proposal text (voters are approving a swapOwner to an undocumented destination), and after 2028 the veto can only be reinstated if the Foundation itself queues the grant — the watched party controls the renewal of its own watchdog, while the custody transfer has no expiration.
After execution, the DAO appears nowhere in the control chain: not as Safe owner, not as proposer, not as admin. The draw limits, budget bounds, and the $500k standup cap exist in prose only — the executable enforces none of them. The conflict-of-interest recusals likewise have no onchain existence; the Foundation Safe is a flat 3-of-5 that will process any transaction three keys sign, whatever the COI policy says.
Role confusion. This also inverts the manager relationship. Karpatkey’s Roles permissions are untouched and the 9-day timelock applies only to owner-level transactions — so day-to-day management of the full $65M continues outside the timelock, while the Foundation inherits the principal’s powers: rescoping, replacing, or removing the Endowment Manager, decisions that today belong to the DAO.
A better model keeps the parties independent:
-
The DAO owns and controls the Endowment, with hard-coded and constitutional limits on outflows.
-
The DAO chooses both the Foundation’s board and the Endowment Manager.
-
The Endowment Manager (currently Karpatkey) pursues long-term growth of the funds.
-
The Foundation’s board makes an annual budget, seeks DAO approval, and withdraws only that amount to its wallet.
-
The Foundation uses that budget to pick providers and fund development.
-
Providers make technical decisions for the protocol.
The current proposal collapses this: the Foundation becomes owner, principal, and budget-setter at once, and given the Founder seat’s succession to an ENS Labs representative, a structural majority on that board sits within reach of a single stakeholder needing only two of the remaining four votes.
I came to this really wanting to vote for it. I think the proposal text addresses a lot of the issues respectfully. I was even going to criticize but ultimately was ok with the idea of legal ownership of the Endowment sitting within a Cayman framework – but having the onchain ownership of the whole endowment be moved to a 3 of 5 multisig plus timelock – that’s clearly a step back IMHO.