Circle Nanopayments

Spending policy proofs for AI agents transacting in USDC.

Verified Nanopayments brings cryptographic intent verification to Circle's Nanopayments rail. Every agent payment carries a portable ZK proof that the payment intent satisfied a formally verified spending policy. The seller verifies that proof before accepting the payment, and writes a permanent on-chain record that anyone can read later. The result is a payment whose authorization any third party can audit, with no API key and no trust in ICME required.

Intent verification is the missing layer above the signing engine: a pre-action check on the agent's natural-language purpose, run before any signature exists and before money moves, emitting a counterparty-verifiable proof the seller can validate without ever seeing the policy.

No Circle SDK fork. No changes to x402. The seller adds a public verification call before honoring payment. The buyer attaches a proof identifier to the request. The settlement flow on Arc is unchanged.

Status. This page describes Preflight's Circle Nanopayments integration as designed. The deployed system is the source of truth: the on-chain contract at the address linked below, the public verification endpoint at api.icme.io, and the live ICME-Lab repositories. Some implementation details on this page may lag behind the deployed version. If anything here conflicts with the on-chain contract or the API's actual behavior, the deployed system wins.

The authorization gap

Circle's Nanopayments let AI agents pay for things instantly with USDC. Under the hood, a TEE (Trusted Execution Environment) checks that the agent's EIP-3009 signature is valid. But "valid signature" and "should this payment happen" are two different questions.

A compromised agent can sign a perfectly valid authorization to send 0.5 USDC to an attacker. The signature is real. The TEE will accept it. The money moves. Nothing in the x402 protocol asks "does this payment comply with the agent's spending policy?"

That's the gap. Authentication without authorization.

Circle Agent Wallets (May 2026) close part of this with wallet-side spending policies (caps, allowlists). That solves numeric guardrails enforced at signing. It does not solve semantic guardrails (intent, urgency tactics, purpose mismatch) and does not produce a counterparty-verifiable receipt. Preflight fills that gap and composes cleanly with Agent Wallet policies.

How Preflight closes it

Preflight runs upstream of signing. The seller verifies the proof out of band before honoring the x402 payment.

Step by step:

1. Agent wants to make a payment. Standard LLM tool-call output describes the action in natural language ("pay 0.001 USDC to WeatherNode for current weather data").

2. Preflight checks the intent. The action is sent to POST /v1/checkIt. ICME's API runs three independent verification paths against the firm's compiled policy: a local extraction model (OxiZ) that maps the action text to policy variables, Automated Reasoning that independently translates the action to formal logic, and the Z3 SMT solver. The system fails closed: any UNSAT from any path blocks the action. The API returns result (SAT or UNSAT), a proof_id, and the policy_hash of the compiled policy.

3. The buyer conveys the proof_id to the seller. This happens at the application layer, alongside the x402 payment request. The proof itself is not transported by x402. Three options:

   • Request body field. Simplest. The buyer adds proof_id to the request body, the seller's middleware reads it. Recommended for new integrations.

   • Non-x402 HTTP header (e.g. X-Preflight-Proof-Id). Works at the HTTP layer. Not part of the x402 protocol; the x402 v2 transport spec defines three named headers (PAYMENT-REQUIRED, PAYMENT-SIGNATURE, PAYMENT-RESPONSE) and is silent on additional headers, so this is non-standard but not forbidden.

   • x402 v2 PaymentPayload extensions field. The x402 v2 schema provides for scheme-specific extension data, but the field's semantics are not yet standardized across schemes. Pin to your scheme's convention if you use this path. Best forward-looking target once the field's semantics solidify.

4. Seller verifies the proof. Before accepting payment, the seller's middleware calls POST /v1/verifyProof against ICME's public endpoint with the proof_id. No API key is required. If valid === true and claimed_result === "SAT", the seller proceeds.

5. x402 payment fires. Circle's GatewayClient settles the EIP-3009 authorization on Arc.

6. Seller attests on-chain. After settlement, the seller writes a permanent record on the NanopaymentAttestation contract: attest(proofId, policyHash, paymentTxHash, RESULT_SAT). The record stores only hashes. No policy contents. No PII. This on-chain record is the durable, anyone-can-read audit surface.

