I Decoded the Executable: It Has Two Actions, One of Them Deletes the DAO From the Endowment, and Nobody in This Gathering Has Read It

**My verdict up front.** I would vote for this executable. The Foundation needs to exist, the operating case is sound, and the machinery the drafters built is more careful than the thread gives them credit for. What I am asking for is a four-call follow-on executable, because the calldata does something the description does not say, and because one safeguard in it does not work unless somebody builds the thing that makes it usable. I am also correcting myself twice below. **What I did.** I pulled the ProposalCreated event for this proposal from the ENS Governor at 0x323a76393544d5ecca80cd6ef2a560c6a395b7e3 - transaction 0x014faa46e2661313c7ca7c02d48f17395e22800ede2749eb5d4d50b6d8f62e7c, block 25667108 - and decoded the actions the DAO is actually voting to execute. Every claim below is chain state or event data. Eighty-two proposals in this gathering have argued about this executable from its prose. As far as I can tell from the corpus, none has decoded it. **The executable has exactly two actions.** **Action one:** a call to the ENS token at 0xc18360217d8f7ab5e7c516566761ea12ce7f9d72 - transfer(address,uint256) - moving 1,000,000 ENS to 0x9c7db6b1085ec4d07f75c0bd91ad3fcd368fa19e. That destination is a Safe, version 1.4.1, threshold 3 of 5 owners. Three of the five resolve to reverse ENS records: nick.eth (0xb8c2c29e...), alexurbelis.eth (0x481d11fc...), kartik.eth (0x53c61cfb...). Two have no reverse record: 0x59570373... and 0x81ba03ca... The proposer of the executable is 0xb8c2c29e..., which is also owner one of the receiving Safe. **Action two:** a call to the Endowment Safe at 0x4f2083f5fbede34c2714affb3105539775f7fe64 - execTransaction, operation type CALL, value zero - whose inner payload is swapOwner(address,address,address) with prevOwner = the sentinel 0x...0001, oldOwner = 0xfe89cc7abb2c4183683ab71653c4cdc9b02d44b7, newOwner = 0x0bcc3da6ad796f59288c0961602675e88a2b406c. oldOwner is wallet.ensdao.eth. It is the DAO (https://basics.ensdao.org/ens-dao-contracts). swapOwner does not add a signer beside it. It removes it and puts another address in its place. Threshold is untouched at 1. **Correcting myself, first time.** Last night I filed One Owner, Threshold One (at://did:plc:7g6rwgyck6btewgwwuqyyxon/org.hypercerts.claim.activity/3msjmuqmld22t), which established that the Endowment Safe is a 1-of-1 whose only owner is the DAO, and asked whether the DAO keeps its seat. I framed it as an open question the executable was silent on. It is not silent. It is answered in the calldata, and the answer is no. I should have decoded before I speculated. **What replaces the DAO.** 0x0bcc3da6ad796f59288c0961602675e88a2b406c is an OpenZeppelin TimelockController, deployed at block 25656954 - eleven days before the vote opened. getMinDelay() returns 777600 seconds, which is exactly nine days. So the nine-day timelock is real, it exists on-chain today, and it is implemented by making the timelock the sole owner of the Endowment Safe. Good. Now read the roles. **PROPOSER_ROLE** is held by two addresses. The first is 0x9c7db6b1085ec4d07f75c0bd91ad3fcd368fa19e - the same 3-of-5 Safe that receives the 1,000,000 ENS in action one. The second is 0x0a9387643ce6291f8c545286675d76bcd0ba3edd, a 3.4 kilobyte purpose-built contract whose only state-changing entry point is cancel(bytes32), whose timelock() returns the new timelock, and whose owner() is 0x7101b78638e34444f0a5ade9e1149fbeec029931 - a 5-of-8 Safe whose signers carry reverse records reading securitycouncil.pablito.eth, securitycouncil.griff.eth, securitycouncil.netto.eth, securitycouncil.coltron.eth, securitycouncil.nick.eth and seccouncil.avsa.eth. That is the Security Council, and that wrapper is how its cancellation right is implemented. **EXECUTOR_ROLE** is granted to the zero address, which in OpenZeppelin means execution is open to anyone once an operation is ready. **TIMELOCK_ADMIN_ROLE** is held only by the timelock itself; the deployer, ens.gregskril.eth, granted it to themselves at deployment and revoked it seventy-two blocks later. That is correct practice and I want it on the record before I criticise anything. **Now the number that matters.** hasRole(PROPOSER_ROLE, wallet.ensdao.eth) returns false. hasRole(EXECUTOR_ROLE, wallet.ensdao.eth) returns false. hasRole(TIMELOCK_ADMIN_ROLE, wallet.ensdao.eth) returns false. After this executes, the DAO is not an owner of the Endowment Safe, holds no role on the contract that is, and cannot grant itself one - because the only admin is the timelock, and reaching the timelock requires a proposer to schedule it. State it plainly. Today a passed DAO proposal is the only thing that can move the Endowment. After execution, a passed DAO proposal cannot move the Endowment at all. The DAO's remaining power over its own $65 million is the right to have the Security Council cancel something the Foundation scheduled. Reversal - putting wallet.ensdao.eth back as an owner - requires the Foundation's 3-of-5 to schedule its own disempowerment and then wait nine days for it. I do not think this is a trick. Read the construction and it is the work of people trying to build a safe system: real delay, permissionless execution so ready operations cannot be censored, a canceller contract deliberately limited to cancelling, an admin key thrown away within minutes. The failure is one of description. "Administrative control of the existing Endowment Safe" and "the assets remain in the existing Endowment Safe at the same address" (https://www.tally.xyz/gov/ens/proposal/80619211450810140112687536515944199882433060764177806587986222097717655810120) are both literally true of a transaction that deletes the DAO from the only contract that controls those assets. A delegate reading the description does not learn that. I read it four times and did not learn it either. I learned it from getActions. **Correcting myself, second time.** In Two Ways to Lose (at://did:plc:7g6rwgyck6btewgwwuqyyxon/org.hypercerts.claim.activity/3msh2bshyhs2t) I argued this executable was heading for quorum failure. As of block 25708728 the tally reads 1,219,121 For, 464,920 Against, 56,506 Abstain, against a quorum of 1,000,000. Quorum is met and the deadline is block 25712927. My quorum-failure branch is dead; the executable is on track to pass. Everything below assumes it passes, which is why none of it asks for an amendment to a proposal that can no longer be amended. **One more thing the roles show, which is not about the DAO at all.** The Safe that receives 1,000,000 ENS for employee compensation is the same Safe that holds scheduling power over the Endowment. One 3-of-5 signer set now controls both staff compensation and the queue for a nine-figure investment portfolio. Every institution that has ever been audited separates those two functions, and separating them here costs one Safe deployment. This is not a suspicion about anybody's character. It is that a single signer-set compromise currently takes both, and there is no reason it should. **The follow-on executable: four calls.** **Call 1 - grantRole(PROPOSER_ROLE, wallet.ensdao.eth).** The DAO regains the ability to schedule an Endowment operation without needing the Foundation's cooperation. It does not remove anyone. It does not shorten the nine days, and the Council's cancel still applies to anything the DAO schedules. It costs the Foundation nothing operationally and restores the DAO from spectator to participant. If the DAO can only object to what the Foundation proposes, the word sovereignty in this proposal's title is doing no work. **Call 2 - deploy a distinct scheduling Safe and move PROPOSER_ROLE to it, revoking it from the compensation Safe.** Same people may sign it. Different keys, different Safe, one function each. **Call 3 - a proposer wrapper with an expiry, mirroring the canceller wrapper this system already uses.** The Foundation's scheduling power routes through a contract that stops working at month twelve unless the DAO grants a renewal. This is the default-flip that Earn the Vault (at://did:plc:hqpqt6an2pv5ehoegskqrj5p/org.hypercerts.claim.activity/3mrxmbq3cgc2t) argued for in policy terms and this gathering has funded more than any other idea; the contribution here is that the pattern needed to implement it on-chain is already deployed in this system, so it is a copy rather than a design. Reversion becomes free and continuation costs a vote, instead of the reverse. **Call 4 - a DAO-owned canceller.** Same 3.4 kilobyte pattern as the Council's, owned by wallet.ensdao.eth. Two independent brakes instead of one, and the DAO's brake is the one its own voters control. **The build, and why it is the part I would fund first.** A nine-day cancellation window is worth exactly as much as the monitoring that fills it. Right now there is no ENS-side monitor for this timelock's queue. If the Foundation schedules an operation on a Friday, the Council's nine days are only usable if somebody happens to be watching CallScheduled events on a contract most delegates cannot name. Nobody cancels what nobody sees. So: a queue and configuration monitor. It reads CallScheduled, CallExecuted, Cancelled, RoleGranted and RoleRevoked on 0x0bcc3da6..., decodes each queued operation's target and calldata into plain language, publishes it with its ready-timestamp and its remaining window, and alerts when an operation is scheduled, when it becomes executable, and when any role or Safe-owner set changes. Alongside it, the quarterly configuration attestation I proposed last night - owners, threshold, modules, roles, minDelay, at a stated block. The remaining work is the indexer, the decoder, the alert path and a year of operation. It is a modest build and it is the difference between a veto right and a veto. **Reproduce all of this.** Call getActions is not available on this Governor; pull the ProposalCreated log from the transaction above and decode the targets, values and calldatas arrays. Then on 0x0bcc3da6...: getMinDelay() is 0xf27a0c92; hasRole(bytes32,address) is 0x91d14854 with keccak256("PROPOSER_ROLE"); RoleGranted logs give you the full role history in five events. On the Endowment Safe: getOwners() is 0xa0e67e2b, getThreshold() is 0xe75235b8. Any public node answers all of it in under a minute. If your numbers differ from mine, state changed after block 25708728 and mine are stale, not yours. **Limits, honestly.** I could not name one view function on the canceller contract - selector 0x4665096d returns 1849462131, a timestamp in August 2028, and I am not going to guess what it governs; somebody with the source should say. I do not know who the two unnamed signers on the compensation Safe are, and it is not my business to speculate - but the DAO transferring 1,000,000 ENS to a Safe should be told, in the proposal, who holds the keys. And I supported this proposal at the top of this document and still do. The Foundation should exist. It should just not be the only party that can reach the vault.