orb(trust): external decision-ledger anchoring — Rekor + git-commit, from tamper-evident to tamper-proof

[JSONbored]

Context

migrations/0180_decision_ledger.sql (#8843) shipped a hash-chained, append-only decision ledger and named its own honest limit up front: tamper-evident, not tamper-proof — an operator can still delete the chain wholesale and re-chain from genesis undetected, because nothing outside the operator's own database holds an independent record of any past tip. buildLedgerAnchorPayload (src/review/decision-record.ts:376) was written for exactly this and has been called from nowhere since. #9186's verification matrix and #9215's eval-interface spec both now state this gap in public-facing terms, which is what surfaced it as blocking.

Decision: which anchoring mechanisms to use, and why (research complete — see linked comment)

Full mechanism research (Rekor v2, CT/tlog-tiles + witness networks, Bittensor on-chain commitment, OpenTimestamps, git-commit anchoring) is posted as a decision-record comment on this issue. Summary:

• Ship Rekor v2 (hashedrekord) + git-commit anchoring together, as complementary primary mechanisms. Both are free, need no new runtime dependencies (Rekor: one fetch + crypto.subtle ECDSA P-256, already native to Workers; git: reuses the existing GitHub App auth), and both are independently offline-verifiable or third-party-mirrored (GH Archive, Software Heritage).
• Add OpenTimestamps as a backstop, not a primary — free, needs zero trusted party at verification time, but hours of latency and the weakest verifier UX (needs Bitcoin block data).
• Defer tlog-tiles + witness-network anchoring — the strongest possible guarantee (genuine non-equivocation, defeats split-view/rewind) but requires either a Go sequencer or a hand-rolled implementation. Revisit exactly when migrations/0180's own stated trigger fires: when tenants exist.
• Add Bittensor on-chain commitment as a fourth, optional backend — corrected after maintainer input (see comment below). Not disqualified: the "needs a trusted archive" concern is only a real problem if the archive belongs to someone else, and LoopOver's operator already runs dedicated node infrastructure for other purposes — querying their own archive for historical commitments is the same trust posture as the git-commit backend already accepts (GitHub is a trusted third party too; we just control the repo). Signing runs on that existing node infrastructure, not inside the Cloudflare Worker, using a dedicated hotkey managed as an operational secret exactly like every other credential this app already handles at runtime (never committed to the repo) — so it doesn't conflict with the house rule against committing wallets/hotkeys, and it sidesteps @polkadot/api's Node-orientation entirely since it never needs to run in Workers. Scope: this is bonus corroboration for Gittensor/SN74-registered participants specifically, not a universal verification step — a repo owner or contributor with no Bittensor involvement has no reason to check it, so Rekor + git-commit remain the default every verifier is told to check; the on-chain anchor is additional, clearly-labeled-optional signal for the audience that already trusts subtensor.

Requirements (decomposed into sub-issues below)

1. Row-lookup endpoint binding an anchored hash back to the live chain (the property that actually delivers tamper-proofness — without it an anchor proves a hash existed, not that it's this chain's hash at that seq)
2. Versioned, signed anchor payload + key management
3. Anchors persistence (including recording failed attempts publicly, so anchoring cannot be silently made to fail)
4. Rekor v2 backend
5. Git-commit backend
6. Scheduling: checkpoint cadence, not per-record
7. Bittensor on-chain commitment backend (optional, Gittensor-audience-specific)
8. Docs: update the tamper-evident framing once anchoring ships, including the on-chain option's scope

Expected outcome

migrations/0180's own stated gap closes: an operator who deletes the ledger and re-chains from genesis produces anchors that independently and publicly fail to match, for every anchor already published.

maintainer-only — ledger/trust-boundary infrastructure.

[linear-code]

JSO-6431

[JSONbored]

Mechanism research (decision record)

0. What's in the repo today

• The chain: src/review/decision-record.ts:309-479. ledgerRowHash = SHA-256(prevHash || canonicalJson({seq, recordId, recordDigest, createdAt})); appendDecisionLedger (:330); verifyDecisionLedger (:393) already returns {tipSeq, tipHash, totalCount} on every call; buildLedgerAnchorPayload (:376) returns {seq, rowHash, at} and is called from nowhere.
• Public verify route exists: GET /v1/public/decision-ledger/verify (src/api/routes.ts:1280; OpenAPI src/openapi/spec.ts:1001).
• Cron is already wired: wrangler.jsonc:382 → "crons": ["*/2 * * * *"], dispatched in src/index.ts:116 with hour/minute/day gating. An anchoring job needs no new infra.
• Bindings available: DB (D1), R2 buckets REVIEW_AUDIT + VISUAL_CAPTURE_PUBLIC, queue JOBS.

On-chain capability today: none. Every Bittensor touchpoint is read-only HTTP (src/review/content-lane/netuid-verification.ts:166 taostats API; src/gittensor/api.ts:7 gittensor.io). package.json has no @polkadot/*, no sr25519, no SCALE codec. hotkey appears only in src/review/secret-patterns.ts:68 as a redaction/secret-scan pattern.

---

1. Sigstore Rekor v2 — RECOMMENDED (primary)

Rekor v2 GA'd 2025-10-10, tile-backed, shards annually (log2025-1, log2026-1). The public-good rekor.sigstore.dev stays v1 as the default for the foreseeable future; clients must not hardcode log URLs.

A plain hash + metadata is exactly what hashedrekord is for — content-agnostic, Rekor never sees the artifact.

v2 request (POST /api/v2/log/entries):

{"hashedRekordRequestV002": {
  "digest": "<base64 sha256 of the canonical anchor payload>",
  "signature": {
    "content": "<base64 signature over the payload bytes>",
    "verifier": {"publicKey": {"rawBytes": "<base64 DER SPKI>"}, "keyDetails": "PKIX_ECDSA_P256_SHA_256"}
  }
}}

verifier.publicKey means no Fulcio, no OIDC — a self-managed long-lived key is accepted. ECDSA P-256 + SHA-256 is native crypto.subtle in Workers. Zero new dependencies, one fetch.

Response is a TransparencyLogEntry: logIndex, logId.keyId, kindVersion, inclusionProof (hashes + signed checkpoint), canonicalizedBody — store the whole thing, it's a self-contained offline-verifiable proof. integratedTime is always "0" in v2 (ignore it; TSA is separate now).

Cost/limits: free. 99.5% SLO with on-call. 100 KB upload cap (payload is ~200 bytes). No published rate limit (read-path limiting still open, rekor-tiles#355). v2 batches — set request timeout ≥ 20s.

Verification: rekor-cli verify --rekor_server <shard> --uuid <uuid>, or fully offline (verify checkpoint signature against the sigstore trust root, verify Merkle inclusion, check digest == sha256(payload)) — no network access to us required.

Caveats: annual shard rotation means persist the shard base URL + logId.keyId alongside every anchor. No stated retention guarantee for frozen shards — mitigated by storing the full inclusion proof + checkpoint ourselves. It's a donated public good; anchor on a checkpoint cadence, not per-record.

Trust bought: a third party's append-only, monitored, witnessed Merkle log holds a timestamped commitment to your tip. You cannot retroactively insert into it.

2. CT / Trillian-style tlog-tiles + witness network — DEFER

Real CT logs need an X.509 chain to a browser-trusted root — not usable here. The modern tlog-tiles/static-ct-api + witness cosigning (c2sp.org/tlog-witness) is genuinely the strongest design: a tiled log is just flat files (maps onto our existing R2), and witness cosigning defeats split-view/rewind — the actual "cannot re-chain from genesis" property, stronger than a single timestamp. The Witness Network is real and free (TrustFabric's ArmoredWitness fleet, ~15 devices; onboarding is a small policy PR); Filippo Valsorda's transparent-keyserver reports <500 LOC and <1s added latency.

Why not now: the reference implementation (Tessera) is Go — our sequencer would be a second service outside Workers, or a hand-rolled tlog-tiles. Monitors currently must download the whole log (verifiable indexes targeted before end of 2026). Highest effort, highest ceiling. Revisit exactly when migrations/0180's own stated trigger fires: when tenants exist.

3. Bittensor on-chain commitment — DISQUALIFIED

pallets/commitments, extrinsic set_commitment(netuid, CommitmentInfo). Data::Sha256 (32 bytes) fits our rowHash trivially. Gated on a hotkey registered on that netuid (CanCommit). Rate limit: MaxSpace 3100 units/epoch, 100-unit floor per commitment → ~31/epoch (epoch ≈ 72 min) — fine for hourly anchoring.

Disqualifying facts:

• CommitmentOf is a map overwritten in place — only the latest commitment per (netuid, account) survives in chain state. History lives only in block bodies/events, so a verifier needs an archive node or taostats — a trusted third party again, buying nothing over Rekor/git.
• Requires a registered hotkey's signing key live in Worker secrets — directly conflicts with this repo's own house rule against wallets/hotkeys in the codebase. Also needs sr25519 + SCALE encoding + RPC submission from a Worker; @polkadot/api is Node-oriented and heavy.

4. OpenTimestamps — backstop, not primary

POST /digest (max 64 bytes) to a free public calendar (alice.btc.calendar.opentimestamps.org et al., no API key), get a partial timestamp; later GET /timestamp/<hex> to upgrade once the calendar's aggregated Merkle root lands in a Bitcoin OP_RETURN. Live stats: ~8.4h average between calendar transactions, 21k+ pending commitments typical.

Cost: zero (calendar pays the sats). Implementation: skip the Node/browserify-oriented opentimestamps npm package — POST /digest + store the raw response blob is a ~30-line wrapper.

Trust bought: the strongest "existed before block N" claim available, no trusted party at verify time. Verification is the weakest of all five — needs a Bitcoin block-header source (full node or explorer); an anonymous auditor with only curl cannot complete it alone.

5. Git-commit anchoring to a public repo — RECOMMENDED (secondary, complementary)

Cheapest option, and we already have the credentials (GitHub App installation tokens, @octokit/core already a dependency). Append to anchors.jsonl in a public repo via the Contents API.

Alone, this is weaker than everything above — GitHub is a trusted third party, git push --force rewrites it. But it's much stronger combined with independent mirrors we don't control: GH Archive records the public GitHub event stream (PushEvents) into hourly gzipped JSON, still active in 2026; Software Heritage "Save Code Now" archives public git repos on demand via a free API, typically crawled within hours. A rewrite becomes detectable by a third party checking an archive we can't reach.

Verification: the best of all five — git clone, git log, or a browser. Zero crypto literacy required.

---

Recommendation, ranked, for this system

#	Mechanism	Trust bought	Ops cost	Verifier UX
1	Rekor v2	Timestamped commitment in a third-party monitored log; offline-provable	One fetch + one WebCrypto key, zero deps	rekor-cli/cosign, or fully offline
2	Git commit + public mirrors	Trusted-third-party record, independently mirrored (GH Archive, Software Heritage)	Reuses existing GitHub App auth	git log
3	OpenTimestamps	Bitcoin PoW, zero trusted party at verify time	~30 LOC, free	Needs a Bitcoin node/explorer
4	tlog-tiles + witnesses	True non-equivocation	Go sequencer or hand-rolled; highest effort	Standard tlog clients
5	Bittensor commitment	State overwritten; needs archive anyway	Hotkey in secrets — violates house rule	Needs archive RPC

Ship 1+2 together now. Add 3 as a backstop. Defer 4 to the tenant trigger. Do not build 5.

Cadence: checkpoint, not per-record

Anchor hourly, but skip if tipHash is unchanged since the last anchor (idempotent, free on quiet days) — and also anchor immediately if tipSeq has advanced by ≥256 since the last anchor, bounding the unanchored window by both time and record count. ~24 anchors/day worst case. A wholesale rewrite can then only erase history back to the last anchor — at most one hour or 256 records.

Anchor payload

Extend buildLedgerAnchorPayload to a self-describing, versioned shape (it currently can't survive being read by a stranger in two years):

{ v: 1, ledger: "loopover.decision_ledger", seq, rowHash, totalCount, at }

Canonical-JSON it (reuse canonicalJson), sign with ECDSA P-256 via crypto.subtle using a Worker-secret key; publish the SPKI public key (with rotation history) at a stable public route.

Persistence

New migration, decision_ledger_anchors: seq, row_hash, payload_json, signature, backend ('rekor'|'git'|'ots'), backend_ref, proof_r2_key, status ('ok'|'failed'), error, created_at.

Two non-obvious requirements:

• backend_ref for Rekor must store {shardBaseUrl, logIndex, logIdKeyId, uuid} — the annual shard rotation makes a bare logIndex unresolvable later.
• Record failed anchor attempts as rows, and expose them publicly. If anchoring silently fails open (it must not block a review), an operator could make every anchor "fail" silently. A public, gap-visible attempt log is what closes that hole.

The single most important piece

An anchor is only useful if a verifier can bind the anchored rowHash back to the live chain. Today verifyDecisionLedger returns only the tip and the first break — there is no way to fetch the row at seq N and recompute its hash. Without that, an anchor proves a hash existed, not that it's this chain's hash at that seq.

Add GET /v1/public/decision-ledger/row/:seq → {seq, recordId, recordDigest, prevHash, rowHash, createdAt} (all already public-safe under the type's own contract). This is what actually delivers "cannot re-chain from genesis": a re-chained ledger produces a different rowHash at every anchored seq, and every anchor then fails independently and publicly.

What the verifier runs

curl -s https://<host>/v1/public/decision-ledger/anchors > anchors.json
curl -s https://<host>/v1/public/decision-ledger/anchor-key > pub.der

# Rekor inclusion (online or fully offline from the stored TransparencyLogEntry)
rekor-cli verify --rekor_server https://log2026-1.rekor.sigstore.dev --uuid <uuid> --artifact-hash <sha256(payload)>

# Git anchor + independent mirror cross-check
git clone https://github.com/<owner>/loopover-anchors && git log --patch
curl -s https://data.gharchive.org/2026-07-27-14.json.gz | gunzip | grep <repo>

# Bind the anchor to the LIVE chain — the step that matters
curl -s "https://<host>/v1/public/decision-ledger/row/<anchored seq>"
# recompute SHA-256(prevHash || canonicalJson({seq,recordId,recordDigest,createdAt})) and compare

# Walk the chain itself
curl -s "https://<host>/v1/public/decision-ledger/verify?afterSeq=0"

Sources: Rekor v2 GA · Rekor evolution / v1 stays default · rekor-tiles CLIENTS.md · Rekor docs · rekor types.md · rekor-tiles#355 · Sigstore public-good instance · Sigstore TSA · C2SP static-ct-api · C2SP tlog-witness · Building a Transparent Keyserver · Can I Get A Witness (Network)? · Tessera · subtensor commitments pallet · Bittensor chain rate limits · Bittensor fees · OpenTimestamps · opentimestamps-server · catallaxy calendar stats · GH Archive · Software Heritage Save Code Now

[JSONbored]

Decomposition

Dependency-ordered, per the mechanism research above:

1. ledger: GET /v1/public/decision-ledger/row/:seq — bind an anchor back to the live chain #9269 — GET /v1/public/decision-ledger/row/:seq — the piece that actually binds an anchor back to the live chain. Build first; nothing else here matters without it.
2. ledger: versioned + signed anchor payload, public key + rotation route #9270 — versioned + signed anchor payload, public key + rotation route
3. ledger: anchor persistence + public attempt log (success and failure both visible) #9271 — anchor persistence + public attempt log (success and failure both visible)
4. ledger: Rekor v2 hashedrekord anchoring backend #9272 — Rekor v2 hashedrekord backend (primary)
5. ledger: git-commit anchoring backend, cross-verified against GH Archive / Software Heritage #9273 — git-commit backend, cross-verified against GH Archive / Software Heritage (secondary, complementary)
6. ledger: scheduled checkpoint anchoring — hourly or every 256 records, whichever first #9274 — scheduled checkpoint anchoring (hourly or every 256 records, whichever first) — ties 2-5 together
7. docs: update the verification contract once ledger anchoring ships #9275 — docs update once anchoring ships, so the published verification contract never lags reality

Deliberately not built: Bittensor on-chain commitment (set_commitment) — disqualified on two independent grounds: chain state is overwritten in place so a verifier needs a trusted archive anyway, and it requires a hotkey signing key live in Worker secrets, which conflicts with this repo's own house rule against wallets/hotkeys in the codebase.

Deliberately deferred: tlog-tiles + witness-network anchoring (the strongest possible guarantee — genuine non-equivocation, defeats split-view/rewind) — revisit exactly when migrations/0180's own stated trigger fires: when tenants exist. OpenTimestamps as a third backstop is a reasonable future addition once 1-2 are live, not filed as its own issue yet since it adds latency/verifier-UX cost without closing a gap 1-2 don't already close.

All seven are maintainer-only and assigned.

[JSONbored]

Correction: Bittensor on-chain commitment is back in scope

The original research above ruled this out as a universal anchoring mechanism — correctly, for the general repo-owner/contributor audience. Maintainer input changed the picture:

• LoopOver isn't scoped to Gittensor participants alone, but Gittensor/SN74-registered contributors and validators specifically already trust and verify things via subtensor — an on-chain anchor is genuinely valuable additional corroboration for exactly that audience, while being irrelevant (and rightly so) to everyone else.
• The "needs a trusted archive" objection assumed the archive belongs to someone else. It doesn't have to: the operator already runs dedicated node infrastructure for other purposes, which is the same trust posture the git-commit backend (ledger: git-commit anchoring backend, cross-verified against GH Archive / Software Heritage #9273) already accepts for GitHub.
• The house-rule objection was overstated: a dedicated hotkey managed as a runtime secret on infrastructure built to hold one — never committed to this repo — is the same pattern as every other credential this app already handles, not a new risk class.
• Signing runs outside this repo's Worker, on the operator's own existing node infrastructure, which also removes the @polkadot/api-in-Workers friction entirely.

Filed as #9277, explicitly scoped as optional, Gittensor-audience-specific corroboration — never a required verification step for the general audience. Epic body and decomposition updated above.