Zero-Trust Audit

A2B is built so that you do not have to trust ATEL. Every meaningful claim about a past transaction — the signed intent, the on-chain fund flow, the audit trail, the merchant's delivery — produces public evidence that any third party can recompute with their own tools.

This page shows how. The three commands below are part of the ATEL SDK and run against public endpoints plus the blockchain. They intentionally do not require Platform authentication. All you need is the intentId of the order you want to audit.

What Each Command Proves

Running all three with a green result establishes — without trusting ATEL — that the transaction was initiated by an authorized key, executed inside the declared envelope, and completed with the stated outcome.

Command 1 · Verify the Intent

atel bitrefill verify-intent <intentId>

What it does:

1. Fetches the Intent JSON from the Platform's public verification API.
2. Extracts the public key from the Intent's issuerDid.
3. Recomputes the canonical signing payload and verifies the Ed25519 signature.
4. Fetches the on-chain Order from A2BOrderGateway.getOrder(intentHash).
5. Compares the on-chain fields (userAddr, maxAmount, deadline) against the Intent.

A PASS result means: the Intent was genuinely signed by the DID's private key, and the on-chain Order matches the signed declaration byte-for-byte.

A failure means either the signature is bad or the on-chain record diverges from the Intent — in either case the transaction should not be trusted.

Command 2 · Audit the Execution Trace

atel bitrefill audit <intentId>

What it does:

1. Fetches every ActionTrace record for the order (hash-chained list of tool calls).
2. Recomputes each record's hash locally.
3. Rebuilds the Merkle tree from the record hashes.
4. Compares the local Merkle root against the auditRoot field recorded on-chain in the executePayment transaction.

A PASS means: no record has been edited, inserted, or removed since the executePayment transaction was mined. The audit trail is byte-identical to what was anchored at settlement.

A failure means someone (the Platform, a compromised operator, a bug) changed the trace after the fact. The on-chain anchor is immutable, so a mismatch points to data having been tampered with.

Command 3 · Verify the Completion Proof

atel bitrefill proof <intentId>

What it does:

1. Looks up the CompletionProof anchor transaction by intent ID.
2. Fetches the full anchored JSON via the verification API.
3. Recomputes the hash and confirms it matches the on-chain anchor.
4. Compares the anchored verdict (DELIVERED / FAILED / EXPIRED) against the Platform-side order state.

A PASS means: the proof on-chain is genuine, matches the off-chain representation, and reports the same verdict the Platform reports.

What "Green" Buys You

If all three commands return PASS:

• You know the signature on the Intent is real.
• You know the on-chain order matches the signed Intent.
• You know the audit trail has not been edited since it was anchored.
• You know the CompletionProof says what the Platform says it says.

From there, the chain of trust is: Intent signer → on-chain Order → audit root → CompletionProof → delivery hash. Each link is either a cryptographic signature, a hash, or a blockchain anchor. None of them depend on ATEL being online, honest, or even existing.

When To Run the Audit

You can run these commands at any time after the order is complete. Typical situations:

• You want to trust a high-value order before acting on the delivered item.
• You are an auditor or compliance officer producing evidence for a regulator.
• You are investigating a dispute — "did this transaction actually happen the way the system claims?"
• You are integrating A2B into your own workflow and want to validate the evidence model.

Dashboard Integration

Your ATEL dashboard performs the same three audits automatically on every order and shows a single status badge:

• Green — all three checks passed.
• Amber — at least one check failed or is inconclusive. Click through for details.
• Pending — the order has not yet reached the state where a check applies.

The dashboard check uses the same SDK code paths. You can always drop to the CLI to reproduce the result independently.