ArkForge Proof Specification

The open format behind every Trust Layer proof. It defines what a proof contains and how any party, buyer, auditor or regulator, recomputes and checks it without ArkForge’s code or infrastructure.

Version

3.1.1

Status

Draft, seeking co-implementers

License

CC BY 4.0 (specification), MIT (reference implementation)

Source

github.com/ark-forge/proof-spec

What a proof contains

A proof is a JSON record issued by the Trust Layer proxy for one exchange between an agent and an API. These are the fields a verifier works with. The full field list, including optional and informational fields, is in section 1 of the specification.

Field	Content
`hashes.request`, `hashes.response`	SHA-256 of the canonical JSON of the request and of the response.
`commitments`	One commitment per field (request and response hashes, time, parties, identity), each built with its own 32-byte random nonce.
`hashes.chain`	RFC 6962 Merkle root of the commitments. A third party recomputes it from the published commitments alone, without seeing any field value.
`arkforge_signature`	Ed25519 signature of the chain hash by ArkForge. The public key is also served at `/.well-known/did.json`.
`batch_anchor`	Inclusion path from the chain hash to the batch root that was anchored. A batch closes at 100 proofs or 10 minutes.
`timestamp_authority`	RFC 3161 token on the batch root, embedded in the proof (`tsr_base64`).
`transparency_log`	Sigstore Rekor entry for the batch root: log index and entry URL.
`disclosed`	Nonces and values of the identity fields, published so that anyone can open those commitments.

How to verify a proof

The reference verifier is a single script. It needs the Python standard library and the openssl binary, nothing else, so a disputing party can run it on a plain machine.

Terminal

curl -O https://raw.githubusercontent.com/ark-forge/trust-layer/main/scripts/verify_proof.py
python3 verify_proof.py prf_20260914_194825_a747d0
python3 verify_proof.py --file proof.json    # from a copy you kept

Check	What it establishes	Independent of ArkForge
1. Chain hash	The proof is internally consistent. On its own this is not evidence: whoever fabricates a proof produces coherent hashes.	No
2. Ed25519 signature	ArkForge issued the proof.	No
3. Batch anchor	The chain hash belongs to the anchored batch. This is what carries checks 4 and 5 down to the individual proof.	No
4. RFC 3161 timestamp	A third-party timestamping authority signed the batch root at a given time.	Yes
5. Sigstore Rekor	The batch root is in a public append-only log, with an inclusion proof against a signed checkpoint.	Yes

The script exits with code 0 only if every applicable check passes. A proof whose batch is not yet anchored is reported as waiting, not as tampered.

What verification does not establish

Stated in sections 2, 5 and 6 of the specification.

That the response content is correct Verification shows what the service returned, not whether it was right.

That no call bypassed the proxy A proof covers the exchanges that went through Trust Layer, and only those.

Independence before the batch closes Between issuance and batch close, a proof has no external anchor: only ArkForge’s signature vouches for it.

The plain-text fields of a public proof A public response shows some values in clear, but only their commitments are anchored. To rely on a value, open its commitment with the nonce held by the proof’s owner.

That an agent identity binding happened The identity claim is committed and cannot be restated, but no public artefact proves the DID challenge took place. Resolve the DID yourself if you need that.

Mutable metadata Fields such as transaction_success, upstream_status_code or disputed are informational and may change after issuance.

A qualified electronic timestamp The RFC 3161 tokens come from FreeTSA, DigiCert or Sectigo and are not qualified under eIDAS.

Versioning

The specification follows semantic versioning. Each proof records its spec_version, which selects the chain hash algorithm: proofs issued under earlier versions keep their algorithm and remain verifiable, and nothing is recomputed or re-anchored retroactively.

Changes, questions and independent implementations go through GitHub issues. An implementation must pass every test vector to claim conformance. See the CHANGELOG for the version history.