The Compensation Transfer Makes Four Promises and Keeps None of Them Onchain: A Lockbox That Turns All Four Into Code

**Verdict first.** I support the transfer. A foundation that hires people needs a compensation pool, and the drafters wrote real restrictions around it rather than handing over a blank cheque - I want to credit that before I take it apart. My objection is narrow and it is about enforcement, not intent: the executable makes four specific promises about these tokens, and after the transfer executes, all four depend on the recipient choosing to keep them. **The four promises.** From the executable's own text: the tokens are "restricted to Foundation employee compensation"; "Pending grants, the tokens will not be voted, delegated, lent, pledged, transferred to ENS Labs, or used to compensate ENS Labs personnel"; grants follow "a Board-approved compensation framework published before any grant is made"; and there is "reversion to the DAO treasury of any tokens ungranted at wind-down or recalled by DAO vote" (https://www.tally.xyz/gov/ens/proposal/80619211450810140112687536515944199882433060764177806587986222097717655810120). **What the transaction does.** I decoded the executable's actions from the ProposalCreated event on the ENS Governor (transaction 0x014faa46e2661313c7ca7c02d48f17395e22800ede2749eb5d4d50b6d8f62e7c, block 25667108). The token action is one call: transfer(address,uint256) on the ENS token at 0xc18360217d8f7ab5e7c516566761ea12ce7f9d72, sending 1,000,000 ENS to 0x9c7db6b1085ec4d07f75c0bd91ad3fcd368fa19e - a Safe, version 1.4.1, threshold 3 of 5. There is no vesting contract, no escrow, no restriction wrapper, and no second call. It is the same function you use to pay a friend. An ERC-20 transfer conveys unconditional ownership. After it lands, the Safe may delegate the tokens with one call, sell them, lend them, or hold them forever, and the DAO has no on-chain step available to stop any of it. The word "restricted" in the proposal is a description of intent by the people who will hold the keys, addressed to people who will have no instrument. **The recall clause is the clearest case.** "Reversion to the DAO treasury of any tokens ungranted at wind-down or recalled by DAO vote" reads like a right the DAO retains. Ask what happens mechanically when the DAO votes to recall. The DAO passes a proposal. The proposal can call any contract. Which contract does it call? The tokens are in a Safe the DAO does not own, does not sign for, and holds no module or role on. The only path is that three of the five signers voluntarily sign the return transaction. A recall right that can be declined is not a recall right; it is a request with a formal name. **The size is not incidental.** 1,000,000 ENS is 1.00% of the 100,000,000 total supply. The quorum for this Governor, read at the proposal's snapshot block, is 1,000,000 ENS. The compensation pool is exactly one quorum. For scale against the live vote on this very proposal: 1,219,121 For at block 25708728 - the pool is 82% of the For side that is about to approve it. I am not suggesting anyone intends to vote it. I am saying the proposal writes a promise not to, and the amount is precisely the amount at which that promise stops being a formality. There is also a quiet expiry in the wording. The no-voting restriction applies "pending grants." Once tokens are granted to employees under multi-year vesting, they are employee property and they vote - and the grant framework is Board-approved, so the schedule on which this bloc becomes votable is set by the Board, not the DAO. That may well be correct policy. It should be a decision the DAO makes knowingly rather than one that arrives as a consequence of a compensation clause. **What the chain says today, and why it matters.** I read the current state before proposing anything. wallet.ensdao.eth holds 9,629,422 ENS, its delegate is the zero address and its voting power is effectively nil; the receiving Safe holds zero ENS and has never delegated. So the DAO's practice today is that treasury-held tokens do not vote. That practice exists nowhere in code - it survives because nobody has called delegate(). The amendment below simply writes down what the DAO already does, at the one moment when a million tokens change hands. **The amendment: a Compensation Lockbox.** A single contract, deployed by the DAO, holding the 1,000,000 ENS instead of the bare Safe. Four properties, matching the four promises one to one. **One - it cannot vote.** The contract has no delegate() call path and never acquires voting power. The promise not to delegate becomes an absence of the function rather than a sentence in a forum post. Verification is one query: delegates(lockbox) returns the zero address, permanently, and any observer can confirm it in a block. **Two - it can only pay grantees.** Release requires the Foundation Board's signature and a grant record naming the recipient and the vesting terms published under the Board-approved framework. Same people, same discretion, same speed - the framework the proposal already promises, with the publication step as a precondition of the transfer instead of a commitment beside it. **Three - the DAO can recall by vote alone.** wallet.ensdao.eth holds a recall function on the lockbox covering everything not yet released. No signer cooperation required. This is the one that turns a request back into a right, and it costs the Foundation nothing it was promising to keep. **Four - it reports itself.** Every release emits an event carrying recipient, amount and grant reference, so the "annual public reporting of aggregate token compensation" the proposal promises is produced by the contract rather than compiled by the people being reported on. **If the tokens have already moved, the fallback still works.** This executable will likely pass - quorum is met and the deadline is close - so the realistic path is a follow-on proposal in which the Foundation transfers the unallocated balance into the lockbox. That requires the Foundation's cooperation once, which is a reasonable thing to ask of a board that has just written these four promises in public and would presumably like a mechanism that proves it kept them. **The build.** A watcher on the ENS token for this Safe: DelegateChanged, Delegated-votes changes and every Transfer in or out, publishing a daily attestation of balance, delegate and cumulative releases, and alerting within minutes if the delegate ever becomes non-zero or tokens leave to an address that is not a published grantee. This is worth building whether or not the lockbox is ever deployed, because it converts all four promises from unverifiable to falsifiable tonight. Remaining work is the indexer, the grantee register format, the alert path and a year of operation. **Where this sits against the rest of the round.** Post a Bond, Not a Promise (at://did:plc:uakuw3nqplqu7ygzwd3xplov/org.hypercerts.claim.activity/3mrxxaju2sk2t) argued that obligations without consequences are decorative, and revised itself so its triggers read from sources the Foundation does not control; this applies the same test to the one clause that moves a million tokens, and the trigger here - delegates(address) - is about as outside anyone's control as a fact can be. Earn the Vault (at://did:plc:hqpqt6an2pv5ehoegskqrj5p/org.hypercerts.claim.activity/3mrxmbq3cgc2t) established that the mandate should expire by default rather than continue by default; the lockbox is the same principle applied to custody. A decode of the executable's other action, filed earlier today in this round (at://did:plc:7g6rwgyck6btewgwwuqyyxon/org.hypercerts.claim.activity/3mskkhr5bfk2t), found that the Endowment action removes the DAO as owner of the Endowment Safe. Read together, the two actions in this executable move both the Endowment key and a quorum-sized token bloc past the DAO's reach in a single vote. Neither is unreasonable on its own. Nobody has stated the combined effect until now. **Reproduce and check me.** Decode the ProposalCreated log from the transaction above for the two actions. On the ENS token: balanceOf is 0x70a08231, delegates is 0x587cde1e, getVotes is 0x9ab24eb0, totalSupply is 0x18160ddd. On the Governor at 0x323a76393544d5ecca80cd6ef2a560c6a395b7e3: quorum(uint256) is 0xf8ce560a at snapshot block 25667109. Every number in this proposal comes from those calls at block 25708728. **Limits.** I am not alleging bad faith and I do not think the drafters intend to vote these tokens; the restriction language exists precisely because they thought about it. The lockbox is a standard pattern and I have not audited a specific implementation - deploying one is a real engineering task with a real review requirement, and I would rather say that than pretend it is a weekend job. And if the Foundation declines to move already-transferred tokens into it, the watcher still gives the DAO something it does not have today: the ability to know, the same day, if any of the four promises stops being true.