Bitcoin-anchored validation receipts for the Validation Registry

[MarkovianProtocol]

The reference implementation models validation and reputation as on-chain registry entries. Those entries cannot show, on their own, an independent portable proof that the underlying data existed at a point in time, anchored outside the EVM chain the registry lives on.

Markovian is a content-agnostic provenance primitive that fills that gap: POST a hash, it writes a Merkle root plus a BN128 Pedersen commitment to a Bitcoin-anchored chain and returns a receipt verifiable by anyone with no account. It proves data was committed at a time, not that it is correct.

It already answers on the ERC-8004 Validation Registry on Sepolia: a validationRequest names the Markovian validator, and the relayer answers validationResponse with responseHash set to the Markovian merkle_root and tag set to "provenance", so a response of 100 reads as "a provenance record was recorded", not a correctness claim.

• Validation Registry (Sepolia): 0x51D26042b3561e1C6cD250Cf211Cec0505178b00
• Writeup and live artifacts: https://markovianprotocol.com/erc8004.html
• Reference implementation (Apache-2.0): https://github.com/MarkovianProtocol/markovian-protocol

Would a Bitcoin-anchored provenance receipt as a validation or reputation source be useful to the reference implementation? Happy to open a PR with a worked example against the registry interface.

[BausBank]

We've been running exactly this pattern in production for the past ~3 weeks (live since mid-June 2026), so sharing operational data points that may help spec this out

Setup: a live trading agent whose append-only journal is sealed with commit-reveal and anchored hourly - a single 32-byte anchor_hash = sha256({journal_head, seq, batch_root, prev_anchor}) published both as EVM calldata (Arc) and via OpenTimestamps to Bitcoin. ValidationRegistry.validationResponse carries the verdict digest, so a receipt binds {what was validated} → {when it provably existed} → {who attested}. 80+ hourly anchors confirmed on both rails so far; revocation (100→0) exercised live

Practical learnings relevant to the proposal:

[1] Anchor the journal head, not individual receipts - one hash commits the entire prefix, catches both re-minting and tail-trimming, and keeps Bitcoin costs at ~zero via OTS batching. Per-receipt anchoring doesn't scale and adds nothing.

[2] OTS calendar servers are the fragile part - of the three default calendars, two had expired TLS for weeks this year; verification must tolerate single-calendar liveness and cross-check the Bitcoin merkle root against ≥2 independent explorers.

[3] Receipts must be reconstructible from public data - we restore the OTS digest from the published anchor_hash so verifiers never handle private files.

[4] The remaining trust gap is outcome truth (a signer can re-mint and re-anchor a forged history): closing it needs enumeration of all anchor-address txs on-chain + cross-checking claims against public venue data - that's the verifier's job, not the registry's.

Happy to contribute a deployment-guide section covering this pattern (also touches #13) - live artifacts are independently checkable at [acos.capital] (https://acos.capital) if useful as a reference

[MarkovianProtocol]

Pulled journal.jsonl and anchors.jsonl from acos.capital and checked them. The journal passes your own verifier (python -m vtr_core.journal.verify: 509 entries, integrity PASS). All 278 anchors chain-link with zero breaks, and anchor_hash recomputes as SHA-256 over the sorted-key canonical payload. Four sampled OTS proofs (anchors 1, 101, 201, 277) replay from sha256(digest) through the recorded ops to the Bitcoin merkle root at the stated heights, cross-checked on mempool.space and blockstream.info. Your point [2] matches what we run: tolerate single-calendar liveness, and take the block header from at least two independent explorers.

Yes to the deployment-guide offer. Concrete scope: a section in this repo's DEPLOYMENT_GUIDE.md — "Anchoring validation receipts in production" — covering your [1] journal-head anchoring rather than per-receipt, [2] calendar liveness policy plus explorer cross-check, and [3] reconstructing the OTS digest from published anchor data, with acos.capital's public files as the worked example. We can fold it into the PR offered in the opening post, or review yours — whichever the maintainers prefer.

One thing would make the ERC-8004 leg checkable end to end: the comment says ValidationRegistry.validationResponse carries the verdict digest and that revocation (100→0) was exercised live, but no registry address or transaction hashes are published. Those two txids — the response and the 100→0 revocation — would close it, and involve no trading data. Everything else verified from public data alone. For the guide we would keep the scope stated the way your point [4] already puts it: the anchors prove the journal existed in this order at these times; outcome truth is the verifier's job, not the registry's.