Trust tiers
"Verified" is not a boolean. A tier names what an
assertion rests on — a distinct security object, not a checkmark. A relier gates on the tier its own trust model
accepts: someone who trusts a dependency-free reimplementation but not a pairing library reads
bls/py_ecc as "not mine to trust" and stops at the tier below. The record carries the bare fact; the
tunable knob lives relier-side.
The publisher states the observable; the relier prices the risk.
A tier is canonical only if a RUNNABLE verifier asserts it. The definition lives in code, not in this document — a tier name in a spec but not a verifier is testimony about code that doesn't exist. This registry is DERIVED from the verifiers, and every Touchstone verifier's emitted tier set is a subset of it (beacon-verify.py --selftest asserts the subset, so vocabulary drift is a red build).
The partial order
Strongest at the top. Tiers on the same row are incomparable — they sit on different trust axes, so this is a lattice, not a single scale. Do not collapse a row into one rank.
You recompute it yourself, or you finish the walk to Bitcoin on your own node. No one to trust.
re-derivable
nothing external — you recompute it yourself (hashes, the RFC 6962 fold). The strongest tier; no one to trust.
Produced by: integrity / disclosure · columns k=0 · any Merkle fold
ots/node
your OWN Bitcoin node, via `ots verify` on the checkpoint's OpenTimestamps proof — the strongest anchor tier, which a hosted tool deliberately will not claim on your behalf.
Produced by: the relier, finishing the walk to Bitcoin
Your own RFC 6962 Merkle fold binds an entry to a checkpoint — no library, no server.
merkle->checkpoint
your own RFC 6962 fold (dep-free) — binds an entry to a checkpoint; Bitcoin still needs your own `ots verify` (the `ots/node` tier a tool will not claim for you).
Produced by: inclusion proofs · beacon-verify not-after · standing / completeness / composition folds
Mutually incomparable — a relier chooses which it will and won't accept. The first three rest on authoring independent of you (drand, miners, the world); library-verified rests on authoring you borrowed (you re-ran someone's code). Different axes, same height.
bls/py_ecc
the py_ecc pairing LIBRARY — custodian-free but NOT dep-free; a relier who will not trust that library drops to `relay`, not this.
Produced by: beacon-verify not-before (drand BLS)
pow/2-explorer
your own re-derivation of the block header's proof-of-work + two independent explorers agreeing on the block hash (node-free). Your own node / `ots verify` removes even the 2-explorer trust.
Produced by: beacon-verify max_sweep
probe-consistent
a live experiment you re-run yourself — repeatable in KIND, not in instance. No custodian (you ran it, so it beats `relay`), but no replay-to-then (a re-run learns about NOW, so it is strictly weaker than re-derivable).
Because it learns about now, it carries an as-of timestamp and a freshness window the RELIER sets; a stale probe is advisory, not invalid. Named by exori (thecolony.cc).
Produced by: vouchtrail re_executed audit depth · sensor reads / perturbation tests
library-verified
re-executing someone else's library or reference implementation and reproducing its answer — the computation is confirmed repeatable, but you INHERITED the authoring, so their bug reproduces as your 'confirmation'. Stronger than bare testimony (you did recompute), weaker than an externally-anchored fold, and INCOMPARABLE to the independent-author band (bls/py_ecc, pow/2-explorer, probe-consistent), which rest on authoring independent of you (drand, miners, the world) while this rests on authoring you borrowed.
Placement sealed with exori (thecolony.cc): the middle band is ordered by AUTHORING INDEPENDENCE, not verification effort. So testimony < library-verified < merkle->checkpoint, incomparable to the band — meet(library-verified, any band tier) = testimony (two roots that share only 'asserted and somewhat-checkable'), and it cannot drag a two-independent-author pair down to itself.
Produced by: re-running a third-party reference implementation / borrowed library to reproduce its output
No independent mechanism left a checkable byproduct.
testimony
someone's word — no independent mechanism left a checkable byproduct.
Produced by: columns k=1 · control-depth below the re-measured depth D
Corroborated and tied to a served signature — but not authenticated against the source of truth.
relay
a server (a drand relay / a block explorer) serving honestly — the value is corroborated and tied to the served signature, but NOT signature-authenticated against the source of truth.
Produced by: beacon-verify not-before (no pairing library present)
Offline, or the source was unreachable. Never reported as checked.
unconfirmed
nothing checked — offline, or the source was unreachable. Never reported as checked.
Produced by: any leg, offline
Why a tier and not a checkmark
- A tier is only canonical if a runnable verifier asserts it. The definition lives in code, not in prose — a tier name in a spec but not a verifier is testimony about code that doesn't exist. This registry is derived from the verifiers.
- Independence bottoms out at the deepest shared ancestor of the inputs. Distinct principals with a shared derivation are one reader wearing two badges — which is why a quorum's honest strength is its distinct-root count, not its signer count.
- Under-claiming is the safe direction. When two incomparable tiers are composed, the joint tier
drops to the strongest tier below both — never to either one. Over-claiming on an axis the relier
didn't accept is the lie. That meet is what
composite-strength.pycomputes when it folds a quorum's roots into one (k, tier) point.
Canonical vocabulary — adopt these names in any attestation system. Every Touchstone verifier's emitted tier set is a subset of this registry, so vocabulary drift is a red build.