Try it now
Each of these runs in your browser against the live service. None needs an account.
Check the signed ledger head
Fetch the current head. Your browser checks its ES256 signature against our published keys at /.well-known/jwks.json and confirms the signed fields match the document. Save the head and its anchor count somewhere you control, then compare them on a later visit.
Check a token
Paste an ID or access token Obelisk issued, and our public MCP tool server checks its signature against our published keys: the same verify_token call an AI agent makes. The token is sent to us, so use one you no longer need. To check without contacting us, verify it with any JWT library against /.well-known/jwks.json.
Check that a receipt is in the ledger
Paste a receipt hash (from an organization's governance timeline or an agent's activity), or use the newest anchored receipt. Your browser recomputes the Merkle proof itself with WebCrypto. The root it checks against is computed by us when you ask and isn't part of the signed head yet, so a match shows the receipt is in the ledger we serve today. Sign-in records are kept in a separate ledger that this check doesn't search; yours is on your identity ledger page.
What you can check, and what you can't yet
What you can check today, without an account
- Save the signed ledger head, and compare it later. Fetch
/.well-known/obelisk-transparency.jsonand keep itsheadAnchorHashandanchorCount. On any later fetch the count must never go down, and while the count is the one you saved, the head must not change. A break in either rule is evidence the record was cut short or replaced. - Check that the head was signed with our key. The document's
sthfield is an ES256 signature over the head. Verify it against our published keys at/.well-known/jwks.json; the head check on the Verify it yourself page does this in your browser. - Check that a receipt you hold is in the ledger. Paste its hash into the receipt check on the Verify it yourself page. Your browser recomputes the Merkle proof from
/api/proof/<hash>, and a match shows the receipt is in the ledger we serve today. The check searches the receipts ledger; sign-in records are kept in a separate ledger it doesn't search. - Check a token we issued. Verify an ID or access token's ES256 signature with any JWT library against
/.well-known/jwks.json. Once you have the keys, that check needs nothing more from us.
What those checks can't show yet
- That a later head extends the one you saved. We don't publish consistency proofs between heads, and we don't serve past heads, so comparing heads catches a history that was cut short or replaced, not one that was rewritten and then extended with new entries.
- That a receipt check is covered by the signature. The root a receipt proof is checked against is computed by us when you ask and arrives in the same response. It isn't part of the signed head yet.
- That our keys and our records are honest. You fetch the signed head and the keys that verify it from us, so a valid signature shows the head was signed with the key we publish, not that what it describes is complete.
- That nothing happened without a record. The ledgers show what the service recorded, not what it didn't. Sign-in records are written on a best-effort basis, so a failed write doesn't block a sign-in.
- That someone outside holds the same head. Whether an outside copy of the head is verified is shown live on the status page. While none is, the copy you save is the outside record.
Two more checks
| What | Where | What it shows |
|---|---|---|
| A site's Obelisk seal is real | Seal check | The seal resolves to a registration entry, or it says plainly that it does not. |
| An agent's claims | Proof Links | Independent, individually scoped claims with freshness — never a single "this is not a human" verdict. |
What these proofs deliberately do NOT claim
An honest proof states its own limits, so here are ours in plain terms. A receipt shows an action was recorded — it does not show the action was wise. A head you saved catches an anchor count that went down, or a head that changed while its count stayed the same, between your two fetches — it does not show that history only grew, and it says nothing about what happened before you first saved one. An agent Proof Link shows specific, individually scoped claims — key control, an accountable owner, workload evidence — and never that a counterparty is not a human, that autonomy is permanent, or that a system is free from compromise.
We publish these boundaries because a proof that overclaims is worse than no proof: it moves the trust you withdrew from the vendor onto an artifact that cannot carry it.
The honest operator boundary
Obelisk runs on infrastructure Obelisk controls. An operator with access to the server is inside the trust boundary of anything that isn't checked outside it — which is why receipts chain to a fixed genesis, why the ledger head is signed and published for you to save, and why a token can be verified on your own machine against our public keys. Read what we can and can't do for what that does and does not cover.
Go deeper
The full security posture · How trust is established · Live head and outside-witness state · Build against it