Blockchain Proof vs Audit Log vs Action Receipt: What Each Proves

Reviewed 17 August 2026 · 16 minute read

A blockchain anchor can show that a digest existed in a recorded chain state and help detect later substitution. An audit log records operational events for monitoring and investigation. A signed action receipt binds an issuer's attestation to specific transaction digests and references. None of them alone proves that the underlying business event was true, authorized, complete or free from bypass.

This article is for security, audit and platform teams deciding what evidence an enterprise agent should produce. It supplies a claim matrix, a verification sequence and failure cases that prevent a valid signature from becoming an exaggerated assurance statement.

What does each evidence mechanism prove?

Swipe horizontally to inspect the full diagram.

A proof is only useful when the verifier knows the claim, issuer, covered bytes, time, key policy and external evidence needed to support it.

Why ordinary audit logs remain necessary

Operators need high-volume records that answer practical questions: which service handled the request, how long it took, which retry ran, where an exception occurred and which trace connects the gateway to the provider.

OpenTelemetry defines a common log data model and uses TraceId and SpanId to correlate records with distributed traces. The OpenTelemetry logs data model is designed for interoperable operational telemetry, not portable business authorization evidence.

Keep logs because receipts should not contain every debugging field. A receipt with full prompts, secrets or customer records becomes a privacy and retention problem. The better division is:

• Logs retain operational detail under enterprise access controls.
• Receipts retain stable identifiers, selected claims and digests needed for later verification.
• Authoritative systems retain the changing business state.
• Optional anchors make selected receipt or evidence-package commitments tamper-evident.

Use stable correlation fields across them:

{
  "transaction_id": "txn:refund:8421",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "receipt_id": "receipt:refund:01K4",
  "request_digest": "sha256:6e4f...",
  "idempotency_key": "refund:order-8421:v1",
  "provider_reference": "refund:rf_9182"
}

Do not use one identifier for every purpose. A trace can contain several attempts. An idempotency key can survive a retry. A receipt can be corrected or supplemented. The provider reference belongs to the external system.

What a digital signature establishes

A signature verifier checks that the protected bytes match the signature under a resolved public key. The surrounding trust policy must then decide whether that key belonged to an acceptable issuer at the relevant time.

Canonicalization is necessary when independently implemented systems sign structured JSON. RFC 8785 defines deterministic JSON serialization so both sides can hash the same logical data into the same bytes. RFC 8785 defines the representation rules and their constraints.

The signature supports these claims:

1. The signed bytes have not changed since signing.
2. The signer controlled the private key corresponding to the verified key under the selected proof profile.
3. The issuer attested to the fields inside the signature boundary.

It does not support these stronger claims without more evidence:

1. Every fact in the receipt was true.
2. The signing system had no bypass route.
3. The business action completed successfully.
4. The agent had valid authority unless authority records are included and verified.
5. The signing key was uncompromised merely because the mathematics verifies.

The W3C Verifiable Credentials model makes a similar distinction: a verifiable credential expresses issuer claims with tamper protection, while the verifier applies its own trust and status policy. The W3C Verifiable Credentials overview is a useful source for issuer, holder and verifier responsibilities.

What blockchain anchoring adds

Anchoring a digest to a blockchain can give an independent verifier a public, timestamped commitment under the chain's inclusion and finality model. If the off-chain artifact changes, recomputing its digest exposes the mismatch.

That is valuable for cross-organizational evidence where no participant wants the other to control the only timestamp or integrity record. It is not necessary for every internal action. A well-operated signed and append-only evidence service may be cheaper, more private and easier to correct under records policy.

Concordium's Agent Registry stores a pointer to an off-chain Agent Card and an on-chain SHA-256 hash of the card bytes. A verifier can fetch the card, recompute its hash and compare it with the registry entry. Concordium's Agent Registry guide provides a concrete example of integrity anchoring. The match shows the card is the one committed by the registry record. It does not independently validate every capability claim inside the card.

OriginTrail applies blockchain and graph mechanisms to published knowledge and provenance. Its DKG can help identify who published an assertion and whether the associated graph commitment verifies. Source reliability and contradictory claims still require application policy. OriginTrail's DKG repository describes knowledge assets, graph data and proof-backed provenance.

Where evidence products sit in the market

Enterprise agent market positioning

Product-scope analysis, not market share, quality or maturity

Text summary of highlighted companies

Company or protocol	Primary scope represented on the map
Intelliger	Transaction-specific authority, deterministic enforcement, reconciliation and portable evidence.
Concordium	Verified ownership, agent registry and identity-linked transaction infrastructure.
OriginTrail	Shared context graphs, provenance and decentralized knowledge infrastructure.
Kong	LLM, MCP and A2A traffic gateway, authentication and observability.
Portkey	AI and MCP gateway, credential isolation, observability and guardrails.
Catena	Agent financial policy, approvals, accounts, payment execution and audit.
Google AP2	Typed checkout and payment mandates, role validation and receipts.

The chart does not imply that a blockchain product has stronger evidence than every gateway, or that a receipt platform is more mature than a log platform. It shows which part of the action lifecycle the documented product scope addresses.

