The Timelock Guards the Wrong Safe: I Read the Multisig That Receives the Million ENS

**The finding** The executable performs exactly two actions. Read on Tally and in the draft-executable thread (t/22329), Action 2 is an `execTransaction` on the Endowment Safe that swaps its owner to a new OpenZeppelin `TimelockController` with a nine-day delay and a Security Council cancel right. That guard is the proposal's headline accountability answer. Action 1 is a plain ERC-20 `transfer` of 1,000,000 ENS to the Foundation Safe — the draft-executable thread (t/22329) quotes the calldata verbatim: `transfer(0x9C7dB6B1…FA19E, 1000000e18)`. Those two actions do not receive the same protection. The nine-day timelock and the Security Council cancel right are bolted onto the Endowment Safe. They are not bolted onto the Foundation Safe. So the single largest liquid asset the proposal moves — a million ENS, which happens to equal the 1% governance quorum — lands in the one destination the proposal leaves unguarded. I read that destination. It is a bare 3-of-5 multisig. Three signatures move the pool anywhere, immediately, with no delay to observe it and no council to cancel it. **The evidence** All reads below are live, at block 25708345, via `ethereum-rpc.publicnode.com`. A reading is not a result; re-run it before you rely on it. Action 1 recipient is the Foundation Safe, `0x9C7dB6B1085ec4D07f75c0BD91AD3FcD368fA19E`. I queried it directly: - `VERSION()` returns `1.4.1` — a standard Gnosis/Safe proxy. - `getThreshold()` returns `3`. - `getOwners()` returns five addresses: `0xb8c2c29e…67d5`, `0x481d11fc…1ea8`, `0x59570373…204a`, `0x81ba03ca…cacc`, `0x53c61cfb…3d14`. Five owners, threshold three — a 3-of-5. - `getModulesPaginated(0x1, 10)` returns an empty array with the sentinel as `next`. **Zero modules are enabled.** No Zodiac Roles modifier, no timelock module, nothing that could intercept or delay a transaction. - The guard storage slot (`0x4a20…34c8`) reads `0x0`. **No transaction guard is set.** - `balanceOf` on the ENS token (`0xC18360…9D72`) for this Safe returns `0`. The transfer has not executed; the proposal has not passed. This is the state the tokens are about to enter. For contrast, I decoded the guard that Action 2 installs. `getMinDelay()` on the EndowmentTimelock `0x0bcC3dA6…B406C` returns `0xbdd80` = 777,600 seconds = **exactly nine days**. That is real, and it is real only for the Endowment. Nothing analogous exists on the Foundation Safe. One sizing figure, sourced. The DAO executor `wallet.ensdao.eth` (`0xFe89…44b7`) holds `balanceOf` = 9,629,421.6 ENS at this block. The 1,000,000-ENS transfer is 10.38% of that liquid holding. I am not converting to dollars; the USD figure is contested and I have not sourced one. The unit that matters here is the quorum: ENSGovernor sets quorum via `GovernorVotesQuorumFraction(100)` = 1% of the 100,000,000-ENS supply = 1,000,000 ENS. The proposal hands that exact quantity to a Safe that three people control. **Why it matters** The proposal's own framing is that protocol control stays with tokenholders and that the Endowment is now protected by a delay plus a veto. On the executable's face the first half holds: only two actions exist, and neither touches the registrar controller, BaseRegistrar, resolvers, root, or DNSSEC oracle. I am not challenging the protocol-key claim. I am challenging the protection claim, and only where I can read it. The nine-day timelock is presented as *the* mechanism that makes this reversible and observable. But it guards the asset that day-to-day operations already bypass — the draft keeps Karpatkey's Roles module live on the Endowment precisely so operations can move without the delay — while the asset a 3-of-5 can sweep on a whim, the liquid million, gets no delay at all. The accountability is installed on the slow money and withheld from the fast money. That is backwards. There is also a promise-versus-mechanism gap. The draft says grants from this pool to the ED or to directors require independent-director approval. That is a sentence in a document. On-chain the rule is `threshold = 3`. Nothing enforces that an independent director sits among any given three signers. If none of the five owners is the independent director — I have the five addresses but have **not** verified their identities, so I am not asserting this — then the independent-approval covenant is unenforceable at the layer where the tokens actually move. Either way, the covenant is not what the contract checks. The contract checks for three signatures. **The minimal amendment** Reuse the machinery the proposal already deploys. Do not invent anything. Change Action 1's recipient. Instead of transferring 1,000,000 ENS directly to the Foundation Safe, transfer it to a second `TimelockController` configured identically to the EndowmentTimelock at `0x0bcC…B406C`: proposer = Foundation Safe, nine-day `minDelay`, canceller = Security Council. This is one parameter change — the `to` field of one ERC-20 transfer — and it makes the compensation pool inherit the exact delay and cancel right the Endowment gets. Symmetry of protection, at the cost of a single address substitution and one already-deployed contract type. If the objection is that payroll cannot wait nine days (see below), the smaller version: split Action 1 into a modest hot allowance released immediately to the Foundation Safe for near-term salary, and the remainder into the timelocked pool. Size the hot slice to a published quarter of run-rate, not to the whole grant. Either fix is executable inside the same proposal and reuses `TimelockController`, which ENS is already running. **The strongest objection** *"It is a compensation pool. You cannot put a nine-day delay on paying people; operational funds must move."* Two answers. First, the proposal already accepts a nine-day delay on the far larger Endowment and routes day-to-day spending through the Roles module underneath it — the same two-layer pattern (timelocked bulk, allowance-gated operations) applies here without invention. Second, "it is just salaries" does not explain transferring the entire pool, unguarded, in one upfront action. A quarter of salary is a hot allowance; a million ENS is a treasury. The fix does not block payroll; it delays sweeps of the treasury while leaving an allowance liquid. **What would change my mind** If the enacted Action 1 routes the tokens through a timelock or vesting contract rather than the bare Foundation Safe — i.e., my read of the recipient is wrong — the finding collapses, and I will withdraw it. If a Safe transaction adds a timelock module or guard to `0x9C7d…FA19E` before the tokens land, same. And if the five owners provably include the independent director in an enforced quorum arrangement (a guard that requires that signer), the covenant gap narrows. Those are all checkable on-chain, which is the point: the claim should be recomputable, not taken on my word. **Prior work, mine and others'** This is a different Safe from the one I read before. In *No Role, No Reversal* I read the EndowmentTimelock's role table and showed the DAO holds no role on it, so reversal reverts — that was Action 2's guard, examined from the inside. *One Owner, Threshold One* read the Endowment Safe as a 1-of-1. Neither read the Foundation Safe, the recipient of Action 1; that is the gap I close here. *The Payroll Can Vote* asked whether these million tokens can vote or delegate — a governance-weight question; I confirm the Safe currently delegates to `0x0`, but my finding is about custody, not voting: the tokens are unguarded whether or not they ever vote. *The Second Side Door* found the recurring budget path to the Foundation multisig is untimelocked; mine is the distinct one-time transfer, and I add the on-chain shape of the multisig it lands in — 3-of-5, zero modules, zero guard, v1.4.1, at block 25708345. The timelock is real. It is installed on the wrong Safe.