If a prompt injection or compromised state causes the agent to attempt an unauthorized payment, step 2 returns UNSAT. The check happens pre-action: the payment is never signed, no EIP-3009 authorization ever exists, and no money moves. The seller can optionally attest the UNSAT result on chain (with paymentTxHash = 0x0) to create a denial record.

Verification is repeatable by design. A zero-knowledge proof is independently and repeatedly verifiable by anyone who holds it, without re-running the check and without trusting ICME. On Circle, the durable public record is the on-chain attestation, which any party can read from the contract any number of times.

Two layers of policy enforcement

Policy enforcement for agent payments happens at two layers. Both are useful. Neither replaces the other. Preflight runs at the intent layer and is built to compose with existing signing-layer infrastructure.

The intent layer. Preflight evaluates what the agent is trying to do, in natural language, before any signature exists. It answers semantic questions: is this action consistent with the firm's policy? Was the agent socially engineered? Is the stated purpose plausible? Is the urgency real? These questions cannot be answered from the structured fields of a signed transaction. They require reading the agent's reasoning trail before it is reduced to bytes.

The signing layer. Wallet and key-management infrastructure governs what a key is allowed to sign: transaction destination, value, contract calls, consensus rules, structured-message fields. These policies evaluate the structured fields of the signing request. They are essential, and they are well-served by existing infrastructure such as Circle Agent Wallets, including features like Circle's Spending Policies for agent wallets (per-transaction caps, time-bound limits, recipient and contract allowlists and blocklists, all enforced at signing time).

Why the layers are distinct

A signing-layer policy can say "no more than $5/day to non-allowlisted addresses." It cannot say "do not pay this invoice if the agent was instructed to bypass review." A signing-layer policy can say "only call these three contracts." It cannot say "do not act if the agent's stated purpose contradicts the firm's policy." Intent is upstream of structure. By the time an action reaches the signing layer, the intent is already encoded in fields that the signing-layer policy cannot meaningfully inspect.

Preflight's compiled policies live in formal logic (SMT-LIB), so they can describe properties the signing layer cannot.

Where intent verification sits in the stack

       Agent reasoning             ◀── Preflight runs here (intent)
              │
              ▼
       Action description          ◀── /v1/checkIt returns proof_id + policy_hash
              │
              ▼
       Proof conveyance + verify   ◀── /v1/verifyProof (seller-side, out-of-band)
              │
              ▼
       EIP-3009 authorization      ◀── Circle Agent Wallet / Spending Policies (signing)
              │
              ▼
       Gateway settlement          ◀── Circle Nanopayments (settlement)
              │
              ▼
       On-chain attestation        ◀── NanopaymentAttestation (durable record)

Drop-in claim

A seller who already accepts Circle Nanopayments can add Preflight by inserting one verification call before honoring payment. No SDK fork. No protocol change. No buyer-side wallet swap.

What Preflight does not do

Preflight is a single-purpose primitive. It does not:

• replace the wallet, the signer, or the settlement engine.

• enforce signing-layer policies (caps, allowlists, contract restrictions). Use Circle Spending Policies for those.

• evaluate transactions that have already been signed. The check runs pre-action by design.

• store policy contents. Only the policy_hash is published.

• require buyer or seller to disclose business logic. The proof attests SAT/UNSAT against the compiled policy without revealing the policy.

Composition with signing engines

A. Preflight + Circle Agent Wallet with Spending Policies

Buyer holds funds in a Circle Agent Wallet configured with Spending Policies: per-transaction caps, time-bound limits (daily, monthly), and recipient or contract allowlists and blocklists. Preflight runs upstream on the intent. The wallet still enforces its Spending Policies at signing time. The seller verifies the proof before honoring payment. Two independent defenses at two distinct layers, no overlap.

B. Preflight + plain EIP-3009 signer

Buyer uses any EIP-3009 compatible wallet or key manager. Preflight is independent of the signing engine. The integration is the same: Preflight evaluates the intent, returns a proof, the seller verifies the proof before honoring the payment.

Sample use case: Data API agent

An autonomous agent that pays per-call for live data. Weather, market data, traffic, news. The firm wants its agent to spend only on legitimate data calls relevant to its task, with no urgency manipulation, no override attempts, and no calls outside its declared service category.

