CRYPTOGRAPHIC INTEGRITY DELIVERY PROOFS EXCHANGER PROTOCOL

What a verifiable API delivery receipt should prove.
Cryptographic SHA-256 digests, signatures & immutable audit trails.

A deep architectural dive into why autonomous AI agents require cryptographic response receipts, the minimum required JSON fields, and how to verify delivery integrity independently.

Published: 2026-11-09 Status: Grounded Technical Guide Reading Time: 5 min

Direct Answer Summary

In traditional human software, an HTTP 200 OK response with a JSON payload is considered sufficient proof of delivery. For autonomous AI agent networks, HTTP status codes cannot prove that the data was unmodified in transit, that the provider had redistribution rights, that the charge was authorized, or that the payload matched the client's idempotency key. A verifiable delivery receipt binds the input request hash, canonical output digest, timestamp, provider key, and fee in an immutable cryptographic record.

1. The Minimum Useful Receipt Fields

A machine-verifiable delivery receipt must contain the following typed fields without storing sensitive credentials or customer secrets:

json · proposed generic example, not an ELYRAON response 
{
  "receipt_id": "rcpt_8f391b42a9ceb640",
  "request_id": "req_01j7b9k2m4v8",
  "capability": "check_n8n_workflow",
  "provider": "elyraon.com.co",
  "delivered_at": "2026-11-09T05:30:00Z",
  "input_sha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
  "response_digest": "a8f5f167f44f4964e6c998dee827110c",
  "schema_version": "1.0.0",
  "billing_unit": "free_trial_invocation",
  "amount_usd": 0.00,
  "idempotency_key": "agent-step-001",
  "signer_key_id": "key_pub_2026_q4",
  "signature": "MEQCIA..."
}

2. Verification Checklist for Client Agents

Before accepting and recording an API delivery as fulfilled, an autonomous agent should verify:

  1. Digest Binding: Does the SHA-256 hash of the delivered response bytes exactly match response_digest?
  2. Input Integrity: Does input_sha256 match the client's sanitized request payload?
  3. Key Validity: Is the signer_key_id published in the provider's authoritative discovery document and unrevoked?
  4. Idempotent Safety: Does the receipt acknowledge the specific Idempotency-Key sent by the caller?
  5. Settlement Status: Is the transaction in simulated test mode or live settlement? Local tests or test-mode Stripe events must never be recorded as verified paid transactions.

3. EXCHANGER Protocol Architecture

The receipt above is a generic reference design only. ELYRAON has not verified a public production endpoint that issues signed delivery receipts or an authoritative public signing-key set. The live Workflow Rescue MCP performs static n8n analysis; it does not establish that results are signed, settled, or independently verifiable.

  • Current Development Status: EXCHANGER and signed receipt capabilities remain development or proposed work. Local tests, architecture examples, and a disabled settlement path do not show that customers can use a production receipt service.
  • Operational Evidence: The MCP tool returns static analysis findings. It does not issue an ELYRAON signed receipt or guarantee provenance.

Next Steps for Engineers

Connect your AI agent to our live MCP tool server, inspect the protocol schemas, or explore EXCHANGER marketplace architecture.

Connect Agent to MCP → Inspect Agent Hub → View EXCHANGER →