Append-only · RFC 9162 · root on NEAR
Transparency log
Every receipt AOTrust issues gets a leaf in a cumulative Merkle tree. Every hour, if anything new exists, the current root is committed to the NEAR blockchain (notary-node.near). That makes the log append-only and independently checkable: we can add entries, but we cannot quietly rewrite the past. Don’t take our word for it - the checks below run in your browser.
Check a receipt end-to-end
Paste the PDR from your receipt (base64, 239 bytes) - or open this page from a link that carries ?pdr=. Your browser asks the public API for the verdict and the inclusion path, then folds the path itself (RFC 9162 §2.1.3) and compares the computed root with the one printed inside the receipt. Nothing here is taken on trust: the leaf, the path and the root check all run locally.
Latest anchor (live)
Source: GET https://api.aotrust.link/v1/anchor/status · on-chain: get_root({"seq": anchor_seq})
Incidents
Every anchoring failure we know about, including the ones that were our own fault. Nothing is deleted from this list.
2026-11-07 - 43 hours without a new anchor. Cause: the anchor job derived the next sequence locally (sequence() - 1) while the public RPC was failing (403/408 from drpc, the older mainnet endpoint deprecated), so the transaction went through on-chain but the local record was rejected as a duplicate and the loop kept retrying. Fix: the job now reconciles its sequence with the chain, and two alarms watch anchor writes and anchor transactions. The missing anchor #85 was backfilled from its on-chain transaction; anchors resumed normally.
Since genesis (2026-06-13) - no other anchoring incident. There were outages of the web front end and of individual payment rails along the way; none of them affected the append-only log or receipts that had already been issued.
Protocol epochs & operator identity
The ledger is append-only from genesis (13 June 2026). Early records are the operator’s calibration and rail testing; later ones are external traffic. Nothing was rewritten or removed - the log simply keeps growing, and every anchor commits the root over all leaves.
Operator: - · treasury (Base): - · notary key: - · JWKS
Network pulse (daily snapshot)
A read-only snapshot is generated once a day at 04:20 UTC, alongside the database backup - no live queries on page load, no client identifiers published.
Snapshot: - · source: GET /assets/transparency_stats.json
Verify a receipt yourself
Paste your work_hash (the SHA-256 hex you notarized) and the seq from your receipt. The page fetches the inclusion path, recomputes the leaf SHA256(0x00‖work_hash), folds the path per RFC 9162 §2.1.3 and compares the root - locally, in your browser.
Verify the log wasn’t rewritten
Ask for the consistency proof between two anchors (e.g. from=62&to=63) and check it per RFC 9162 §2.1.4 in the browser.
What this proves - and what it doesn’t
- Proves: a given leaf existed in the log at a given size; the log only grew between two anchors (consistency); the root is on-chain and cannot be altered retroactively.
- Doesn’t prove: that every receipt in the world is published (we could withhold new entries), that a timestamped artifact is correct, or that the notary key wasn’t compromised at signing time.
- Keys: JWKS · did:web · offline verifier in aotrust-skills.
- Raw API: /v1/anchor/status, /v1/anchor/proof/{seq}, /v1/anchor/consistency?from=&to=.