The public ledger

The live, publicly reachable surface of linkex.ai's Open Tally ledger — eight endpoints, no account required.

Everything a verifier needs from the operator is served publicly by the production gateway. No account, no API key. Errors are self-explaining: a 4XX response body names the parameter to fix rather than returning an opaque "internal error."

Endpoint	Gives you
`/api/receipt/commitments`	the signed period-commitment ledger (`include_tokens=1` adds the RFC 3161 tokens)
`/api/receipt/keys`	the signing-key history, scoped by sequence range
`/api/receipt/bundle`	a single-receipt evidence bundle (`stream`, `seq`)
`/api/receipt/period`	a period proof with deterministically sampled receipts (`stream`, `sample`, optional `first_seq`/`last_seq`)
`/api/receipt/commitment-blocks`	stalled streams and why — a ledger showing only successes would make stalling look like quiet
`/api/anchor/transparency`	the on-chain anchor ledger (`include_entries=1` discloses each window's entry list)
`/api/anchor/stats`	anchor totals, including `earliest_window_start_ms` — where on-chain coverage begins
`/api/anchor/spec`	the anchoring specification, verbatim (`?version=` for historical versions) — hash it to reproduce the on-chain `spec_hash`
`/api/anchor/page`	the human-readable transparency page, with the full self-check procedure in its footer

`GET /api/receipt/keys`

The signing-key history: for each stream, the Ed25519 public keys with their half-open validity ranges (from_seq / until_seq) and retirement reasons.

curl -s https://linkex.ai/api/receipt/keys

{
  "data": {
    "issuer": "linkex.ai",
    "records": [
      {
        "key_id": "ed25519:3d1aa5da8d32…",
        "stream": "ch:3",
        "public_key": "JgbnqHcMguWJ5O9/cs4uUmJo757gPT3f+YHlObW9zw0=",
        "from_seq": "1",
        "until_seq": "",
        "retired_reason": ""
      }
    ]
  }
}

Check 1 (signature validity) validates every receipt against this published history — a signature from a key not valid for that stream and sequence range fails, even if the signature itself is mathematically sound. The key_id is a recomputable fingerprint of the key beside it, so the history cannot name one key and publish another.

`GET /api/receipt/commitments`

The signed period-commitment chain — the ledger's public spine, served in canonical form (the exact object that was hashed, decimal strings and all):

curl -s 'https://linkex.ai/api/receipt/commitments?page_size=1'

{
  "data": [
    {
      "commitment": {
        "spec": "linkex.period-commitment",
        "spec_version": "1",
        "issuer": "linkex.ai",
        "stream": "ch:10",
        "from_ms": "1788570074617",
        "until_ms": "1788570434593",
        "first_seq": "1",
        "last_seq": "5",
        "count": "5",
        "root": "sha256:4c165425c120…",
        "prev_commitment_hash": "sha256:0000…",
        "key_id": "ed25519:3d1aa5da8d32…"
      },
      "hash": "sha256:6572a1f3124a…",
      "signature": "ihHjOrnLjfQ9…",
      "tsa_status": "obtained",
      "tsa_time_ms": 1788652559000,
      "tsa_authority": "CN=DigiCert SHA256 RSA4096 Timestamp Responder…",
      "tsa_url": "http://timestamp.digicert.com"
    }
  ],
  "total": 192
}

The protocol invariants are visible right in the payload: numbers carried as strings, first_seq/last_seq/count fixing the window's extent, prev_commitment_hash chaining periods, the whole object signed — and each commitment carrying its timestamp-token status in the open.

`GET /api/receipt/bundle` and `/api/receipt/period`

The two proof endpoints. bundle returns everything needed to verify one receipt offline (the receipt with predecessor and successor, key history, covering commitment, Merkle proof); period returns a commitment-chain proof plus receipts drawn by the published sampling rule — the seed is in the response, so the draw is recomputable. See the verification guide for the full workflow.

`GET /api/receipt/commitment-blocks`

The honesty endpoint: streams whose commitment building is currently blocked, and why. A transparency surface that only displays successes would make a stalled channel indistinguishable from a quiet one — so stalls are published too. An empty list means nothing is stalled.

`/api/anchor/*` — the on-chain leg

A live record from /api/anchor/transparency:

{
  "window_start_ms": 1788930000000,
  "window_end_ms": 1788933600000,
  "row_count": 7,
  "data_root": "26770aa06c76624a…",
  "spec_version": "v2",
  "spec_hash": "3103baf64bd4c8af…",
  "prev_anchor_hash": "a422fdfce7d771ac…",
  "payload_hash": "615d2cad73879b8f…",
  "status": "confirmed",
  "chain_network": "eip155:8453",
  "tx_hash": "0xddecf7390d3cebdefd62f9bf6216424c4eeb50de4e0f297864032ef126c9d34c",
  "block_number": 51072548
}

Every field is checkable: fold the window's entries (add include_entries=1) to reproduce data_root; hash /api/anchor/spec to reproduce spec_hash; rebuild the payload to reproduce payload_hash; open tx_hash on any Base explorer and compare the 32-byte calldata; and confirm prev_anchor_hash links to the previous window, so no window can vanish silently. The anchoring page walks all five steps.

/api/anchor/stats reports totals and earliest_window_start_ms — commitments issued before that moment carry RFC 3161 timestamps but predate on-chain coverage, a stated boundary.

Machine-readable docs

Like the main docs site, every page here is available as raw Markdown — see /llms.txt for the index and /llms-full.txt for the full corpus.

GET /api/receipt/keys

GET /api/receipt/commitments

GET /api/receipt/bundle and /api/receipt/period

GET /api/receipt/commitment-blocks