The spending policy in plain English

The agent may pay for data API calls if all of the following hold:
- The amount per call is between 0.001 and 0.01 USDC.
- The service category is "weather", "market_data", "traffic", or "news".
- The agent has not been instructed to bypass review, ignore prior rules,
  or treat the request as urgent.
- The agent's stated purpose is consistent with the declared service
  category.
- The recipient is a known data provider (allowlist match).

Reject otherwise.

This natural-language policy is sent to POST /v1/makeRules. The API returns a compiled SMT-LIB policy and a policy_hash (a content-addressed fingerprint of the compiled artifact). Every later checkIt call references that policy_hash. The compiled policy lives on ICME's servers and is never disclosed to sellers, regulators, or counterparties.

What this policy prevents

• A prompt-injected agent that has been told "ignore your spending limit, this is urgent." The urgency-tactic variable extracted from the action text is true. UNSAT.

• A compromised agent paying for a service outside its declared category. The service-category variable extracted does not match the allowlist. UNSAT.

• An agent attempting an override ("the user said it's OK to skip review"). The override-attempt variable is true. UNSAT.

• A standard, legitimate weather data call within the cap. All extracted variables satisfy the compiled policy. SAT. Proof generated.

API reference

Endpoint	What it does	Cost
POST /v1/checkIt	Check an action against a compiled policy. Returns SAT/UNSAT, proof_id, and policy_hash.	1 credit ($0.01)
POST /v1/checkRelevance	Quick check: is this action even relevant to the policy?	Free
POST /v1/verifyProof	Publicly verify a proof by ID. No API key.	Free
GET /v1/proof/{id}	Get proof status (authenticated). Returns 404 until generation completes.	Free
POST /v1/makeRules	Compile a natural language policy into SMT-LIB. One-time.	300 credits ($3.00)

Both makeRules and checkIt return SSE streams, not plain JSON. Each line is data: {...}\n\n. The final event has "step":"done" and contains the result. For a single-JSON response without streaming, use POST /v1/checkItProd (same logic, same fields).

checkIt final SSE event:

{
  "step": "done",
  "result": "SAT",
  "detail": "All constraints satisfied.",
  "proof_id": "2e45c585-b7ec-4159-9cec-b3977fbcbbdc",
  "policy_id": "22b0a446-9b09-4796-ae44-e6c2b2466037",
  "policy_hash": "60c79bbc4f8ac087de1110fa0e347292f35b6d2943a2a4ccd18ae991a5d64418",
  "claimed_result": "SAT"
}

result is the verdict (SAT permitted, UNSAT blocked) after all three verification paths reconcile. The system fails closed: any UNSAT from any path blocks the action. A zero-knowledge proof is generated in the background (proof generation runs asynchronously and is not on the critical path), referenced by proof_id.

verifyProof response (plain JSON):

{
  "valid": true,
  "verify_ms": 406,
  "policy_hash": "60c79bbc4f8ac087de1110fa0e347292f35b6d2943a2a4ccd18ae991a5d64418",
  "claimed_result": "SAT",
  "used": true,
  "proof_bytes_len": 92986,
  "trace_length": 524288,
  "created_at": "2026-05-09T00:11:20.880850Z"
}

policy_hash is the content-addressed fingerprint of the compiled SMT policy the action was checked against, returned as a bare hex string. (On chain it is stored as a bytes32; the seller converts when it writes the attestation.) A regulator or counterparty receiving a proof_id can call verifyProof, read the policy_hash, and confirm the proof was generated against the specific policy version the firm claims was active. The policy contents remain private. The durable public record is the on-chain attestation.

New accounts get 325 credits ($5 USDC on Base). Top-ups are $5 for 500 credits.