Design an action receipt around verifiable claims

A receipt for a decision or attempted action should be small enough to share and precise enough to verify:

type ActionReceipt = {
  receiptId: string;
  transactionId: string;
  issuer: string;
  issuedAt: string;
  agent: { id: string; owner: string };
  authority: {
    mandateId: string;
    mandateDigest: string;
    statusObservedAt: string;
  };
  decision: {
    result: 'allow' | 'deny' | 'approval_required';
    policyDigest: string;
    approvalDigest?: string;
  };
  request: {
    requestDigest: string;
  };
  execution?: {
    providerReference?: string;
    observedState: 'accepted' | 'unknown' | 'confirmed' | 'failed';
  };
  assurance: {
    mode: 'unilateral' | 'bilateral';
    evidenceRefs: string[];
  };
  proof: {
    verificationMethod: string;
    cryptosuite: string;
    value: string;
  };
};

This is an illustrative profile. The verifier must use the declared schema and proof profile rather than accepting arbitrary algorithms. Sensitive request bodies can remain in a controlled evidence store while the receipt carries their digest and access-controlled reference.

When execution occurs, the observed state must not be called final when the provider only accepted submission. Add later reconciliation events for confirmation, failure, reversal and dispute. Preserve the earlier receipt rather than rewriting history.

Verify receipts as findings, not one green badge

Return a structured report:

type Finding = {
  check: string;
  result: 'pass' | 'fail' | 'unknown';
  detail: string;
};

type EvidenceReport = {
  integrity: 'valid' | 'invalid' | 'unknown';
  authority: 'valid' | 'invalid' | 'unknown';
  executionBinding: 'valid' | 'invalid' | 'unknown';
  outcome: 'confirmed' | 'failed' | 'reversed' | 'disputed' | 'unknown';
  findings: Finding[];
};

Run checks in a defined order:

1. Validate the receipt schema and declared version.
2. Resolve the issuer and verification method.
3. Apply algorithm, audience, time and key-status policy.
4. Recreate the canonical signing payload and verify the signature.
5. Resolve the mandate and its status at the relevant time.
6. Recompute the retained request digest.
7. Match the decision and any approval to the same transaction digest.
8. Match provider reference and idempotency key to the authoritative system.
9. Resolve later reconciliation, correction, reversal or dispute records.
10. Verify any external anchor against the exact evidence-package digest.

A missing request artifact should produce unknown execution binding even when the receipt signature is valid. A current key compromise can change assurance for historical receipts depending on the compromise policy and trusted-time evidence.

Failure cases expose overclaiming

A single "verified" badge is dangerous when it hides these distinctions.

When to use each mechanism

Use operational logs for debugging, telemetry, incident response and high-cardinality search. Use signed receipts when another service, auditor or counterparty must verify a compact transaction record without receiving the entire log system. Use an external anchor when independent timestamping or tamper evidence justifies the added privacy, cost, finality and governance complexity.

Many enterprise actions need logs and receipts but no blockchain. Cross-company or public-registry scenarios may benefit from all three.

Questions about logs, receipts and blockchain proof

Does a blockchain prove that an enterprise action happened?

It can prove that a digest or record was included under a particular consensus and timestamp model. It does not independently prove that the source event occurred, that the source was complete or that the person publishing the record was truthful.

Is a signed action receipt an audit log?

No. A receipt is a compact attestation intended for later verification. An audit log is a higher-volume operational history used for search, investigation and reconstruction. A mature design links them by transaction and digest while retaining each for its own purpose.

Can a valid receipt prove there was no bypass?

Not alone. The signature proves integrity and issuer attestation for the signed fields. A no-bypass claim also depends on network controls, credential isolation, coverage testing and evidence from every permitted execution path.

Do enterprise agent systems need blockchain anchoring?

Usually not for every action. Signed receipts plus controlled retention may be sufficient inside one enterprise. External anchoring becomes more relevant when independent timestamping, cross-company verification or public-registry accountability justifies the additional privacy, governance and operational cost.

Current Intelliger and OATI boundary

OATI's public developer preview implements Receipt schemas, builders, RFC 8785 canonicalization, Ed25519 and ES256 profiles, verification, middleware and cross-language conformance fixtures. The deployed control-plane vertical slice emits an issuance Receipt for a credential ceremony.

Durable bilateral evidence, retention, audit-package export, dispute workflows and independent cryptographic review remain incomplete. The target Intelliger evidence service and outcome ledger are not deployed commercial services. A valid unilateral receipt supports verification that the issuer attested to its signed fields under the resolved key. It does not independently prove the event, absence of bypass or counterparty agreement.

Use the canonical AI agent audit-trail guide for the full evidence model, review the Concordium Agent Registry enterprise architecture, compare action receipts with application logs and follow an auditable MCP transaction from request to receipt.

Expert review required before publication: cryptography, audit and records specialists should verify the proof boundaries, historical-key policy, retention guidance and all current implementation statements.

To inspect the current Receipt objects and verification path, open the OATI documentation and lookup tools.