# Three Clocks: Published Close, Programmed Maximum, and Finalization
*Probity Institute — method note. A mechanical check anyone can run, worked through on one live proposal. Descriptive only: no rating, no recommendation, no statement about how any holder should act.*
A governance proposal can have three closing times. The **published close** is the point the DAO's material identifies as the end of voting. The **programmed maximum** is the last moment the governance program accepts an instruction that can change the tally. The **finalization time** is when a later transaction records the result and freezes the tally. These times may coincide, but they need not.
This page defines the mechanical check, applies it to one Solana governance proposal, and gives the reading recipe so the result can be reproduced independently. The check has no effect on any GSA determination, cell or tier.
## What the check measures
For a proposal on an SPL Governance program (the program behind Realms), three values are stored on chain:
- `creation_time` — when the proposal account was created, in unix seconds;
- `voting_base_time` — the base voting window, in seconds;
- `voting_cool_off_time` — an optional extension, in seconds, during which **only negative votes (Deny and Veto) and vote relinquishment are accepted**.
From those three values:
- **Programmed vote close** = `creation_time` + `voting_base_time`
- **Programmed last moment** = `creation_time` + `voting_base_time` + `voting_cool_off_time`
- **Finalization time** = the block time of the successful `FinalizeVote` instruction
- **Formalization latency** = finalization time − programmed last moment
The check compares the **published close** — the point the DAO's own material identifies as the end of voting, read by a person and cited — against the **programmed last moment**. It reports the difference in seconds and names the instructions the program still accepts in the interval. Once that interval ends, a separate receipt establishes when the result was formalized.
Three outcomes are possible:
1. **Aligned.** The published close is the programmed last moment. The announcement is a complete statement of when the decision can still change.
2. **Programmed open after published.** The material says voting has ended while the program still accepts Deny, Veto and relinquishment. The recorded result can change after readers were told it could not.
3. **Published open after programmed.** The material gives holders more time than the program will allow. This is the more damaging direction and we have no live case of it yet.
## Worked example: Orca DAO, proposal 91VPw3WU
Orca DAO is a Solana exchange and is not one of the 53 DAOs in the determinations dataset. It is used here because its material and its program disagree about what the cooldown is, and every input is a public account read.
**On-chain values, read 2026-10-19 at 02:00 UTC:**
| Field | Value |
|---|---|
| Governance account | `7VZTFBDyJK5pdoQWzi8gEHDuqdmHW8xwghbyQKUxjqVt` |
| Proposal account | `91VPw3WU24gSZLPbvKJaPPg7RkK9iPgvx8B3xL75keho` |
| `creation_time` | 2026-10-13 18:38:46 UTC |
| `voting_base_time` | 432,000 s (5 days) |
| `voting_cool_off_time` | 172,800 s (2 days) |
| Programmed vote close | 2026-10-18 18:38:46 UTC |
| Programmed last moment | 2026-10-20 18:38:46 UTC |
| Proposal state at read | `Voting` |
**What the DAO published.** On 2026-10-13 the Council Secretary posted the live vote with two times: "Voting period ends: 18 October 2026, 18:38 UTC. Cooldown period ends: 20 October 2026, 18:38 UTC." The proposal's terms describe the cooldown as a period in which the proposal "cannot be implemented" and during which the Council may veto it. The passing condition is stated as at least 3,000,000 ORCA voting Yes, with more Yes than No, "during the 5 day voting period" (forum posts 16 and 12, forums.orca.so/t/1281).
**The divergence.** Both published times are correct. What differs is what the cooldown *is*. In the program, the cooldown is still voting: Approve and Abstain are rejected, but Deny, Veto and RelinquishVote are accepted until 2026-10-20 18:38:46 UTC. A holder who reads "voting period ends 18 October" and stops watching is right about Yes and Abstain and wrong about the three instructions that can still change the recorded tally. The gap between the stated end of voting and the program's last accepted instruction is **172,800 seconds**.
**Observed in the gap.** The largest opposing ballot, exactly 700,000.000000 ORCA, was withdrawn at **2026-10-18 20:28:46 UTC** — 110 minutes after the stated close of voting. The transaction succeeded (`27rgR2j…Jqi4`, no error), and the vote record (`7PBE3yb9…QjoS`) no longer exists on chain; its signature history shows only the original cast and the withdrawal.
**Tallies at the same read**, summed from 24 vote records and cross-checked against the proposal account's own option totals:
- Yes: **3,594,556.733884 ORCA** (119.82% of the 3,000,000 ORCA figure stated in the Bylaws)
- No: **36.978620 ORCA** (0.0010% of participating weight)
- Participating: **3,594,593.712504 ORCA** across 24 records
- Three ballots of exactly 1,000,000.000000 ORCA supply 83.46% of the Yes total and sum to exactly 3,000,000.000000.
**Finalization — VERIFIED.** A successful `FinalizeVote` instruction was recorded at **2026-10-21 00:50:02 UTC**, **22,276 seconds (6 hours 11 minutes 16 seconds)** after the programmed last moment. Its sole signer was `FA8Kft2G8xGY8AhQEdPSSxpRnEoPpg4tm17nmS1hYJQf`, the wallet associated with a **75,000.000000 ORCA Yes** vote record. The proposal account now reports state code `5`, `Executing`.
**Final recorded tally — VERIFIED.** The proposal account records **Yes 3,594,556.733884 ORCA** and **No 36.978620 ORCA**. Eight seconds after `FinalizeVote`, the same 75,000-ORCA voter successfully called `RelinquishVote` and `WithdrawGoverningTokens`. At 2026-10-21 23:50:47 UTC, a voter associated with an exact **1,000,000.000000-ORCA Yes** ballot called `RelinquishVote` three times and `WithdrawGoverningTokens`. A fresh account read after both transactions returned the same option totals, reconciled exactly against the 24 remaining vote records. Relinquishment after finalization did not reopen or recalculate the recorded tally.
**Proposal-state transition — UNVERIFIED.** The transaction that first wrote state code `5` has not been identified with an archival before-and-after account read. We do not infer that fact from the `FinalizeVote` receipt or either later withdrawal receipt.
## Reading it yourself
Read-only, no key, any Solana RPC endpoint:
1. **Governance config.** `getAccountInfo` on the governance account, base64. On the Orca account (236 bytes) `voting_base_time` is the little-endian `u32` at byte offset 83 and `voting_cool_off_time` at offset 103. These offsets were located by searching the account bytes for the values, not taken from a specification; re-locate them the same way for any other governance account rather than assuming.
2. **Proposal.** `getAccountInfo` on the proposal account. Byte 65 is the proposal state: the 2026-10-19 read returned `2` (`Voting`), while the post-finalization read returned `5` (`Executing`). The option vector begins with a `u32` label length; in the Orca account `Yes` starts at byte 113 and `No` at byte 135, each followed by a little-endian `u64` weight in base units and a `u8` result. `creation_time` is the little-endian `i64` at byte 156. Read the successful `FinalizeVote` receipt separately; without an archival before-and-after read, do not equate it with the unidentified state-code write.
3. **Votes.** `getProgramAccounts` on the SPL Governance program `J9uWvULFL47gtCPvgR3oN7W357iehn5WF2Vn9MJvcSxz`, filtered by `memcmp` at offset 1 against the proposal address. Each 91-byte record carries the voter's wallet at bytes 33–65, the weight as a `u64` at 66–74, and the option bytes at 80–84. The per-record weights must sum exactly to the proposal account's option totals; if they do not, the layout has changed and the read should be discarded rather than interpreted.
## Second venue, same comparison: a Governor contract
The Orca read above is one venue's layout. A check that only works where it was invented is an anecdote, so the same two-number comparison was run against an EVM governor — Compound's — where the mechanism stores its own numbers in a different shape and answers in a different language.
**What was compared.** Compound's published governance process says a passed proposal waits two days in the timelock. The contract states the same delay in two places: the timelock's minimum delay, and the `eta` stamped on the proposal when it is queued. Both were read at source on 2026-10-20.
| Quantity | Published | Programmed | Class | Gap |
|---|---|---|---|---|
| Timelock minimum delay | 2 days (172,800 s) | 172,800 s — `delay()` on `0x6d903f60…c33925` | aligned | 0 s |
| Applied delay on proposal 611 | 2 days (172,800 s) | 172,800 s — `eta` 1791289199 minus queue time 1791116399 | aligned | 0 s |
Proposal 611's timeline, read from the chain: voting closed at block 26113038 (2026-10-03 16:34:23 UTC), the proposal was queued at block 26118948 (2026-10-04 12:19:59 UTC), and `eta` — the first moment it could execute — was 2026-10-06 12:19:59 UTC. The delay the DAO publishes is exactly the delay the mechanism applied. Nothing hidden, nothing to report beyond the number.
**A false positive this check produced, and why it is printed rather than deleted.** The first pass compared `eta` to the vote-close timestamp and reported a gap of 243,936 seconds — two days and 19 hours 45 minutes — which would have read as a DAO publishing a two-day delay while applying a longer one. It is not that. A governor stamps `eta` at the moment the proposal is **queued**, not at the moment voting ends, so the difference between `eta` and the vote close contains the 71,136 seconds (19h45m36s) it took for someone to submit the queue transaction, plus the delay. Queue latency is not a delay divergence, and a check that conflates them would accuse a DAO of something it did correctly.
The corrected rule, now written into the tooling: the programmed delay is `eta` minus the **queue** timestamp, taken from the `ProposalQueued` event. Where the queue moment is unknown, the check declines to classify rather than guess. This is the second thing the second venue taught us, and it is the reason the check family is run against more than one contract before any of it is described as a standard.
**A third outcome, recorded as a refusal.** The live ENS activation proposal stores its close as a block number (26267763) that had not been mined at read time. A block number becomes a wall-clock time only when the block exists, so there is nothing to compare yet; the check reports *not comparable*, with the reason, instead of projecting a timestamp and calling the projection a reading. A projection is not a determination.
## Where the check generalises
- **Governor-style contracts** (Compound, Uniswap, Aave): the programmed close is `voteEnd` in the proposal struct and is normally the value the interface displays, so this divergence class is usually zero there. The parallel test is the execution window — `eta` and the timelock delay — against the delay the proposal describes, but only when `eta` is measured from the **queue** event. Measured from the vote close it produces a false gap, as the section above records.
- **Timelocks**: the same shape applies to any published delay. A stated 2-day timelock against a contract `getMinDelay()` is the identical test in a different variable; Compound's t/8098, which proposes raising both the escrow cooldown and the timelock minimum to 10 days, is a live in-dataset case.
- **Snapshot**: a proposal's `end` timestamp *is* the published date, so this class of divergence is zero by construction. What needs checking there is whether the space's stated voting period and the proposal's actual window agree — a different test.
- **Every Realms DAO**: the config read is one `getAccountInfo` per governance account, so the check is cheap to run across a whole venue rather than proposal by proposal.
## Limits
- The published close is a **human-read claim** from the DAO's own material, cited with its source. It is the one input that is not mechanical, and the check is only as good as that citation.
- The check reports **what the program will accept**, not what the DAO intends. A divergence may be a design nobody disclosed or an announcement that described the cooldown loosely. We record the difference; we do not assign a motive.
- The close comparison does not itself determine the finalized outcome. Outcome and formalization latency require a successful `FinalizeVote` receipt and a post-finalization proposal-account read.
- A `FinalizeVote` receipt does not identify a separate proposal-state write unless archival transaction evidence establishes that link.
- This is a mechanical check outside the frozen GSA methodology. It changes no GSA cell, determination or tier.
- The account layouts above are empirically derived from one live account each and sum-verified. They are not a specification, and a program upgrade can change them.
Determinations on this site describe code and program state, not intent. Nothing here is advice, a recommendation, or a view on whether any proposal should pass. Verify any figure against the accounts named above; if a number here is wrong, we will correct it and date the correction.
*Sources: Solana mainnet RPC reads, 2026-10-19 02:00 UTC and 2026-10-22, including the 700,000-ORCA post-close relinquishment `27rgR2jNn9qNipoT7bzbYBacLGA549Hz3vCQHgZBvhRgpcq9Fuc79VCKsmo5URGHFmEMHu1tRkExKt3XYJq1Jiq4`, `FinalizeVote` receipt `2KFyr1Z2NS2DHixa61y6EVjkGUtG5VPn82Bg6ncJCsiouW1mwxf1BRU52Hzz2kreRWUhDc5F5AtV5d3bTD6QdKdi`, 75,000-ORCA post-finalization relinquishment `5aaeNmVZ1kPpFvyjkQGyggrWshTzZmaPvC9zF5ZdeTdbJgfThWhhMgLzezePXnKNwAHWDXQoTcudNwrELLAE6V3f`, and 1,000,000-ORCA post-finalization relinquishment `nJzghFX7qMjKCDcX9eZMEuD4DpS1933o6WRMDMfR3DcpL243JSjq2BiRm8yZpsCDb6PoQXBEiNvMaKtDyL9JMYb`; Orca forum posts 12 and 16, forums.orca.so/t/1281; SPL Governance cool-off semantics per the Realms documentation and the `GovernanceConfig` type (`voting_base_time` "can be extended by optional cool off time when only negative votes (Veto and Deny) are allowed").*
---