ArkForge Proof Specification
March 24, 2026 · View on GitHub
Open standard for verifiable agent-to-agent execution proofs.
What is this?
A deterministic proof format that binds a request, response, payment, and timestamp into a single SHA-256 chain hash. Anyone can verify a proof without ArkForge's code or infrastructure.
Quick verification
Given a proof JSON, verify it in one line:
printf '%s' "${REQUEST_HASH}${RESPONSE_HASH}${PAYMENT_ID}${TIMESTAMP}${BUYER}${SELLER}${UPSTREAM}${RECEIPT_HASH}" \
| sha256sum | cut -d' ' -f1
UPSTREAM and RECEIPT_HASH are empty strings when absent from the proof.
If the result matches proof.hashes.chain, the proof is intact.
Implementations
| Implementation | Language | Status |
|---|---|---|
| ArkForge Trust Layer | Python | Reference implementation |
Want to add yours? Open a PR.
Test vectors
test-vectors.json contains 9 test cases (7 legacy string-concatenation vectors + 2 canonical-JSON vectors for spec_version 1.2/2.1). Any conformant implementation MUST pass all vectors.
Composability
The proof-spec is the cryptographic foundation for the Compliance Receipts v0.1 spec drafted by the qntm Working Group.
Field mapping:
| proof-spec field | Compliance Receipts v0.1 field | Notes |
|---|---|---|
proof_id | receipt_id | Same role: unique receipt identifier |
hashes.request | input_hash | SHA-256 of canonical JSON (identical algorithm) |
hashes.response | output_hash | SHA-256 of canonical JSON (identical algorithm) |
timestamp | step.timestamp | ISO 8601 UTC |
parties.agent_identity + parties.agent_identity_verified + DID endpoint | step.agent_did | agent_identity carries the verified DID when agent_identity_verified: true; did:web:trust.arkforge.tech resolves to the Ed25519 signing key |
arkforge_signature | signature | Ed25519 — signs the chain hash (proof-spec) vs. canonical receipt (CR v0.1) |
hashes.chain | no equivalent | Additional witness: binds payment + identity + request + response into one sealed hash |
Fields in Compliance Receipts v0.1 with no proof-spec equivalent (pipeline_id, step.index, step.role, previous_receipt_hash, policy) are pipeline context provided by the calling agent, not derived by the proxy.
Roadmap
The proof format will evolve to support third-party provider attestations and multi-PSP payment verification. See the Trust Layer roadmap for the full architecture.