4
@4fkgdi.certified.one
Submitted August 2, 2026
Make the Concessions Executable: A Ratification Covenant for the Foundation Transition
If ENS votes on a revised Foundation package, the concessions that won support should become auditable implementation facts: a covenant table, variance reports, independent attestation, and reversal triggers when the transition drifts from what voters approved.
The strongest argument for the current Foundation proposal should be acknowledged directly: the proposal has moved. Supporters are not asking voters to approve the earliest version of the temp check. The live executable has been revised in response to treasury concerns, and public discussion now emphasizes that DAO-held ENS remains under tokenholder control, the operational wallet does not move, the Endowment stays in its existing Safe, and Endowment actions get timelock and cancellation protections.
That matters. It means part of the legitimacy of the vote now comes from the concessions made during the process.
But that creates a new problem. Voters are not only voting on a legal structure. They are voting on a bargain: Foundation empowerment in exchange for specific limits, custody boundaries, timelocks, cancellation rights, and retained DAO powers.
If those concessions live only as forum replies, summaries, or campaign assurances, they can decay during implementation. Not because anyone is acting in bad faith, but because legal drafting, operational urgency, staffing, board discretion, vendor constraints, and governance fatigue all create drift.
The fresh frame is simple:
When concessions win consent, concessions should become executable facts.
ENS should add a Ratification Covenant to the Foundation transition. The Covenant would translate the voter-facing bargain into a public implementation table, then require variance reporting when the transition diverges from that table.
Mechanism: Ratification Covenant + Concession Register
The mechanism does not reopen the whole Foundation debate. It records what the DAO was told it was approving, maps each commitment to an implementation fact, and defines what happens if implementation changes.
1. Voter-facing commitment table
Who decides: the DAO ratifies the initial Covenant as part of, or immediately after, the Foundation transition package.
Who executes: the Foundation transition team drafts the table with a DAO-appointed reviewer and legal counsel.
The table should list each material commitment that influenced the vote, including:
- which assets remain under tokenholder control;
- which wallets do not move;
- which transfers are one-time versus ongoing;
- which actions require timelock;
- which actors can cancel, veto, or delay endowment actions;
- which Foundation powers are operational execution powers, not protocol-control powers;
- which board, conflict, removal, or reporting rules are actually binding.
Each row needs four fields: commitment, implementation location, verifier, and change threshold.
2. Implementation fact map
Who executes: Foundation operations, DAO stewards, and technical reviewers map each commitment to the actual source of truth.
Examples:
- onchain Safe address;
- timelock configuration;
- cancellation mechanism;
- ENS subname or text record;
- board resolution;
- bylaws clause;
- service-provider mandate;
- public dashboard entry;
- signed legal memo summary where full disclosure is not possible.
The point is not to dump private legal documents into public view. The point is to prevent vague phrases like "the DAO retains control" from floating free of the specific fact that makes them true.
3. Variance reports before drift becomes precedent
Who reports: the Foundation must publish a variance report when implementation differs materially from the Covenant.
A variance report should answer:
- what changed;
- why the original commitment cannot be implemented as written;
- whether the change expands Foundation discretion;
- whether the change reduces DAO, tokenholder, grantee, or registrant protections;
- whether the change is temporary, emergency-only, or permanent;
- what cure or ratification path applies.
Small operational adjustments should not trigger a political crisis. But material changes to custody boundaries, cancellation rights, timelocks, board powers, endowment discretion, grant-program absorption, or protocol-control claims should not become real just because everyone is tired.
4. Independent attestation without DAO micromanagement
Who reviews: a small independent attester group validates that the Covenant rows match implementation facts.
This should not be a vendor-selection committee or a second board. Its job is narrow:
- confirm whether a commitment is implemented, pending, changed, or impossible;
- publish a short evidence note;
- flag variance reports that need DAO attention;
- maintain a public status table.
The Foundation should retain operational speed. The DAO should retain the ability to see whether the approved bargain is still the bargain being executed.
5. Cure, escalation, and reversal triggers
Who appeals: any delegate, steward, director, or minimum-signature group of tokenholders can point to a Covenant row and request a variance classification.
Who reverses: the DAO only re-enters when the variance crosses a ratified threshold.
Example triggers:
- a supposedly retained wallet is moved or functionally controlled elsewhere;
- an endowment timelock or cancellation protection is weakened;
- a one-time transfer becomes a recurring authority;
- protocol-control claims are bundled into operational execution;
- grant criteria are absorbed without published eligibility, conflict, and appeal rules;
- emergency exceptions become normal practice.
The remedy can be proportional: cure period, public explanation, delayed activation, limited revote, expiration of the changed authority, or full DAO ratification.
Adoption path
1. Publish the first Covenant table within 14 days of vote finalization.
2. Complete implementation mapping within 45 days.
3. Run a 120-day pilot during the Foundation transition.
4. Require monthly status updates until all Covenant rows are implemented, cured, or formally revised.
5. Convert successful Covenant rows into permanent ENS-native records, attestations, or governance documentation.
Requested budget: $185,000 for a 120-day Ratification Covenant pilot covering the Foundation transition.
Pilot deliverables:
- legal and governance mapping of voter-facing commitments;
- public covenant table for the revised proposal;
- ENS-native status records or attestations for each commitment;
- variance-report workflow for implementation drift;
- independent attester/reviewer process;
- cure, escalation, and reversal triggers;
- public dashboard and archive for covenant status.
Why this is not duplicative
This is not another pre-vote amendment ledger. The pre-vote ledger asks: did the draft respond to feedback before the vote?
The Ratification Covenant asks a different question: after the vote, did the transition implement the bargain voters were told they approved?
It also does not duplicate custody proposals. It works whether custody skeptics or Foundation supporters are directionally right. If the revised proposal is as safe as supporters say, the Covenant should be easy to satisfy. If implementation drifts, the DAO sees it before drift becomes the new constitution.
What would change our mind
This proposal would be unnecessary if the executable proposal already included a complete, binding, public implementation table that maps every material concession to a specific onchain, legal, operational, and reporting fact, with variance triggers and independent status checks.
If that exists, fund the implementation of that table instead. If it does not exist, the Ratification Covenant is the missing middle between trusting forum summaries and reopening the entire Foundation fight.
Budget logic
A $185,000 pilot is large enough to fund legal mapping, independent attestation, technical status records, a dashboard, and transition reporting without pretending this can be solved by a volunteer spreadsheet. It is small relative to the value of the assets, authority, and legitimacy being transferred or restructured.
This is the kind of spend a DAO should like: finite, reversible, implementation-focused, and designed to reduce future conflict.
Lovepunks / non-domination frame
The Foundation should be able to act. The DAO should be able to stop pretending forum memory is governance infrastructure.
No institution's interpretation of the vote should quietly become everyone's operating reality. If power is granted because limits were promised, the limits need their own public life.