# Circle Nanopayments **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. The result is a payment that any third party can audit cryptographically, 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 the action through a three-stage pipeline: an LLM extractor produces structured fields from the action text, an SMT solver verifies the firm's compiled policy against those fields, and a consensus rule (fail-closed on UNSAT, reject on ambiguous extraction) gates the result. The API returns SAT or UNSAT, plus 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 field exists in the x402 v2 schema and there is a `@x402/extensions` npm package, 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. 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. ### 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 mainnet 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 `urgencyTacticDetected` field extracted by the LLM is true. UNSAT. * A compromised agent paying for a service outside its declared category. The `serviceCategory` extracted does not match the allowlist. UNSAT. * An agent attempting an override ("the user said it's OK to skip review"). The `overrideAttempt` field is true. UNSAT. * A standard, legitimate weather data call within the cap. All extracted fields 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. Single-use. No API key. | Free | | `GET /v1/proof/{id}` | Get proof status (authenticated). | 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. **checkIt final SSE event:** ```json { "step": "done", "result": "SAT", "extractor_result": "SAT", "smt_result": "SAT", "consensus": "ALLOW", "check_id": "uuid", "proof_id": "uuid", "policy_hash": "0x...", "detail": "Satisfiable", "extracted": { "transferAmount": 0.001, "urgencyTacticDetected": false, "...": "..." } } ``` The `extractor_result` reports what the LLM extractor produced from the action text. The `smt_result` reports the SMT solver's verdict against the compiled policy. The `consensus` field is the final decision after the consensus rule applies (fail closed on UNSAT, reject on ambiguous extraction). **verifyProof response (plain JSON):** ```json { "valid": true, "claimed_result": "SAT", "policy_hash": "0x...", "used": true } ``` `policy_hash` is the content-addressed fingerprint of the compiled SMT policy the action was checked against. 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. New accounts get 500 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: 0x... | | |<------------------------------| | | | | 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). ```typescript // 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 } = await r.json(); if (!valid || claimed_result !== "SAT") { return res.status(403).json({ error: "PROOF_INVALID_OR_NOT_SAT" }); } next(); // proof checks out. let gateway.require() handle the payment ``` Wire it up in Express: ```typescript 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: ```typescript 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 policyHash, // from verifyProof response 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; the field exists in the schema today but is not yet documented 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. No ICME access required. **Deployed on Arc Testnet (chainId 5042002):** | Contract | Address | Explorer | | ---------------------- | -------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | NanopaymentAttestation | `0x76ce30319c561beaa6dcf936017fcbb1e84b18b1` | [view on Arc Testnet explorer](https://testnet.arcscan.app/address/0x76ce30319c561beaa6dcf936017fcbb1e84b18b1) | 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 ```solidity // 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: ```javascript 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: ```javascript const proofs = await contract.sellerProofs(sellerAddress, 0, 100); ``` Listening for new attestations: ```javascript 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 (extractor + SMT solver + consensus) | a few seconds | Returns SAT/UNSAT immediately. ZK proof generation runs asynchronously. | | ZK proof generation (JOLT-Atlas) | 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. | The ZK proof generation step uses JOLT-Atlas, an active research project from ICME Labs that extends the JOLT zkVM (originally from a16z Crypto Research, by Arasu Arun, Srinath Setty, and Justin Thaler) to zero-knowledge machine learning. JOLT-Atlas should be treated as research-grade software at this stage. We use it as the cryptographic prover for the LLM extractor step. The policy decision returned by `checkIt` does not block on proof generation. ### 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, single-use audit token that a payment processor or supervisor can verify without buyer cooperation. 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 signed, verifiable, single-use receipt anchored to a permanent on-chain record. ### Costs | Item | Cost | When | | ---------------------- | ----------------------------- | --------------- | | ICME account creation | 5 USDC on Base mainnet | 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](https://testnet.arcscan.app/address/0x76ce30319c561beaa6dcf936017fcbb1e84b18b1) | | Public verification endpoint | `https://api.icme.io/v1/verifyProof` | | Circle Nanopayments docs | [developers.circle.com/gateway/nanopayments](https://developers.circle.com/gateway/nanopayments) | | Circle Spending Policies | [developers.circle.com/agent-stack/agent-wallets/wallet-operations/custom-policies](https://developers.circle.com/agent-stack/agent-wallets/wallet-operations/custom-policies) | | JOLT-Atlas | [github.com/ICME-Lab/jolt-atlas](https://github.com/ICME-Lab/jolt-atlas) | ### Research foundations The cryptographic primitives that make Preflight work draw on published research: * **JOLT-Atlas: Verifiable Inference via Lookup Arguments in Zero Knowledge** ([arXiv:2602.17452](https://arxiv.org/abs/2602.17452)). The zkML framework that powers Preflight's verifiable inference. Active research project from ICME Labs extending the JOLT zkVM. * **JOLT (a16z Crypto Research).** The underlying zkVM by Arasu Arun, Srinath Setty, and Justin Thaler. SNARKs for virtual machines via lookups. * **SMT and automated reasoning.** The Preflight pipeline draws on techniques from the SMT and automated-reasoning research lineage. DM for access to the upcoming paper or to collaborate. *** *Nanopayments moves money at the speed of AI. Preflight proves it moved correctly.* --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.icme.io/documentation/agentic-commerce/circle-nanopayments.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.