# A published threshold, and the base it multiplies
A governance proposal can name a threshold in a sentence — "20% of votable supply" — and the
number that sentence produces depends on a second value the sentence does not name. This note
describes the read that tests the two against each other, publishes a worked example, and states
the limit.
## Why it is a separate read
A percentage is not a rule until its base is fixed. Two contracts can implement "20%" and mean
numbers two orders of magnitude apart, because one multiplies by total supply and the other by
the supply eligible to vote. A reader told "20%" learns the shape of the rule and nothing about
the cost of using it.
So the record publishes three things beside each other:
1. the threshold as **published** (quoted, with the document and its date);
2. the base as **read** from the contract that computes it, at a pinned block;
3. the resulting **number of votes**, computed both ways where the two bases differ.
## How the read works
Three calls against the governor, and one against the module it names.
- `0xf8ce560a` — `quorum(uint256)`: call it with the proposal **snapshot block** the governor
computes for itself. The governor's own `quorum` is per proposal type, so this one call
contains both the percentage and the base.
- `0xf48aef33` — `proposalTypes(uint8)`: the per-type tuple. For a type that carries no quorum
of its own, the threshold lives in a module instead.
- `0xc792b5aa` — `approvedModules(address)`: whether a module is approved. A deployed module that
is not approved cannot be used, and a record that reads a deployed-but-unapproved module as
the current behaviour would be wrong.
- `0xb9f5ee9a` — `votableSupply()`: the governor's own view of the base it uses.
Where a threshold is computed inside a module, the module's **verified source** is read and the
relevant lines are quoted in the record. The arithmetic in the source is the finding; the
deployment of the module is the fact that makes it operative.
A browser `User-Agent` is required by the public endpoints; a default python or curl agent is
answered with 403.
## Worked example — Optimism, "Security Council Changes", read 2026-10-30
The proposal (forum topic 10921, posted 2026-10-22) replaces Security Council cohort elections
with a Lead who nominates members, each seated unless a veto threshold is reached. It states:
> Each nominee is confirmed through a new proposal type, "Council Appointment". A nominee is
> seated unless 20% of active votable OP supply vetoes that nominee.
The implementing pull request (OPerating-manual #72, open and draft at the read) states:
> An appointment is vetoed if veto votes reach 20% of active votable OP supply.
The onchain ratification proposal's own description (block 158,853,925) states:
> Each nominee is confirmed through an optimistic approval and is seated unless 20% of votable
> OP supply vetoes them.
The word **active** is in the forum post and in the charter text; it is not in the onchain
description. No published text defines it, and none states a formula, snapshot rule or activity
window.
Read at OP Mainnet block **158,863,672** (2026-10-30 02:08:41 UTC):
- Governor `0xcDF27F107725988f2261Ce2256bDfCdE8B382B10`, proposal type 2 ("Optimistic"):
quorum 0 bps, approval 0 bps, module `0x8980C97f0e8a3A69831139e51003E65238F1F343`.
- `approvedModules(0x8980…)` → **true**. `approvedModules(0x27964c5f…)` → **false**.
- The approved module's verified source:
```
if (proposal.settings.isRelativeToVotableSupply) {
uint256 snapshotBlock = IGovernorUpgradeable(proposal.governor).proposalSnapshot(proposalId);
IVotesUpgradeable token = IOptimismGovernor(proposal.governor).token();
againstThreshold = (token.getPastTotalSupply(snapshotBlock) * againstThreshold) / PERCENT_DIVISOR;
}
```
The flag is named `isRelativeToVotableSupply`; the code multiplies by **total supply**.
- The deployed-but-unapproved variant `0x27964c5f…` computes the same expression against
`votableSupply(snapshotBlock)` instead.
- `totalSupply()` of OP at the read: **4,294,963,292.25 OP**. `votableSupply()`: **55,134,630.00 OP**.
- 20% of the votable supply is **11,026,926 OP**. 20% of total supply is **858,992,658 OP**.
The second is **77.9x** the first.
A live proposal of exactly this type, "Maintenance Upgrade Proposal: OP Mainnet Proposer
Rotation", carries `proposalData` decoding to a 2,000-bps relative threshold. Its against votes at
the read: 4,087.99 OP. Both computations clear that number, so its outcome does not turn on this
difference. What turns on it is the number an organised opposition would have to reach before an
appointment was vetoed.
## What the votable supply is
`votableSupply()` on the governor forwards to a separate contract, `VotableSupplyOracle`
`0x1b7ca7437748375302baa8954a2447fc3fbe44cc`. That contract stores a checkpointed number, not a
computed one: its `owner()` is `0xE4553b743E74dA3424Ac51f8C1E586fd43aE226F`, a Gnosis Safe
proxy, and only that address can write a new checkpoint. The last checkpoint is block
**154,015,822** (2026-07-09 20:53:41 UTC), **22** checkpoints since deployment, value 55,134,630 OP.
The 30% quorum on the live ratification vote is exactly 30% of that number: 16,540,389 OP. The
percentage is governance-set — a proposal type's bps, alterable only through a passed proposal
executed via the timelock. The base is set by a multisig key, not by the token contract. Both
facts are published; neither is a criticism, and this note does not say which arrangement is
better.
## Limits, stated
- The record reports what the approved module **computes today**. It does not say how a future
Council Appointment proposal will encode its threshold, and types 6 and 7 of the configurator
are unset at the read — the type does not exist yet.
- A difference between two published texts of one proposal is recorded as a difference. It is
not a finding about intent, and this note does not say which denominator the proposer meant.
- No definition of "active votable supply" is adopted here. The phrase is quoted, not interpreted.
- Only the two proposals named here were read. This note makes no claim about typical turnout.
- Thresholds are not verdicts. A threshold read is a description of a mechanism at a block, not a
rating, not a recommendation on any proposal, and not advice on how to vote.
## What it is not
This read moves no GSA cell. Verdicts change only through the frozen methodology at a scheduled
re-check, on executed on-chain events. The record is published in the freshness layer as a dated
watch event with impact `may-affect`, subject matter GSA-1 (who holds authority), GSA-2 (who can be
displaced, and by what bloc) and GSA-5 (what a participant is told about the rule being applied).
The first record is at [`data/authority/optimism-council-appointment-threshold.json`](../data/authority/optimism-council-appointment-threshold.json).
---