Request flow

 Buyer (agent)                    Preflight                   Seller
      |                               |                         |
      |  POST /v1/checkIt             |                         |
      |  "pay 0.001 USDC to           |                         |
      |   WeatherNode for weather"    |                         |
      |------------------------------>|                         |
      |                               |                         |
      |  result: SAT                  |                         |
      |  proof_id: abc-123            |                         |
      |  policy_hash: 60c79bbc...     |                         |
      |<------------------------------|                         |
      |                                                         |
      |  GET /api/weather/verified                              |
      |  Body (or non-x402 header):                             |
      |    proof_id: abc-123                                    |
      |  + standard x402 payment authorization                  |
      |-------------------------------------------------------->|
      |                                                         |
      |                               |  POST /v1/verifyProof   |
      |                               |  {"proof_id":"abc-123"} |
      |                               |<------------------------|
      |                               |  { valid: true,         |
      |                               |    claimed_result:"SAT" }
      |                               |------------------------>|
      |                                                         |
      |                                  proof valid + payment  |
      |                                  accepted = 200 OK      |
      |<--------------------------------------------------------|

Two independent checks. The x402 payment authorization authenticates the buyer (the EIP-3009 signature is valid). The Preflight proof authorizes the intent (the action satisfied the compiled policy). The seller verifies both.

Two USDC flows. Base mainnet: the buyer pays $0.01/check to Preflight for the proof economy. Arc: the buyer pays per-call to the seller via Nanopayments. Same USDC, two chains, both Circle.

Seller integration

The seller adds proof verification as Express middleware before gateway.require(). The proof_id is read from wherever the integration places it: a request body field (simplest), a non-x402 HTTP header (works at the HTTP layer; not part of the x402 protocol), or the x402 v2 PaymentPayload extensions field (forward-looking, semantics not yet standardized).

// proof-guard.ts. verify the Preflight proof before accepting payment
const proofId = req.body.proof_id || req.headers["x-preflight-proof-id"];
if (!proofId) return res.status(400).json({ error: "MISSING_PROOF_ID" });

const r = await fetch("https://api.icme.io/v1/verifyProof", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ proof_id: proofId }),
});

const { valid, claimed_result, policy_hash } = await r.json();
if (!valid || claimed_result !== "SAT") {
  return res.status(403).json({ error: "PROOF_INVALID_OR_NOT_SAT" });
}

res.locals.policyHash = policy_hash; // keep for the on-chain attestation
next();                              // proof checks out. let gateway.require() handle the payment

Wire it up in Express:

app.get("/api/weather/verified",
  proofGuard,                // 1. verify proof (Preflight)
  gateway.require("$0.001"), // 2. accept payment (Nanopayments)
  handler                    // 3. serve data
);

After settlement, the seller writes the on-chain attestation:

import { ethers } from "ethers";
import attestationAbi from "./NanopaymentAttestation.abi.json";

const attestation = new ethers.Contract(
  "0x76ce30319c561beaa6dcf936017fcbb1e84b18b1",
  attestationAbi,
  sellerSigner
);

await attestation.attest(
  ethers.keccak256(ethers.toUtf8Bytes(proofId)),       // proofId hashed
  "0x" + policyHash,                                    // bare hex from verifyProof, to bytes32
  paymentTxHash,                                        // from Gateway settlement
  1                                                     // RESULT_SAT
);

No SDK changes required

Buyer side. Any standard x402 client works. The buyer includes the proof_id in the request body (recommended) or a non-x402 HTTP header. The extensions field in x402 v2 PaymentPayload is a forward-looking target once its semantics are standardized at the scheme level.

Seller side. Express middleware runs before gateway.require(). No Circle SDK modification needed. The proof is verified via ICME's public endpoint. No API key, no account required.

On-chain attestation

After every verified payment, the seller writes a permanent record to the NanopaymentAttestation contract on Arc. The record binds the off-chain ZK proof to the on-chain payment. Storage is hashes only. No policy bodies. No PII. Anyone with the proofId can independently verify "this proof authorized this Nanopayment by this seller" by reading the contract directly, any number of times. No ICME access required. This is the durable public record of the decision.

Deployed on Arc Testnet (chainId 5042002):

Contract	Address	Explorer
NanopaymentAttestation	0x76ce30319c561beaa6dcf936017fcbb1e84b18b1	view on Arc Testnet explorer

The on-chain bytecode at that address is the primary source of truth. Anyone can verify the contract behavior by reading the chain directly. The Solidity source is reproduced below for transparency.

Contract source

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

