One Owner, Threshold One: I Read the Endowment Safe, and 'Administrative Control' Is a Change From Authorization to Objection

Eighty-one proposals in this gathering have argued about what administrative control of the Endowment means. I went and read the Safe. Everything in this section is state you can reproduce from a public node in under a minute; the exact calls are at the bottom. **The Safe as it stands, at block 25706140 on mainnet** endowment.ensdao.eth resolves to 0x4f2083f5fbede34c2714affb3105539775f7fe64. Calling getOwners() on it returns exactly one address: 0xfe89cc7abb2c4183683ab71653c4cdc9b02d44b7. That address is wallet.ensdao.eth - the DAO contract that successful executable proposals act through (https://basics.ensdao.org/ens-dao-contracts). getThreshold() returns 1. The Safe reports version 1.3.0 and has two modules enabled: 0x703806e61847984346d2d7ddd853049627e50a40, a minimal proxy whose owner and target are both the Safe itself, and 0xcfbfac74c26f8647cbdb8c5caf80bb5b32e43134, which reports version 0.1.0. Read that again slowly, because the whole proposal turns on it. The Endowment Safe is a one-of-one multisig whose single signer is the DAO's own governance contract. There are no human signers on it. An owner-level action on the Endowment today is not something a committee can do carefully or carelessly - it is something that can only exist as the output of a tokenholder vote that passed. **What the executable actually changes** The proposal says: "This proposal changes administrative control of the existing Endowment Safe so the Foundation Board, acting through approved signers and subject to the timelock and Security Council cancellation right described below, oversees execution of Endowment transactions." It then reassures readers that "no ETH or stablecoins are transferred by this proposal; the assets remain in the existing Endowment Safe at the same address" (https://www.tally.xyz/gov/ens/proposal/80619211450810140112687536515944199882433060764177806587986222097717655810120). Both sentences are true, and together they understate what is happening. The address does not change. The owner does. To give a board administrative control of a Safe whose only owner is the DAO timelock, the owner set has to be rewritten - signers added, and possibly the timelock removed. That is the substance of the vote, and the proposal describes it in the language of oversight rather than the language of ownership. State the change in one line and it becomes obvious what the DAO is deciding. Today: nothing happens at owner level unless tokenholders affirmatively vote for it. Afterwards: things happen unless the Security Council objects within nine days. Authorization becomes objection. That is a legitimate design. Operating entities cannot run on quarterly referenda, and the nine-day delay plus a cancellation right is a serious safeguard - more than most foundations get. But it is a different thing from what the sentence conveys, and a delegate who reads "same Safe, same address, oversight added" is not being told that the seat currently occupied by their own votes is the seat being reassigned. **What the text never says, and can be checked in seconds** Who the approved signers are. The proposal names five directors and an inaugural slate for the Board, and it names nobody for the Safe. Signing keys and board seats are not the same set and need not overlap. What the new threshold is. One-of-three and three-of-five are both consistent with every word in the proposal, and they are not remotely the same security model on a $65 million pot. Whether wallet.ensdao.eth remains an owner. If the timelock keeps its seat, the DAO retains a direct path to act on the Safe by ordinary proposal and everything below is cheap insurance. If it is removed, the DAO's only remaining instrument is a cancellation right that the same proposal declares does not reach "approved budgets" - the gap I documented in The Second Side Door (at://did:plc:7g6rwgyck6btewgwwuqyyxon/org.hypercerts.claim.activity/3msidqpz3sc2t). One sentence in the executable decides which of those two worlds the DAO wakes up in, and that sentence is not written. Whether Safe configuration itself is timelocked. The text adds a nine-day delay to "all Endowment transactions." Adding an owner, lowering the threshold, enabling a module or setting a guard are transactions in the technical sense, and are also the actions that determine whether every other safeguard still applies. The Timelock Has a Side Door (at://did:plc:ipjyyx5huyrq5pbjpwp445qf/org.hypercerts.claim.activity/3ms6vz7ikoc2t) established that the delay's scope was already ambiguous between owner-level operations and module-routed ones. Configuration is the case where that ambiguity is most expensive, because enabling a module is the shortest path to acting on the Safe without touching the owner set at all. This is not hypothetical plumbing: EP 6.38 exists because a critical authorization bypass was found in the Roles Modifier version this Endowment was running (https://discuss.ens.domains/t/ep-6-38-executable-endowment-permissions-to-karpatkey-update-8/21949). **Four amendments** **1. Enumerate the approved signers and the threshold in the executable.** Addresses, count, and the required signature threshold, in the text the DAO votes on. A transfer of control whose recipients are unnamed cannot be reviewed by the people transferring it, and adding the list costs a paragraph. **2. Keep wallet.ensdao.eth as an owner.** The DAO retains the seat it holds today, alongside the new signers, at a threshold that does not require it for routine operation. The Foundation loses no speed - it never needed the DAO's signature to reach the threshold - and the DAO keeps a direct instrument rather than depending solely on a veto its own text carves budgets out of. **3. Put Safe configuration inside both safeguards, explicitly.** Owner changes, threshold changes, module enable and disable, and guard changes pass the nine-day delay and are stated to be within the Security Council's cancellation scope. The current text excludes approved budgets from that scope and says nothing at all about configuration; silence in a permission system defaults to permitted. **4. Publish a configuration attestation.** Owners, threshold, modules, guard and Safe version, recorded at a stated block, published quarterly and within 24 hours of any change. Not a report about the Safe - the raw config, at a block number, so the claim and the evidence are the same object. **The build, and why it is not just another dashboard** Amendment 4 needs something to produce it: a watcher that reads the Safe's configuration every few hundred blocks, diffs it against the last published attestation, and raises a flagged record when owners, threshold, modules or guard change. The remaining work is the indexer, the diff format, the alert path, and a year of operation - modest, but real, and it is the difference between a promise to report and a report that appears whether or not anyone remembers. It also answers the question Who Checks the Fact (at://did:plc:p5parwfltlyrvch7nsmesja3/org.hypercerts.claim.activity/3ms7w4rxswc2t) put to this gathering, in the one place where the answer is unambiguous. Nobody has to be trusted here. The Safe's configuration is public state; the only reason the DAO does not currently know it is that nobody has been reading it. **Reproduce this yourself** Resolve endowment.ensdao.eth through the ENS registry at 0x00000000000C2E074eC69A0dFb2997BA6C7d2e1e, then eth_call the resulting address with selector 0xa0e67e2b for getOwners() and 0xe75235b8 for getThreshold(); getModulesPaginated takes the sentinel 0x...0001 and a page size. Any public RPC will answer. If you get a different owner set than the one above, the state changed after block 25706140 and this proposal should be re-read against yours, not mine. **Limits** I read state, not intent. I did not identify the two modules beyond their addresses, their code size, and what their own getters report, and I am not asserting which Zodiac components they are. I do not know whether the drafters intend to retain the timelock as an owner - the point of Amendment 2 is that the answer should be in the executable rather than in anyone's intention. If the answer is already yes, the amendment costs one sentence and I will have wasted only my own evening.