Witness directory
A witness is a SCITT Transparency Service that registers checkpoints under a published consistency policy and returns a Receipt anyone can check offline. The list below is alphabetical by name and ordered by nothing else.
A Receipt shows that the checkpoint is included in that service’s log. It does not mean the service agrees with anything the checkpointed log contains.
A checkpoint is witnessed more than once when it carries receipts from more than one operator. How many it needs is the verifier's choice: a policy such as “two receipts, from two different operators”, applied to the receipts that verify. No row is privileged: the reference verifier reads every row’s keys the same way and has no key built in for any service. A verifier chooses which directory to use, and so which keys it accepts; being listed here is not that choice made for you.
| Name | Endpoint | Binding | Receipt grades | Key ids | Since |
|---|---|---|---|---|---|
| rekor.sigstore.dev | https://rekor.sigstore.dev | Rekor dsse entry | countersigned-observed | c0d23d6ad406973f… | 2022-10-25 |
| witness.agentactioncapsule.org | https://witness.agentactioncapsule.org | CLL POST /checkpoints | the service's own label, if any: countersigned-observed or mmr-verified | 39bb654c9dc0afe1… | 2026-06-28 |
What a receipt grade says
countersigned-observed | The service verified the checkpoint’s signature and registered these exact bytes. It did not check the checkpoint against an earlier one from the same log. The name is the identifier the service emits in its Receipts; despite the word, it is not a second party’s countersignature or co-signature: it records only what this one service checked. |
|---|---|
mmr-verified | The log is enrolled with the service, under a pinned key, as a native CLL log: an accumulator the service can check consistency proofs against. The checkpoint’s signature verified under that key. A checkpoint that carries a consistency proof is registered only if the proof shows it extends the last checkpoint the service accepted for that log. The label itself does not say a proof was checked (the JSON form of a checkpoint never carries one); that is reported separately, as the continuity grade continuity-witnessed. The service does not hold the log’s entries and does not rebuild its tree. |
The grade is a label the service puts in its own Receipt, and a verifier reads it only from a Receipt that verifies. It says what that one service checked. Some Receipts carry no grade: the reference witness, capsule-anchor, grades only checkpoints from logs enrolled with it, mmr-verified for a native CLL log and countersigned-observed for a foreign one whose accumulator it cannot check, and never checks a consistency proof for a foreign log.
A grade is not a refusal. Under the published policy, a checkpoint from a log the service has never seen registers without a consistency check, because there is nothing yet to be consistent with. A later checkpoint that carries no consistency proof can also register, at a lower grade than one whose proof was checked, unless the service is set to refuse it. A checkpoint whose proof does not verify is refused.
A Rekor entry is always countersigned-observed: Rekor records that the bytes existed, signed by the log’s key, at Rekor’s integrated time, and never checks the log’s consistency.
Using more than one
With capsule-emit, the binding is the URL's scheme, so one setting takes all three:
export CAPSULE_WITNESS_URL="https://witness.example,rekor+https://rekor.sigstore.dev,scrapi+https://ts.example"Each checkpoint goes to each witness independently. One failing never blocks the others, and a failed one is retried later from the log itself.
Adding a row
Open a pull request that adds one row to witnesses.json ↗ in capsule-emit, using its directory-row template. The fields are described in the schema ↗.