Open standard for verifiable agent-to-agent execution proofs.
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.
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' ' -f1UPSTREAM and RECEIPT_HASH are empty strings when absent from the proof.
If the result matches proof.hashes.chain, the proof is intact.
| Implementation | Language | Status |
|---|---|---|
| ArkForge Trust Layer | Python | Reference implementation |
Want to add yours? Open a PR.
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.
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.
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.