/// @title NanopaymentAttestation
/// @notice Single-purpose attestation registry: a seller asserts that a
///         Circle Nanopayment it just settled was authorized by a
///         Preflight ZK proof. One write per (proofId, seller) pair.
///
///         The record stores only hashes. No policy contents. No PII.
///         Anyone can independently verify "this proofId was used to
///         authorize this on-chain payment by this seller" without
///         needing access to ICME or the buyer's wallet.
///
/// @dev    Deployed on Arc Testnet (chainId 5042002):
///         0x76ce30319c561beaa6dcf936017fcbb1e84b18b1
///         Explorer: https://testnet.arcscan.app/address/0x76ce30319c561beaa6dcf936017fcbb1e84b18b1
contract NanopaymentAttestation {

    /// @dev Result codes for the off-chain Preflight check.
    uint8 constant RESULT_UNSAT = 0;
    uint8 constant RESULT_SAT   = 1;

    struct Attestation {
        bytes32 proofId;       // ICME Preflight proof_id (keccak256 of UUID string)
        bytes32 policyHash;    // ICME policy_hash (compiled SMT policy fingerprint)
        bytes32 paymentTxHash; // Arc Gateway settlement tx (0x0 if UNSAT / blocked)
        uint8   result;        // RESULT_SAT or RESULT_UNSAT
        address seller;        // msg.sender at attestation time
        uint256 timestamp;     // block.timestamp at attestation time
    }

    /// @dev proofId => attestation. Single-use: cannot be overwritten.
    mapping(bytes32 => Attestation) private _attestations;

    /// @dev seller => list of proofIds attested by that seller, in order.
    mapping(address => bytes32[]) private _sellerProofs;

    /// @dev Total count of attestations across all sellers.
    uint256 public totalAttestations;

    event ProofAttested(
        bytes32 indexed proofId,
        bytes32 indexed policyHash,
        address indexed seller,
        uint8   result,
        bytes32 paymentTxHash,
        uint256 timestamp
    );

    error AlreadyAttested(bytes32 proofId);
    error InvalidResult(uint8 result);
    error ZeroProofId();

    /// @notice Record that a Preflight proof authorized a Nanopayment.
    /// @dev    Reverts if the proofId has already been attested (single-use).
    /// @param  proofId        keccak256 hash of the ICME proof UUID
    /// @param  policyHash     ICME policy_hash returned by checkIt
    /// @param  paymentTxHash  Arc Gateway settlement tx hash; 0x0 for UNSAT
    /// @param  result         RESULT_SAT (1) or RESULT_UNSAT (0)
    function attest(
        bytes32 proofId,
        bytes32 policyHash,
        bytes32 paymentTxHash,
        uint8   result
    ) external {
        if (proofId == bytes32(0)) revert ZeroProofId();
        if (result > RESULT_SAT) revert InvalidResult(result);
        if (_attestations[proofId].timestamp != 0) revert AlreadyAttested(proofId);

        _attestations[proofId] = Attestation({
            proofId:       proofId,
            policyHash:    policyHash,
            paymentTxHash: paymentTxHash,
            result:        result,
            seller:        msg.sender,
            timestamp:     block.timestamp
        });

        _sellerProofs[msg.sender].push(proofId);
        unchecked { totalAttestations += 1; }

        emit ProofAttested(
            proofId,
            policyHash,
            msg.sender,
            result,
            paymentTxHash,
            block.timestamp
        );
    }

    /// @notice Read a single attestation by proofId.
    /// @return The Attestation struct; `timestamp == 0` means no record exists.
    function getAttestation(bytes32 proofId)
        external
        view
        returns (Attestation memory)
    {
        return _attestations[proofId];
    }

    /// @notice Check if a proofId has been attested.
    function isAttested(bytes32 proofId) external view returns (bool) {
        return _attestations[proofId].timestamp != 0;
    }

    /// @notice Total number of attestations made by a given seller.
    function sellerAttestationCount(address seller)
        external
        view
        returns (uint256)
    {
        return _sellerProofs[seller].length;
    }

    /// @notice Page through a seller's attestation history.
    /// @param  seller  address that wrote the attestations
    /// @param  offset  index to start at
    /// @param  limit   maximum number of proofIds to return
    function sellerProofs(address seller, uint256 offset, uint256 limit)
        external
        view
        returns (bytes32[] memory)
    {
        bytes32[] storage all = _sellerProofs[seller];
        uint256 total = all.length;
        if (offset >= total) return new bytes32[](0);

        uint256 end = offset + limit;
        if (end > total) end = total;
        uint256 size = end - offset;

        bytes32[] memory page = new bytes32[](size);
        for (uint256 i = 0; i < size; i++) {
            page[i] = all[offset + i];
        }
        return page;
    }
}

