No Feedback Black Box: An Amendment Ledger Before the Foundation Vote

The strongest argument for empowering the ENS Foundation should be granted. ENS needs professional execution, legal continuity, long-term stewardship, faster operational decisions, and a structure that can handle work the token-voting process is bad at doing every week. But there is one step where Foundation empowerment can become illegible even if everyone argues in public: the move from forum feedback to executable proposal. A temp check can receive serious objections. A draft can say it incorporated feedback. An executable can then arrive with a payload, board structure, budget authority, custody assumptions, grants transition, and accountability language that ordinary delegates cannot easily compare against the debate that produced it. The fresh frame is simple: **If feedback matters, it should leave a public diff.** ENS should require an Amendment Ledger before the Foundation executable vote. ## Mechanism: the ENS Foundation Amendment Ledger Any major Foundation empowerment executable should publish a public ledger that maps material objections to concrete treatment before the vote opens. The ledger is not a veto and not another debate forum. It is change control for DAO legitimacy. ### 1. Material objection register **Who decides:** ENS DAO ratifies a materiality rubric for the Foundation transition. **Who executes:** The proposer or Foundation transition team compiles the register from the official forum threads, temp checks, draft executable discussion, public calls where transcripts are available, and delegate comments. **Who reports:** A reviewer pool checks the register for completeness. An objection is material if it concerns at least one of these areas: - treasury custody or drawdown authority; - board selection, independence, renewal, or removal; - conflicts of interest and recusals; - grants/SPP absorption and eligibility criteria; - operating budget or discretionary authority; - protocol, app-layer, Endowment, or revenue assumptions; - reversibility, sunset, or emergency reopening. The register should not include every small comment. It should include the objections that would materially change whether a delegate supports the executable. ### 2. Response and diff requirement **Who executes:** The proposer publishes a response for each material objection. Each ledger row should show: - objection summary; - source link or post number; - owner responsible for the response; - status: adopted, partly adopted, rejected, deferred, or out of scope; - exact text or payload diff when adopted; - reason when rejected; - rejected alternative, if one exists; - whether the issue should be split into a separate vote. A proposal should not be able to claim that feedback was incorporated without showing the diff. ### 3. Unresolved-core trigger **Who decides:** The trigger is ratified before the executable vote. If three or more core areas remain marked rejected, deferred, or unresolved, the default is not automatic rejection. The default is separation. The executable should split the unresolved core area into a separate vote, amendment, or explicit delegate choice. For example, ENS could vote separately on: - Foundation operating mandate; - treasury custody or drawdown cap; - board independence rules; - grants transition rules; - conflict-of-interest policy ratification; - renewal and contraction terms. This lets delegates support professional execution without being forced to accept every unresolved assumption in one package. ### 4. Minority response bounty **Who appeals:** Any delegate group, working group participant, or tokenholder coalition can nominate one unresolved core issue for a minority response. **Who executes:** A fixed bounty funds a short public memo that writes the strongest case against the unresolved issue and the smallest amendment that would make it acceptable. **Who reports:** The memo is linked inside the ledger before voting starts. This is not opposition theater. It is a counter-search mechanism. It keeps skeptics inside the process and reduces the chance that one institution supplies the facts, the options, the timeline, and the definition of success. ### 5. Vote-readiness checkpoint **Who reverses or pauses:** Delegates decide whether the executable is vote-ready. Before the vote opens, the ledger should pass a simple readiness check: - every material objection has a source and response; - every adopted change has a visible diff; - every rejected core objection has a reason; - every unresolved core cluster has a split-vote or explicit no-split rationale; - every reviewer disagreement is preserved in the public archive. If the ledger is incomplete, the vote can still proceed only if the missing sections are named publicly. Silence should not be treated as resolution. ## Adoption path 1. Ratify the Amendment Ledger as a process amendment for the ENS Foundation executable. 2. Build the initial register from topics #22175, #22203, and #22329, plus any official Foundation transition discussion links. 3. Publish a temp-check-to-executable diff map. 4. Apply the unresolved-core trigger to custody, board, grants, budget, COI, and reversibility issues. 5. Fund one or more minority response bounties before the executable vote. 6. Archive the final ledger as the public record of how ENS handled feedback during the transition. ## Budget request Request **$160,000** for a 90-day pilot: - `$35,000` for ledger schema, materiality rubric, and governance-language drafting; - `$30,000` for forum/source extraction, objection clustering, and public source links; - `$25,000` for executable diff mapping and reviewer QA; - `$25,000` for minority response bounties; - `$20,000` for delegate review packets, summaries, and public archive; - `$15,000` for legal/governance review of vote-splitting implications; - `$10,000` for maintenance, corrections, and final post-vote report. This is small relative to the Foundation authority being debated, but large enough to make the public feedback process auditable instead of performative. ## Why this is not duplicative This is not another generic accountability dashboard. It does not measure Foundation performance after authority is granted. It is not another custody proposal. Custody is one row in the ledger, not the whole mechanism. It is not another grants charter or grantee-continuity proposal. Grants are included only because SPP absorption is one material objection category. It is not another anti-capture manifesto. It creates a narrow process rule: material feedback must be mapped to a public response, diff, or split-vote trigger before the executable vote. ## What would change my mind If the final ENS Foundation executable already publishes a complete objection-to-amendment ledger, exact diff map, rejected-alternative notes, and split-vote treatment for unresolved custody, board, grants, COI, budget, and reversibility objections, this proposal becomes redundant. If delegates explicitly decide that speed matters more than a complete ledger, the requirement could be narrowed to only custody, board, grants, and COI. But that tradeoff should be visible. Public feedback should not vanish between discussion and execution.