# What a determination was read against
A determination is a statement that specific governance rights are held or enforced in a specific
way at a stated date. For most of this universe that statement rests on a contract we read. Until this
surface existed, the feed told a reader the verdict and the date but not the address, so the read
could not be repeated.
The anchor surface closes that gap, and its coverage figure is a statement about this product rather
than about the DAOs in it.
## Three kinds of anchor
- **contract anchor** — a governance contract is named, with the chain and the block at which its
runtime bytecode was read, and the role it plays is asserted by a record we publish. A reader can
repeat the read.
- **venue only** — no governance contract is named. The anchor is the place proposals are recorded:
a Snapshot space or an OpenSquare space. A venue records intent. It cannot refuse, delay or execute
a transfer, so a verdict anchored here cannot be re-derived from a bytecode read.
- **described venue only** — a venue is named in prose in the dataset (an executive-vote portal, a
validator ballot, a chain's native governance) and no address has been pinned to it yet.
## Coverage, as published
Of 53 determinations, **8 (15.1%) name the contract a governance action executes through**:
| DAO | Chain | Contracts named |
|---|---|---|
| ENS | Ethereum | Governor, Timelock (2-day `getMinDelay`) |
| Compound | Ethereum | Governor (proxy), Timelock |
| Arbitrum | Arbitrum One | Core governor, Treasury governor |
| Optimism | OP Mainnet | Governor |
| Sky (MakerDAO) | Ethereum | Chief, DSPause |
| Rocket Pool | Ethereum | pDAO proposal contract |
| Kyber | Ethereum | KyberDAO governance contract |
| Aave | Ethereum | Governance Core |
The other **39 rest on a proposal venue** and **6 on a venue described in prose**. No determination
in the universe is anchored to nothing.
That split is worth stating plainly: the standards claim to verify mechanism, and for 15% of the
universe the mechanism is a contract we can point at. For the rest the mechanism is a venue plus
documents. Both are useful readings, and they are not the same reading.
## An anchor is a moving object
Two live cases show why an anchor carries a block and not just an address.
**ENS is voting on a replacement.** Snapshot proposal `0x5bc7802…3627a` in `ens.eth`, `[7.3] [Social]
Governor Nexus Update`, closes 2026-11-03 18:15:08Z, approving a governor on OpenZeppelin v5.6.1. At
read time it carried 16,828.02 ENS for, 0 against, from 39 ballots — 3.37% of the 500,000 ENS
opposition threshold the same proposal introduces on its Optimistic proposal type, and 16.8x the
1,000 ENS bond its Bond type requires. The proposal states "The Timelock is untouched"; the admin
transfer is a later step. The anchor therefore stays `0x323A7639…b7e3` until a migration proposal
executes. It is not untouched forever, and the record says what would move it.
**Arbitrum's quorum is not one number.** ArbitrumDAO runs two governor contracts. The core governor
applies a 5000/10000 numerator, clamped to 150M–450M ARB; the treasury governor applies 4000/10000,
clamped to 100M–300M. Neither exposes a quorum constant, so quorum is computed per timepoint. At the
two live ballots' snapshot blocks the figures were 151,764,791.05 and 121,414,208.74 ARB — 30,350,582
ARB apart. The same 12,509,608.37 ARB of support is 10.30% of the treasury quorum and 8.24% of the
core quorum. A quorum figure quoted without the governor it belongs to is ambiguous by that much.
## How to use it
```
curl -s https://probity-institute.pages.dev/data/anchors/anchors.json | jq '.rows[] | select(.slug=="ens")'
```
Then repeat the read the row names:
```
curl -s -X POST https://ethereum-rpc.publicnode.com -H 'Content-Type: application/json' \
-A 'Mozilla/5.0' \
-d '{"jsonrpc":"2.0","id":1,"method":"eth_getCode","params":["0x323A76393544d5ecca80cd6ef2A560C6a395b7e3","latest"]}'
```
A non-empty result is bytecode present now. Compare the length against `code_bytes` in the row, and
read `verified_block` to know when the row's own read was taken. A public RPC endpoint that rejects a
plain client user-agent will reject the call: send a browser user-agent header, as above.
## Limits
- Bytecode presence proves a contract exists at an address. It does not prove the contract holds the
role the row asserts. That assertion comes from the cited record, which is published and can be
checked line by line.
- A contract anchor names one contract, not every power centre. Where a DAO also runs a foundation, a
security council or a multisig, those are separate reads in separate records.
- Roles are read at a block. Contracts are upgraded, governors replaced and timelocks re-pointed. The
`succession_watch` block states what is in flight where we know of it; it is not a guarantee that we
know of everything.
- Chain attribution comes from where the read succeeded. A deterministic deployment can place the same
address on several chains; the row names the chain the record reads.
- A venue anchor is not a weaker version of a contract anchor. It is a different object. Snapshot
spaces hold signals; the vote that binds execution is on chain.
## What this surface is not
Not advice, not a recommendation on any proposal, not a statement that a contract is well built, and
not a security rating. It is an index of what was read, published so that the reading can be checked.
---