Design notes worth understanding:

• Single-use. attest reverts with AlreadyAttested if the same proofId is written twice. A proof cannot be reused to attest a second payment.

• Hashes only. The contract stores proofId, policyHash, paymentTxHash as bytes32 and never sees the underlying policy text or proof bytes. The on-chain footprint per attestation is fixed-size and private.

• No admin keys, no upgradability. The contract is a write-once registry. There is no owner, no proxy, no governance, no upgrade path. What you see is what runs.

• Denial records. A seller can attest an UNSAT result with paymentTxHash = 0x0 to create a durable record that an attempted payment was blocked by Preflight. Useful for regulator-facing audit trails where blocked attempts matter as much as approved ones.

• Indexed events. ProofAttested indexes proofId, policyHash, and seller, so all three are filterable in standard event queries.

Reading attestations

Any party with a proofId can independently verify the on-chain record:

const attestation = await contract.getAttestation(proofIdHash);
// returns: { proofId, policyHash, paymentTxHash, result, seller, timestamp }

if (attestation.timestamp === 0n) {
  // no attestation exists for this proofId
}

Paging through a seller's attestation history:

const proofs = await contract.sellerProofs(sellerAddress, 0, 100);

Listening for new attestations:

contract.on("ProofAttested", (proofId, policyHash, seller, result, paymentTxHash, timestamp) => {
  // ...
});

Key differentiator

Every spending control offers controls (if-statements). Preflight offers spending proofs (ZK):

	Controls	Proofs
Mechanism	Check rules before paying	Mathematically prove all constraints satisfied
Verifiability	Trust the middleware ran	Any party can call verifyProof without an API key
Privacy	Auditor sees the policy	Auditor verifies without seeing the policy
Auditability	Log files	Cryptographic receipts aligned with EU AI Act Article 12 logging

Why Arc

Arc is the deliberate choice for the settlement leg of this stack, not a default. Four Arc properties this design depends on:

1. Deterministic settlement. Arc's stablecoin-native consensus gives every Nanopayment a known finality window. GatewayClient.pay returns once settlement is final. No probabilistic-confirmation polling, no reorg hedge.

2. Predictable, sub-cent fees. USDC is the native gas asset on Arc. Transfer cost is bounded and stable in stablecoin terms. That is what makes per-API-call nanopayments economically defensible. $0.001 for the call, fee well under $0.001. The same math on Ethereum mainnet or a general-purpose L2 inverts immediately on any spike.

3. Agent-native throughput. EIP-3009 transferWithAuthorization batched by Circle Gateway means an agent pre-funds once and draws down without a per-call onchain settlement round trip. Capital sits in the Gateway, not in N idle hot wallets.

4. Public attestation surface. Arc isn't only where USDC moves. It's where the binding between the off-chain ZK proof and the on-chain payment becomes a permanent record. The record stores hashes only, browsable on the Arc Testnet explorer.

Capital efficiency

Two compounding effects at agent scale:

1. Pre-funded Gateway, single pool. Instead of one funded EOA per agent or per service, an operator pre-funds one Gateway balance. Available balance shows separately from on-chain wallet balance. That split is the capital-efficiency lever Circle's design already gives you, and Preflight preserves it.

2. Zero-waste blocked path. UNSAT actions never produce an EIP-3009 signature, so they never burn settlement throughput or hit a revert. On a "check at signing" stack, every blocked attempt either consumes a settlement slot or gets caught mid-batch. Preflight + Arc moves that cost to zero. UNSAT exits in a few seconds with no signature, no settlement, no waste.

These properties (deterministic settlement, predictable fees, agent-native throughput, public attestation surface) are what make the proof-gated path work economically and architecturally. On a chain without them, per-API-call nanopayments break, and the off-chain proof cannot anchor itself to anything anyone else can audit.

