# Markovian Protocol > Markovian lets an agent commit a claim, resolve the outcomes decidable from public data, and trace the lineage of any output, all bound into a public witnessed transparency log with Bitcoin-anchored heads and verifiable by anyone, without trusting the agent or an operator. It proves what was committed and when, and settles outcomes by deterministic replay. It does not assert that arbitrary claims are true. Markovian has three primitives over one atomic output. One claim, many envelopes. - COMMIT writes a content-agnostic provenance record: a SHA-256 data hash and a Merkle root, bound as a leaf into a public append-only transparency log that independent witnesses cosign. It proves that an agent made a claim, and when. It makes no statement about whether the claim is correct. - RESOLVE decides whether a claim actually holds, for outcomes decidable from public data, by deterministically replaying that data into a verdict anyone can recompute, with no oracle and no trusted party. It is the only primitive that returns a verdict. - TRACE walks the lineage between records across agent handoffs, verifying every node and edge against the public record. It shows what produced an agent's output, so an agent is checked, not trusted. In short: COMMIT proves a claim was made, RESOLVE decides whether it holds, TRACE shows what produced it. The same provenance record is the canonical object `markovian-provenance/v1`. It plugs into the standards agents already use. --- # Full content ## A real record This is a real stamp, created 2026-07-31 against the live endpoint, shown exactly as returned: ``` POST https://api.quantsynth.net/stamp {"data": {"purpose": "field-pass deploy check", "date": "2026-07-31"}, "label": "fieldpass-deploy-check"} { "ok": true, "stamp_id": 3276, "log_index": 5476, "log_origin": "markovianprotocol.com/log", "inclusion": "https://log.markovianprotocol.com/inclusion?leaf=5476", "wallet": "anonedd991df02af0ed350e959a225507b65", "issuer": "anonedd991df02af0ed350e959a225507b65", "merkle_root": "b657a420f56098ad03f1df76557f8e495d5cc5c860445373e226901f4b4ee78f", "data_hash": "f1c337e6e2edf7dad35238e683f0286905ccf9fa7c95310da7fcac44e7c54fd4", "zk_commitment": null, "block_height": null, "stamped_at": "2026-07-31 16:42:57.550090+00:00", "verify_url": "https://api.markovianprotocol.com/verify/b657a420f56098ad03f1df76557f8e495d5cc5c860445373e226901f4b4ee78f" } ``` Three independent ways to check it: 1. Look it up: GET the verify_url. `verified: true` means the record exists and the response echoes the committed data_hash. 2. Recompute: hash your copy of the content with SHA-256 and compare it to data_hash. A changed byte changes the hash. 3. Trust nobody: fetch the inclusion URL and verify the RFC 6962 inclusion proof against the witnessed log head at https://log.markovianprotocol.com/checkpoint . This path needs no trust in the API, only in the witness quorum and the math. ## The witnessed log Markovian operates a public, append-only transparency log (C2SP checkpoint format) at https://log.markovianprotocol.com - Signed head: /checkpoint - Any leaf: /leaf/{i} - Bulk: /leaves?start={s}&end={e} - Inclusion proof: /inclusion?leaf={i}&size={n} - Consistency proof between heads: /consistency Seven independent witnesses, run by unrelated operators, cosign each checkpoint. A cosignature attests the log is append-only with a single history. It does not attest that any claim in the log is true. The acceptance rule: a checkpoint counts as witnessed when at least 4 of the 7 pinned witnesses have a verifying Ed25519 cosignature on it. Witnesses cosign on an hourly round, so a new entry can sit up to about an hour as committed-but-not-yet-witnessed. Roster, key sources, and the rule: https://markovianprotocol.com/witness-policy.html . Each witness key is pinned from the operator's own published page, never from the log. Two of the seven also emit ML-DSA-44 (post-quantum) cosignatures alongside Ed25519, and since July 2026 the published checkpoint also carries the log operator's own ML-DSA-44 cosignature; the operator's post-quantum signature carries no witness weight. Checkpoints are timestamped into Bitcoin hourly with OpenTimestamps: https://log.markovianprotocol.com/anchor Verification tooling: - Standalone checkpoint verifier with the witness keys pinned in source: https://markovianprotocol.com/.well-known/verify_checkpoint.py - Browser verification of all seven cosignatures: https://markovianprotocol.com/trace.html - Verify a log record by hash: GET https://markovianprotocol.com/anchor/{sha256-hex} recomputes the RFC 6962 inclusion proof server-side. rootcommit/v3 records also return an EIP-712 signer verdict, binding an EVM wallet to a log root under a Bitcoin timestamp. Markovian also runs a public witness for other transparency logs, listed on the witness-network.org test table: https://witness.markovianprotocol.com/about ## COMMIT, the provenance entrance Stamping is frictionless. POST /stamp with a data payload and nothing else: no account, no wallet, no funding. The protocol mints an ephemeral committer and returns a verifiable record. By default the stamp is anonymous and free. An optional committer handle may be supplied to attribute repeated stamps to the same agent, so an agent can accumulate a verifiable, replayable track record. ``` curl -X POST https://api.quantsynth.net/stamp \ -H "Content-Type: application/json" \ -d '{"data": "anything"}' ``` What happens on a stamp: 1. The payload is canonicalized as RFC 8785 (JCS) JSON and hashed with SHA-256. Only the hash is stored; the raw data never is. A client can also send a precomputed data_hash and keep the data entirely private. 2. The record {merkle_root, data_hash, issuer} is appended as a leaf to the public witnessed transparency log. The response carries the leaf index and a ready-made inclusion-proof URL. 3. The log's heads are cosigned by the independent witness quorum on the hourly round and timestamped into Bitcoin via OpenTimestamps. A stamp may carry an Ed25519 countersignature from the submitting agent. A countersignature that does not verify over the content is refused, not flagged: anchoring an invalid signature would lend it credibility it has not earned. ## Verify Look up any record by Merkle root: ``` curl https://api.quantsynth.net/verify/{merkle_root} ``` `verified: true` means the stamp record exists and the response echoes its committed data_hash. To confirm content is unaltered, recompute your content's SHA-256 and compare. The trust-nobody path is the log inclusion proof, which verifies against the witnessed log head without trusting the endpoint. Every COMMIT root also carries a standard OpenTimestamps proof, downloadable at GET https://api.quantsynth.net/verify/{merkle_root}.ots and verifiable with the stock `ots` client against Bitcoin, with no trust in Markovian. Live verifiable demo, a real record checked in the browser: https://demo.markovianprotocol.com ## TRACE TRACE composes stamps into one provenance graph: a stamp can reference prior stamps in derived_from, with the parent references bound inside the committed bytes, so tampering with a link breaks the hash. The referenced payload is published by root so a lineage walk can fetch nodes it was not handed; a payload is accepted only if its SHA-256 matches the committed data_hash. TRACE walks a stamp's lineage and verifies every node and edge, returning a MAP of the graph, not a verdict: each node carries hash_binds and anchored, each edge carries edge_verified, and `valid` is true only if every node and edge checks out. A node whose payload was never published is an unresolved frontier. Showcase: https://markovianprotocol.com/trace.html ## Resolution by deterministic replay For outcomes decidable from public data, Markovian resolves by deterministic replay: pin the inputs by hash before the outcome, then recompute the verdict from those inputs, so anyone can rerun the same computation and get the same answer. No oracle committee, no trusted reporter. The two-clause contract: the verifier recomputes, and the inputs are pre-committed. A deterministic-replay resolution validator for ERC-8004 is published at https://github.com/MarkovianProtocol/erc8004-resolution-validator ## Doors The canonical record travels inside the standards agents already use. Each door page shows a real, live artifact. ### W3C Verifiable Credentials — live https://markovianprotocol.com/vc.html The markovian-provenance/v1 object becomes the credentialSubject of a W3C Verifiable Credential (Data Model 2.0), issued by did:web:api.markovianprotocol.com and secured as a JOSE enveloped JWT (vc+jwt, Ed25519). The VC standard itself states that verifiability does not imply the truth of the claims carried; that separation matches the stamp exactly. Endpoints: /.well-known/did.json, /vc/provenance/v1, POST /credential, POST /credential/verify. ### Model Context Protocol — live https://markovianprotocol.com/mcp.html A public MCP server over Streamable HTTP at https://api.markovianprotocol.com/mcp/ (trailing slash required) with three tools: - markovian_stamp: stamps data into the public transparency log. - markovian_verify: checks a merkle root against the public verifier and returns whether the log holds a matching record. - markovian_trace: walks a stamp's derived_from lineage and verifies every node and edge; returns a map, not a verdict. Client configuration: ``` { "mcpServers": { "markovian": { "type": "http", "url": "https://api.markovianprotocol.com/mcp/" } } } ``` The same tools run locally over stdio from the reference server in the protocol repository. Listed in the official MCP registry as io.github.MarkovianProtocol/provenance . A second hosted instance runs as a Hugging Face Space (MarkovianProtocol/markovian-provenance) with stamp and verify tools. ### ERC-8004, Trustless Agents — live on Base mainnet https://markovianprotocol.com/erc8004.html Two Markovian agents are registered on the ERC-8004 registry on Base mainnet (chain id 8453, registry 0x8004A169FB4a3325136EB29fA0ceB6D2e539a432): agent 59270 sells a signal at a paid x402 endpoint, agent 59285 buys it. Both are operated by Markovian and that is disclosed in each registration file. Trust model: witnessed-log. Every settlement between them is stamped as a leaf in the public log. Markovian plugs into the Validation Registry as a provenance provider. The semantic firewall: the on-chain response is a score from 0 to 100, and a 100 from Markovian means a provenance record was found in the log, not that the agent's work is correct. The response tag is set to `provenance` so no consumer can mistake the score for a correctness claim. ### x402 — live A paid endpoint at https://markovianprotocol.com/signal/latest returns HTTP 402 payment terms and sells one signal for 0.02 USDC on Base. Each settlement is stamped as a leaf in the witnessed log, for example https://log.markovianprotocol.com/leaf/912 ### OpenTimestamps — live https://markovianprotocol.com/ots.html Every COMMIT root is submitted to the four public OTS calendars, which batch it into their own Merkle tree and write one root to Bitcoin. The returned .ots proof verifies with the unmodified ots client against Bitcoin, with no calendar, no Markovian, and no trust required. The OTS proof is a second, adversary-disjoint anchor beside the witnessed log: it can be checked against Bitcoin even if Markovian is offline. ### Ethereum Attestation Service — testnet https://markovianprotocol.com/eas.html The record is registered as an EAS schema (markovian-provenance/v1) and issued as an attestation on Sepolia, with refUID linking onto existing attestations. ### C2PA — live https://markovianprotocol.com/c2pa.html A namespaced assertion (com.markovianprotocol.provenance.v1) inside a C2PA content manifest. Because the stamp is also a leaf in the public log, the record survives even if the manifest is stripped from the file. ### CloudEvents — live https://markovianprotocol.com/cloudevents.html The record rides on a CloudEvent as extension attributes (markovianroot, markovianverify, markovianprovenance), so provenance follows the event across every transport and broker hop. ## Canonical record The `markovian-provenance/v1` object: - merkle_root: the record's handle; a salted SHA-256 root committed to the log. - data_hash: SHA-256 of the RFC 8785 canonical bytes of the stamped content. The field a verifier recomputes and compares. - issuer: the committer handle, as named in the transparency-log leaf. Attribution metadata, not a cryptographic identity. `wallet` is kept as a compatibility alias with the same value. - log_index / inclusion: the leaf position in the witnessed log and a ready-made inclusion-proof URL. The trust-nobody path. - stamped_at: server timestamp of the commit. - verify_url: public lookup for the record. - attestation: a plain-language statement that the record proves provenance and time, not correctness. - zk_commitment, block_height: legacy fields, null on new stamps. Historical values date from a retired internal chain; they were never client-verifiable and carry no weight. ## Conformance and open source - https://github.com/MarkovianProtocol/canoncheck — byte-level canonicalization conformance checker for RFC 8785 (JCS) + SHA-256 records, with test vectors. Also runs as a Hugging Face Space. - https://github.com/MarkovianProtocol/log-consistency-vector — a self-contained consistency-proof test vector with an offline verifier: old head, new head, RFC 6962 proof, and refusal cases that must fail closed. - https://github.com/MarkovianProtocol/erc8004-resolution-validator — the deterministic-replay resolution validator. - https://github.com/MarkovianProtocol — everything else, including the reference MCP stdio server and integration specs under specs/. ## Build ``` # No SDK, just HTTP: curl -X POST https://api.quantsynth.net/stamp \ -H "Content-Type: application/json" -d '{"data": "hello, provenance"}' # Or from PyPI: pip install markovian python3 -c " from markovian import MarkovianClient print(MarkovianClient().stamp('hello, provenance')) " ``` Native MCP for agents: add https://api.markovianprotocol.com/mcp/ to any MCP client configuration; the tools are self-describing. ## What a record proves, and what it does not A Markovian record establishes that specific bytes existed and were committed at a specific time, in a log whose single history is attested by independent witnesses and whose heads are timestamped into Bitcoin. Altering or backdating it undetected would require breaking SHA-256 or rewriting the witnessed history. It does not establish that the committed content is true, correct, or authorized; verdicts exist only where deterministic replay from pre-committed public inputs is possible. ## Primitives - COMMIT: https://commit.markovianprotocol.com — prove what an agent produced. - RESOLVE: https://resolve.markovianprotocol.com — settle what an agent asserts, oracle-free outcome resolution by deterministic replay. - TRACE: https://markovianprotocol.com/trace-explorer.html — trace where an output came from. - How it composes: https://markovianprotocol.com/atomic.html — one atomic output, three primitives.