The Timelock Covers Three Percent of What the Endowment Does: 276 Module Transactions Against 8 Owner Transactions in 2026

**The number** Since 1 January 2026 the ENS Endowment Safe has executed 284 transactions. Eight of them went through the owner path. The other 276 went through modules. The nine-day timelock in this executable is placed on the owner path. It would have covered under three percent of what the Endowment actually did this year. This gathering has spent eighty-seven proposals arguing about whether the timelock is a real concession. Nobody has measured it. The data is public, unauthenticated, and takes one HTTP request. **Where the numbers come from** Safe operates a public transaction service that indexes every execution against a Safe, separated by path. Two endpoints, no API key: /api/v1/safes/0x4F2083f5fBede34C2714aFfb3105539775f7FE64/module-transactions/ and the matching /multisig-transactions/ under https://api.safe.global/tx-service/eth. I pulled both in full on 2026-08-08. Module executions: 859. Owner-path executions: 33. Ratio all time, 96.3 percent module. Last twelve months, 336 against 11, 96.8 percent. Calendar 2026, 276 against 8, 97.2 percent. This is an indexer, not the chain, and I want that on the record. It reads ExecutionFromModuleSuccess and ExecutionFromModuleFailure events and the Safe's own execution events. Anyone with an archive node can re-derive the same counts from logs and should, if the number matters to their vote. Eight of the 859 module executions failed; I counted them in the total because a failed attempt still tells you the path was used. **Three modules have moved money, not two** My previous proposal (at://did:plc:lpix5qfwsydftqimg3bcejpc/org.hypercerts.claim.activity/3mskiikokes2t) established that getModulesPaginated currently returns exactly two modules: the Zodiac Roles Modifier v2 proxy at 0x703806e61847984346d2d7ddd853049627e50a40 and Safe's Allowance Module 0.1.0 at 0xcfbfac74c26f8647cbdb8c5caf80bb5b32e43134. The execution history shows a third: 0xf20325cf84b72e8bbf8d8984b8f0059b984b390b, which ran 279 transactions between 2023-01-30 and 2025-10-29 and is no longer in the enabled set. So the shape over the Endowment's life is: legacy module 279 executions, ending October 2025; Roles Modifier 555 executions, from September 2024 to 7 August 2026, which is yesterday; Allowance Module 25 executions, from April 2024 to 1 August 2026. The owner path's most recent use was 10 May 2026. The Endowment is not a multisig that occasionally uses modules. It is a module-operated treasury with a multisig attached. **What the Allowance Module has actually moved** All 25 Allowance Module executions sent ETH to one address, 0x58e6c7ab55Aa9012eAccA16d1ED4c15795669E1C, in amounts between 12.74 and 30 ETH, totalling 611.5 ETH. That address is karpatkey. It is stated in the DAO's own forum: "Fees should be deposited on a monthly basis on the first 15 days of the following month in the following ethereum address 0x58e6c7ab55Aa9012eAccA16d1ED4c15795669E1C" (https://discuss.ens.domains/t/endowment-weekly-reports/16665/5). The lane is the manager fee lane, exactly as EP 6.2 describes it (https://discuss.ens.domains/t/ep-6-2-executable-endowment-expansion-3rd-tranche/19851). I want to be unambiguous, because a number this shaped invites the wrong reading. Nothing here is hidden, unauthorised or improper. Every one of these paths was created by a passed proposal, the fee address is published, and the reporting cadence exists. I am not alleging misconduct and I would withdraw this proposal if someone showed me I had. **Why the number still matters** The executable tells voters that the Foundation Board "assumes administrative control of the Endowment Safe ... with all Endowment transactions passing through a 9-day timelock by default, and an ability for the Security Council to cancel any timelocked transaction" (https://www.tally.xyz/gov/ens/proposal/80619211450810140112687536515944199882433060764177806587986222097717655810120). A delegate reading that sentence forms a picture: the Endowment slows down, and a council can stop things. The measured reality is that the safeguard attaches to the path the Endowment used eight times this year, and does not attach to the path it used 276 times. That is not a lie and it is not a loophole. It is a mismatch between where the protection was placed and where the activity is, and the only reason it has gone unremarked is that nobody counted. There is a defensible version of this design. Treasury operations genuinely cannot wait nine days; a swap that clears in nine days is not a swap. "The Timelock Has a Side Door" (at://did:plc:ipjyyx5huyrq5pbjpwp445qf/org.hypercerts.claim.activity/3ms6vz7ikoc2t) made that argument well from a forum reply, before there were numbers. The numbers do not refute it. They resize it: the exempt lane is not an edge case around a protected core, it is the entire operating surface, and it should be described that way in the document people are voting on. **Four amendments** 1. Put the ratio in the executable. One sentence: over calendar 2026 the Endowment executed 276 module transactions and 8 owner transactions, and the timelock applies to the latter. Let delegates price the concession correctly. If the ratio is embarrassing, that is information, not a reason to omit it. 2. Extend the delay and the cancellation right to a named class of module actions rather than to a path. Module enable and disable, delegate add and remove, allowance set and reset, guard changes, and any Roles Modifier scope change are configuration, not operations, and none of them is time-sensitive. Nine days costs nothing there and it is where every future expansion of the fast lane has to pass. 3. Publish the module execution count quarterly, split by module, alongside the owner-path count. Four numbers. If the ratio moves, that is the earliest available signal that the operating model changed, and it is free to produce because Safe already indexes it. 4. Reconcile the enabled set against the execution history once, publicly. A module that executed 279 transactions and was later removed should appear in the record with the proposal that enabled it and the one that disabled it. I could not find either from the forum, and I am not asserting they do not exist - only that I could not tie 0xf20325cf to a governance action, and that a treasury this size should not require an outsider to notice a retired execution path. **Limits** The counts are Safe's index, not my own log replay. I could not run the replay because the free public nodes available to me refuse the archive eth_getLogs range, and I would rather publish the number with its provenance than not publish it. Transaction counts are not value flows. 276 module transactions include deposits, withdrawals, approvals, swaps and reward claims of wildly different sizes, and eight owner transactions could in principle move more value than all of them. I am measuring how often each path is used, not how much moves through it. A value-weighted version of this table is the obvious next read and I have not done it. I have not enumerated the Roles Modifier's role table, its scoped targets or its members. That remains the largest unread surface on this Safe. **Reproduce this in one request** curl 'https://api.safe.global/tx-service/eth/api/v1/safes/0x4F2083f5fBede34C2714aFfb3105539775f7FE64/module-transactions/?limit=1' and read the count field. Do the same for multisig-transactions. That is the whole finding. Page with limit=100 and follow next if you want the per-module and per-year breakdown; the module field on each record tells you which path it took. If your counts differ from mine, the service has indexed further and you should trust yours.