Measured performance

Latency measurements from Arc Testnet runs of the reference implementation. Numbers vary with policy complexity, action text length, and network conditions. Each call logs preflightMs and paymentMs.

Stage	Typical latency	Notes
checkIt (three verification paths)	a few seconds	Returns SAT/UNSAT immediately. ZK proof generation runs asynchronously.
ZK proof generation (JOLT zkVM)	tens of seconds	One-time per check. Off the critical path. Amortizable across a session.
verifyProof (seller-side, public)	sub-second	No API key. Pure verification.
GatewayClient.pay (Arc Testnet)	sub-second	Observed in our runs on Arc Testnet.
Blocked path (UNSAT)	a few seconds	No signature, no settlement, no proof wait.

Today's proofs are produced by JOLT, ICME's adaptation of the JOLT zkVM (originally from a16z Crypto Research, by Arasu Arun, Srinath Setty, and Justin Thaler), wrapping the SMT verification of the compiled policy. The proving pipeline is functional and generates real cryptographic proofs today; it has not yet completed a formal security audit, and the policy decision returned by checkIt does not block on proof generation. JOLT Atlas, ICME's zkML framework, is a separate effort that extends cryptographic coverage to the natural-language extraction step; it is under active development and does not power production verification today.

Compliance & auditability

Preflight produces a cryptographic receipt for every agent payment decision. This matters for three live regulatory regimes:

1. EU AI Act (Article 12 logging, Article 50 transparency). The EU AI Act requires automatic recording of events relevant to risk identification and substantial modification, and transparency about AI system operation. Every Preflight proof binds an action description to a policy_hash, producing a content-addressed cryptographic record aligned with the logging obligation. The compiled policy contents remain private to the firm; only the hash is published, satisfying decision-provenance use cases without exposing internal policy logic. Alignment with the logging obligation is one component of compliance, not a substitute for the broader conformity-assessment, oversight, and quality-management obligations the Act imposes.

2. MiCA and payment-services rules in the EU. Authorization trails for automated transfers. A proof_id is a portable audit token that a payment processor or supervisor can verify, and the on-chain attestation provides the durable record.

3. US Treasury and SOX-style internal controls. Agents acting on a corporate treasury can produce per-payment proofs binding each transfer to a board-approved spending policy.

Today most "agent guardrails" are log lines in a private system. Preflight upgrades that to a verifiable receipt anchored to a permanent on-chain record.

Costs

Item	Cost	When
ICME account creation	5 USDC on Base mainnet (325 credits)	Once
Credit top-up	5 USDC per 500 credits	As needed
Policy compilation	300 credits ($3)	Once per policy
Policy check (checkIt)	1 credit ($0.01)	Per check
Arc Testnet USDC	Free via faucet	As needed
x402 Nanopayments	$0.001 to $0.005 per API call	Per API call

Try it yourself

Resource	Link
On-chain attestation contract	testnet.arcscan.app/address/0x76ce30319c561beaa6dcf936017fcbb1e84b18b1
Public verification endpoint	https://api.icme.io/v1/verifyProof
Circle Nanopayments docs	developers.circle.com/gateway/nanopayments
Circle Spending Policies	developers.circle.com/agent-stack/agent-wallets/wallet-operations/custom-policies
JOLT Atlas	github.com/ICME-Lab/jolt-atlas

Research foundations

The cryptographic primitives that make Preflight work draw on published research:

• JOLT (a16z Crypto Research). The zkVM by Arasu Arun, Srinath Setty, and Justin Thaler. SNARKs for virtual machines via lookups. This is the proving system behind Preflight's production proofs today, wrapping the SMT verification.

• JOLT Atlas: Verifiable Inference via Lookup Arguments in Zero Knowledge (arXiv:2602.17452). ICME's zkML framework extending the JOLT proving system to ONNX model inference. The forthcoming layer that will extend cryptographic coverage to the natural-language extraction step. Not yet in production.

• SMT and automated reasoning. The Preflight pipeline draws on the Automated Reasoning Checks lineage. DM for access to the upcoming paper or to collaborate.

---

Nanopayments moves money at the speed of AI. Preflight proves it moved correctly.