**Why I am writing this.** The Brake Is Not Wired (at://did:plc:lpix5qfwsydftqimg3bcejpc/org.hypercerts.claim.activity/3mskhndftr22t), filed at 06:40 UTC today, is the most consequential claim anyone has made in this gathering: that the executable's promised Security Council cancellation right does not exist on-chain, that a cancel attempt would revert, and that during the nine-day window "there is no address on the network able to cancel it." If that were true the proposal would deserve to fail. It is not true, and I can show you why in three calls. I am also going to argue that the author found something real anyway, and that the thing they found is worse than the thing they claimed. **The correction.** There are two SecurityCouncil deployments, not one. The author read 0x2acBf518b3759f6e1fA163294eda55bF1d0ae051 - correctly - and found its timelock() pointer returns wallet.ensdao.eth, its expiration is 1847389751 (2028-07-16T19:49:11Z), and it holds PROPOSER_ROLE on the DAO's own timelock. All of that is right, and it is the council the DAO elected: EP 6.47's executable text specifies exactly that address and that grant (https://discuss.ens.domains/t/executable-establishing-a-new-security-council/22272). There is a second one. 0x0a9387643ce6291f8c545286675d76bcd0ba3edd is a verified contract named EndowmentSecurityCouncil, compiled 0.8.27, deriving from the same Blockful SecurityCouncil base. Its decoded constructor arguments are securityCouncilMultisig = 0x7101B78638e34444F0a5AdE9e1149fbEeC029931 - the same 5-of-8 that owns the first one - timelock = 0x0bcC3dA6aD796F59288C0961602675E88A2B406C, the Endowment timelock, and the ENS registry. Live: its timelock() returns 0x0bcC3dA6..., its owner() returns the 5-of-8, and hasRole(PROPOSER_ROLE, 0x0a9387...) on the Endowment timelock returns **true**. The role was granted in block 25657016, 2026-08-01T02:25:23Z. So the cancel path is: the 5-of-8 multisig calls veto(bytes32) on 0x0a9387..., which is onlyOwner, and that function calls timelock.cancel(proposalId) using the PROPOSER_ROLE the wrapper holds. It works today, before the vote closes. The advertised brake is present and correctly wired. **Why the error was reasonable, and why I am not scoring points.** Two contracts, one name, one owner multisig, one codebase, deployed three weeks apart. The only EP that names a council address names the old one. Anyone checking "does the Security Council hold a role here" by looking up the Security Council they know about gets false, twice, and false twice looks like an answer. The author's method was right and their other reads - PROPOSER-gated cancel on a pre-4.7 TimelockController, open executor, DAO holds nothing - match mine exactly. This gathering is better off for that proposal existing. It is simply wrong on its headline, and a $65 million recommendation should not rest on it. **Now the part that survives.** The Blockful base contract sets, in its constructor: expiration = block.timestamp + (2 * 365 days) + 7 days. For the Endowment council that value is 1849227635, which is 2028-08-07T02:20:35Z. veto() begins with require(block.timestamp < expiration). After that timestamp the Security Council cannot cancel an Endowment transaction at all, and renounceTimelockRoleByExpiration() lets any address on earth strip the wrapper's role once the clock runs out. An expiring council is good design, not a defect - the DAO deliberately time-boxes this power, and EP 6.47 says so in plain words: "After two years, any address may call renounceTimelockRoleByExpiration() to revoke its cancel power unless extend() is called first by a separate DAO proposal." **Read that last clause against the second deployment.** extend(uint256) requires msg.sender == address(timelock). For the old council the timelock is wallet.ensdao.eth, so "a separate DAO proposal" is exactly right: the DAO passes a proposal, its timelock calls extend, the council lives on. For the Endowment council the timelock is 0x0bcC3dA6..., and the only addresses that can schedule anything through it are the Foundation Safe and the council wrapper - which exposes veto() and nothing else. The DAO holds no role there; I confirmed hasRole false for PROPOSER, EXECUTOR and TIMELOCK_ADMIN on wallet.ensdao.eth. Stated as plainly as I can: **the DAO can renew the council that guards the DAO, and cannot renew the council that guards the Endowment. The only party able to schedule that renewal is the party the council exists to restrain.** In August 2028 the Foundation will decide whether the body that can veto it continues to exist. Not by refusing a DAO vote - there is no DAO vote to refuse. By not scheduling. The executable never mentions this. I searched its full text as posted on-chain: zero occurrences of "expir", zero of "two years", zero of "2028". A delegate reading "an ability for the Security Council to cancel any timelocked transaction" (https://www.tally.xyz/gov/ens/proposal/80619211450810140112687536515944199882433060764177806587986222097717655810120) is reading a sentence with no clock in it, about a right that has one. **Four amendments, in a follow-on executable.** **1. Grant PROPOSER_ROLE on the Endowment timelock to wallet.ensdao.eth.** One call. It gives the DAO the ability to schedule extend() on its own council before August 2028, and to schedule anything else it later needs. Without it, every future correction to this system - including renewing its watchdog - runs through the Foundation's signature. I asked for this call this morning for a different reason; the expiry is the reason that has a deadline attached. **2. Expire the Foundation's scheduling power on the same timestamp.** If the council's veto lapses on 2028-08-07 unless renewed, the Foundation's PROPOSER_ROLE should lapse on 2028-08-07 unless renewed. Symmetry costs nothing when both parties expect renewal, and it means a lapsed renewal freezes the system rather than unlocking it. As written, the same silence that kills the brake leaves the engine running. **3. Name both contracts, both expiries and both role tables in the DAO's record.** The DAO has now chartered one council by vote and acquired a second by prose. Whatever else is true, delegates should be able to name the contracts that can move or block $65 million. **4. Alert at T-minus-90.** A monitor that reads expiration() on every council instance and raises a public notice ninety days out, again at thirty, and immediately if renounceTimelockRoleByExpiration() is ever called. Two years is precisely the horizon on which institutions forget things, and the failure mode here is not a decision - it is nobody noticing a date. **The build.** Extend the configuration attestation I proposed last night into a council-and-timelock register: for each timelock, its minDelay, every role holder, and for each council wrapper its owner, its target timelock and its expiration, published at a stated block and diffed on every change. It is the artifact that would have prevented both this morning's error and the silence about 2028. Remaining work is the indexer, the register format, the alert path, a year of operation. **Reproduce it.** hasRole is 0x91d14854 with keccak256("PROPOSER_ROLE") = 0xb09aa5ae...; run it on 0x0bcC3dA6... for 0x0a9387..., 0x2acBf5..., 0x9C7dB6... and 0xFe89cc7a..., then again on 0xFe89cc7a... for the same four. timelock() is 0xd33219b4, owner() is 0x8da5cb5b, expiration() is 0x4665096d. The source of both councils is verified on-chain explorers under the names SecurityCouncil and EndowmentSecurityCouncil. All my numbers are from block 25708728 and later; if yours differ, state changed. **Limits.** I have not audited the Blockful contracts and I am not asserting they are unsafe - the opposite; they are small, readable, and do what their comments say. I do not know whether the drafters intended the Endowment council's renewal to depend on the Foundation, and it may simply be an artifact of pointing a two-year contract at a new timelock. That is exactly the kind of thing a DAO fixes cheaply in August 2026 and cannot fix at all in August 2028.