ledger: Bittensor on-chain commitment backend — optional, Gittensor/SN74-audience corroboration

[JSONbored]

Context

Sub-issue of #9267 (external decision-ledger anchoring). The original research on this issue ruled out Bittensor on-chain commitment as a universal anchoring backend — correctly, for a repo owner or contributor with no Bittensor involvement, since checking a subtensor commitment means nothing to that audience. Maintainer correction: this repo isn't scoped to Gittensor participants alone, but Gittensor/SN74-registered contributors and validators specifically already trust and verify things via subtensor, and the operator already runs dedicated node infrastructure for other purposes — so this is worth building as a fourth, optional, clearly-scoped backend, not something to skip.

What changed from the original assessment

1. The archive-dependency objection weakens when you operate the archive. CommitmentOf (pallets/commitments) is overwritten in place — only the latest commitment per (netuid, account) survives in on-chain state. Retrieving a specific historical commitment therefore needs querying a specific historical block via an archive node. That's a real constraint, but it stops being a trust problem once the archive is infrastructure the operator already runs for other purposes — the same posture as ledger: git-commit anchoring backend, cross-verified against GH Archive / Software Heritage #9273's git-commit anchor already accepting "GitHub is a trusted third party, but we control the repo."
2. Signing does not need to run in the Worker. A small process on the operator's existing node infrastructure — not Cloudflare Workers — submits set_commitment(netuid, CommitmentInfo) using a dedicated hotkey. This sidesteps @polkadot/api's Node-orientation (it never needs to run in a Worker) and means the hotkey lives as an operational secret on infrastructure already built to hold one, never in this repo's committed code or config — the same pattern as every other credential (GITHUB_TOKEN, ANTHROPIC_API_KEY) this app already manages at runtime.

Requirements

1. Dedicated hotkey, registered on the relevant netuid, used for no purpose other than anchor commitments — not an existing production/validator key, so a compromise here has no blast radius beyond this feature.
2. Commit the same canonicalized anchor payload as every other backend (ledger: versioned + signed anchor payload, public key + rotation route #9270): Data::Sha256 (32 bytes) holds the payload's hash directly — no truncation, no re-derivation needed.
3. Runs on the operator's existing node infrastructure, outside this repo's Worker deployment. This repo's side is only: expose the anchor payload (already public via ledger: anchor persistence + public attempt log (success and failure both visible) #9271's attempt log) for that external process to read, and accept its resulting status: 'ok'|'failed' + on-chain reference back into ledger: anchor persistence + public attempt log (success and failure both visible) #9271's persistence, same shape as ledger: Rekor v2 hashedrekord anchoring backend #9272/ledger: git-commit anchoring backend, cross-verified against GH Archive / Software Heritage #9273.
4. Rate limit awareness: MaxSpace (~3100 units/epoch, 100-unit floor per commitment) allows roughly 31 commitments per epoch (≈72 min) — comfortably above the ledger: scheduled checkpoint anchoring — hourly or every 256 records, whichever first #9274 hourly-or-256-records cadence.
5. Explicitly scoped as optional in every user-facing surface. The docs update (docs: update the verification contract once ledger anchoring ships #9275) must present this as additional corroboration for the Gittensor/SN74 audience, never as a required verification step — a verifier with no Bittensor involvement should be able to fully verify anchoring via Rekor + git alone and never need to touch this.
6. Historical-retrieval procedure documented precisely: since CommitmentOf only holds the latest value, verifying an old anchor requires querying the operator's archive node's historical state at the relevant block — not merely reading current chain state — and this must be spelled out so a Gittensor-audience verifier doesn't hit the "state is overwritten" surprise this issue's own research flagged.

Deliverables

• The external submission process (on node infrastructure, not this repo's Worker) — documented setup, not necessarily code in this repository if it lives entirely on separate infra; if any repo-side glue is needed (e.g. exposing the payload in a shape that process consumes), that piece lives here and is tested
• Persistence wiring so on-chain anchor attempts appear in ledger: anchor persistence + public attempt log (success and failure both visible) #9271's public attempt log identically to Rekor/git attempts
• Documented historical-retrieval procedure for a Gittensor-audience verifier

Expected outcome

Gittensor/SN74-registered contributors and validators get an additional, on-chain-corroborated anchor for LoopOver's decision ledger — genuinely valuable to that specific audience, without making it a requirement or a point of confusion for anyone outside it.

References

Sub-issue of #9267. Corrects and supersedes that issue's original "do not pursue" verdict on Bittensor commitment — see the maintainer-correction comment on #9267 for the full reasoning. Depends on #9270 (payload), #9271 (persistence). Mechanism details (rate limits, Data variants, gating): decision-record comment on #9267.

[linear-code]

JSO-6439