# Execution Layers — When a Vote Does Not Finish the Handover
A passed governance vote can authorize one transaction while leaving the advertised end
state dependent on later operators and later votes. We record those dependencies as
separate execution layers. This prevents a live vote, an executed payload, and a completed
handover from being reported as the same event.
## The three-layer record
| Layer | Question | Evidence that closes it |
|---|---|---|
| `voted_payload` | What does the Governor and Timelock execute if the proposal succeeds? | Proposal calls, final vote state, queue record, execution transaction, post-execution state reads |
| `required_operator_commitments` | Which later actions depend on named operators rather than the voted payload? | Operator transactions and direct reads proving every promised role, proxy, or parameter change |
| `later_cleanup_vote` | Which parts of the advertised end state require another executable proposal? | The later proposal, its execution, and post-execution reads |
Each layer names its authority, status, enforcement class, actions, and closing evidence.
The aggregate record remains incomplete while any required layer is unresolved. A layer
may be politically expected and still be `not_yet_verifiable` when no transaction has
occurred.
This is descriptive data. It does not change a GSA verdict, rate the proposal, or state how
any holder should vote.
## Worked example: ENSv2 activation
ENS proposal `51915723803355532053585313225201979004629663092454892570706465301184496475762`
was **Active** at Ethereum block `26237855` on 2026-10-21 02:02:59 UTC. The Governor
returned:
- For: `1,017,070.841990320100294119 ENS`
- Against: `24.944871129841 ENS`
- Abstain: `0 ENS`
- Quorum: `1,000,000 ENS`
- Queue ETA: `0`
Quorum was crossed by `17,070.841990320100294119 ENS`, but the vote remained open. No
payload call had executed.
### Layer 1 — voted payload
The proposal contains 15 atomic calls from the DAO Timelock. They freeze new v1 `.eth`
registrations, preserve renewals for unmigrated names, authorize migration-cleanup
contracts, transfer the v1 BaseRegistrar to a renew-only contract, and route the canonical
Universal Resolver through an intermediate proxy. Immediately after call 15, that
intermediate proxy still serves v1 resolution.
The proposal text says only stage 2 of its five-stage activation requires this vote. The
15 calls do not perform the final sync, enable v2 registration, switch canonical resolution
to v2, or transfer every v2 admin role from ENS Labs to the DAO.
### Layer 2 — required operator commitments
After the voted payload executes, the specification assigns these actions to named
operators:
1. ENS Labs takes a fresh post-freeze v1 snapshot and reruns premigration.
2. ENS Labs revokes the BatchRegistrar roles, enables both migration controllers, and
authorizes the v2 ETHRegistrar.
3. The ENS Security Council switches the intermediate Universal Resolver proxy to the v2
implementation.
4. ENS Labs transfers every v2 admin role it holds to the DAO Timelock, renounces its own
roles, transfers the `.eth` and `.reverse` root tokens to a Timelock-owned Safe, and
transfers the two BatchRegistrar contracts to the DAO.
5. ENS Labs publishes each transaction and a script proving its deployer retains no role.
These are commitments in the proposal specification. They are not calls in the voted
payload. We close this layer only after the transactions and role reads exist.
### Layer 3 — later cleanup vote
The specification says some v2 roles are deliberately broader than the system needs
long-term. Once v2 has run safely, a follow-up executable proposal is expected to revoke
those roles, including the `.eth` root token's power to unregister `.eth`.
Until that later proposal executes and the roles are read again, the advertised end state
remains incomplete.
## Consumer rule
Use the layer status, not the proposal headline, as the completion signal:
- `active_vote_quorum_met_not_executed` means the political threshold is currently met but
no state change has executed.
- `not_yet_verifiable` means the proposal text assigns a future action to an operator and
no closing chain evidence exists.
- `future_executable_proposal_required` means another governance action is part of the
stated end state.
A risk engine should therefore distinguish `payload_executed` from `handover_complete`.
An executed first layer can be a material event while the overall transition remains open.
## Sources and limits
Primary sources, accessed 2026-10-21:
- [ENS proposal and 15-call specification](https://www.tally.xyz/gov/ens/proposal/51915723803355532053585313225201979004629663092454892570706465301184496475762)
- [ENSv2 migration documentation](https://docs.ens.domains/ensv2/migration/)
- [ENS Universal Resolver documentation](https://docs.ens.domains/resolvers/universal/)
The exact vote weights, state and queue ETA above were read from the ENS Governor at block
`26237855`. The proposal deadline is block `26267763`, which had not been mined at that
read. We therefore do not publish a canonical closing timestamp yet. Tally's address count
is front-end data; the Governor does not return a voter count.
---