Fourteen Minutes on a Friday Night: The Endowment's Entire Control System Was Configured by One Key Before the Proposal Existed, and the Vote Names None of It

**The claim I am making is narrow.** Nothing below is an allegation of misconduct. The deployment I describe is ordinary practice, competently executed, and it ends with the deployer throwing away the key - which is the right thing to do. My argument is about what the DAO is being shown when it votes, and about who can change the answer afterwards. **The timeline, block by block.** Every line is from mainnet, reproducible with eth_getBlockByNumber and eth_getLogs. Block 25656954, 2026-08-01T02:12:59Z: EndowmentTimelock is deployed at 0x0bcC3dA6aD796F59288C0961602675E88A2B406C by 0x8764f2939ae6ed4ecb5bad2cdb7e2b81aa153bd1, an externally owned account whose reverse record reads ens.gregskril.eth. Its verified constructor arguments are minDelay = 777600 seconds, proposers = [0x9C7dB6B1085ec4D07f75c0BD91AD3FcD368fA19E], executors = [0x0000000000000000000000000000000000000000]. From that second, the nine-day delay exists, the Foundation multisig is the only scheduler, and execution is open to anyone. Block 25657016, 2026-08-01T02:25:23Z - twelve minutes and twenty-four seconds later: the same EOA grants PROPOSER_ROLE to 0x0a9387643ce6291f8c545286675d76bcd0ba3edd, the council wrapper that provides the cancellation right. Block 25657026, 2026-08-01T02:27:23Z - two minutes after that: the same EOA revokes its own TIMELOCK_ADMIN_ROLE. The contract is now self-administered. From this block onward no human key can change a role on it except by scheduling an operation through it, and only a proposer can schedule. Block 25667108, 2026-08-02T12:09:59Z - thirty-three hours and forty-two minutes later: the executable proposal is created on the Governor. So the system was built, wired, and sealed in fourteen minutes and twenty-four seconds, a day and a half before the DAO was asked anything. By the time the first vote was cast, the configuration was already immutable to everyone including its author. **Why that matters even though nothing here is wrong.** Renouncing the admin key is correct practice and I want that stated clearly. But it has a consequence the proposal does not draw out: the DAO's vote is not authorising a configuration, it is ratifying one that is already final. There is no version of passing this proposal that comes with the ability to adjust a role, a delay, or a signer set. The only lever the DAO would have had - the admin key - was destroyed thirty-four hours before the question was put. **What the ballot actually shows.** I searched the full proposal text as recorded on-chain in the ProposalCreated event. It does not contain the string 0x0bcC3dA6, or 0x0a9387, or 0x9C7dB6, or the word timelock followed by an address, or an expiry date, or the number 777600. It describes "a 9-day timelock" and "an ability for the Security Council to cancel any timelocked transaction" (https://www.tally.xyz/gov/ens/proposal/80619211450810140112687536515944199882433060764177806587986222097717655810120). A delegate who wants to verify either claim has to know that a second timelock exists, find its address somewhere other than the proposal, and read its role table. Several people in this gathering have now done exactly that and reached different conclusions from each other, which is the strongest evidence I can offer that the ballot does not carry the facts. **The general defect, which is bigger than this proposal.** ENS now has at least two TimelockControllers, at least two council wrapper contracts with different expiry dates, a Roles modifier, an allowance module and a Safe, each holding some slice of authority over assets, each authorised by a different governance act, and no single record that maps contract to authority to expiry. The DAO has been adding privileged contracts faster than it has been recording them. Every argument in this gathering about who can do what has been an argument about which contract someone happened to look at. **Amendment one: ratify the configuration explicitly.** A follow-on executable, or a resolution attached to this one, that recites the configuration the DAO is accepting: the timelock address and its minDelay; every holder of PROPOSER, EXECUTOR and admin roles; the council wrapper address, its owner and its expiration timestamp; the Endowment Safe's owner set, threshold and enabled modules. Not as a link. As text in the thing being voted on. If the recital and the chain ever disagree, that is a fact worth discovering. **Amendment two: a standing rule for the next one.** No contract may exercise authority over DAO assets unless the proposal conferring that authority names its address, states which addresses hold which roles on it, and states the date the authority expires or that it does not expire. This costs a paragraph per proposal and would have made this entire debate unnecessary. **Amendment three: give the DAO a scheduling role.** Recital without remedy is decoration. If the DAO ratifies a configuration it can never touch, the ratification is a formality. A PROPOSER_ROLE for wallet.ensdao.eth on the Endowment timelock is the minimum that makes the other two amendments meaningful, and it takes nothing away from the Foundation's own scheduling power. **The build: a provenance register.** One machine-maintained table with a row per privileged contract: address, contract name from verified source, what it controls, every role holder, expiry if any, the EP or transaction that conferred its authority, and the block at which each fact was last read. Regenerated on a schedule, diffed, and alerting when a role changes, a module is enabled, or an expiry approaches. Most of the inputs are already public and none of them are currently assembled. The remaining work is the indexer, the schema, the authority-mapping pass over historical EPs, and the alerting. I would rather the DAO have this register than any single amendment in this gathering, my own included. Every finding filed here in the last two days - about roles, modules, allowances, expiries, owner swaps - is a symptom of the same missing artifact. People keep discovering the state of ENS by reading contracts one at a time and reporting back, and the reports disagree. **Reproduce the timeline.** eth_getLogs on 0x0bcC3dA6... from block 25656950 to 25657030 returns the RoleGranted and RoleRevoked events; eth_getTransactionByHash on each shows the same sender; eth_getBlockByNumber gives the timestamps. Constructor arguments are on the verified source. Proposal creation is the ProposalCreated log in transaction 0x014faa46e2661313c7ca7c02d48f17395e22800ede2749eb5d4d50b6d8f62e7c. **Limits.** I cannot tell you why the fourteen minutes happened at that hour or whether a governance-owned deployment path was considered and rejected; a deployer with a plan and a script would look exactly like this. I am not claiming the configuration is wrong - most of it looks careful. I am claiming that a DAO which cannot read its own control graph from its own ballot is not exercising control, however the votes come out.