Lineage proofs verify offline — an unbroken chain of signatures back to a human root. But a proof cannot prove the negative: that the root was ever registered, that nothing in the chain has been revoked or superseded since, or that the answer is final. That answer is authority, and it comes from an anchor backend: a blockchain, a transparency log, or an institutional notary.

​
The seam: LineageAnchor

The backend is pluggable through one small trait. Every backend — Sigil’s GAL, an EAS attestation chain, a certificate transparency log — implements the same read-only shape:
  • check_revocation(did) — revocation-first: is this subject revoked?
  • get_hmr / get_mhr / get_enr(did) — the typed root anchor, if any
  • get_org_root(org_did) — the org’s Merkle lineage root (optional)
  • current_finalized_block() — the backend’s finalized height
Verifiers never depend on a specific chain. They depend on the seam.

​
Anchor references in the document

A lineage section may carry anchorRefs naming the backends the registration was anchored to:
  • scheme names the backend: sigil, eas, ctlog, or a future registered name. Unknown schemes are additive, never breaking — a verifier ignores schemes it does not support rather than rejecting the document.
  • locator addresses the record within the backend: a transaction hash (sigil), an attestation UID (eas), a log-id:index (ctlog).
  • inclusionProof binds the locator to the backend’s canonical root. Self-proving schemes (EAS) carry none; batch-Merkle schemes require one.
The display form is anchor:<scheme>:<locator>. Full schema: specification section 9.2.1.

​
The verifier’s anchor policy

Which schemes a verifier requires is policy, not document content:
The dispatcher checks each trusted backend in preference order: revocation-first, root-kind anchoring, active-status requirement, and finality confirmation (an anchor recorded beyond the finalized block is unconfirmed and rejected). The first trusted backend whose anchor confirms wins. No trusted confirmation means fail closed — a misconfigured or unreachable anchor never presents as ordinary failure, because it cannot prove the negative.

​
The backends

​
Sigil (reference)

Sigil’s Global Authority Ledger is the reference backend and the home of the lineage economics: typed edges, root anchors, org lineage roots, revocation-first RPC, shard topology, publisher bonds, and generation-decay rewards. The production adapter (mars-protocol::SigilAnchorClient → LineageAnchor) lives in sigil-sdk.

​
EAS

The Ethereum Attestation Service is the first foreign anchor. Root anchors are attestations under the OAS lineage schema (string did,string kind,string status,string metadataCommitment,uint64 anchoredAtBlock), addressed to a deterministic per-DID recipient (blake3(did)[0..20]), newest supersedes oldest. Resolution via EAS GraphQL plus JSON-RPC finality (oas-anchor-eas in Rust, @openagentid/anchor-eas in TypeScript, which also publishes via the maintained EAS SDK). Org roots are not modeled on EAS in v1.

​
The cost pattern: batch-Merkle

Per-registration chain writes do not scale. Publishers batch: collect an epoch’s registrations, build a Merkle tree, publish the root once, and give every registration its inclusion path in its anchorRef. One write commits the epoch; every event verifies offline against it. The full operational pattern is in ANCHORING.md (in the oas repository), covering epochs, finality arithmetic, revocation-by-supersession, and why proofs must never live server-side.

​
The rules

  1. Proofs offline, authority anchored. Never confuse the two.
  2. Trusted schemes are verifier policy. Documents declare anchors; verifiers choose which they trust.
  3. Unconfirmed is not authoritative. An anchor beyond the finalized block is rejected until confirmed.
  4. Fail closed on authority. An unreachable anchor means no, never maybe.

​
Next