# Agentic Commerce Clearing House

On April 2, 2026, the Linux Foundation launched the [x402 Foundation](https://www.x402.org/) with backing from Google, Microsoft, Visa, Mastercard, Stripe, Amazon Web Services, and more than 20 other organizations. The protocol embeds stablecoin payments directly into HTTP, allowing AI agents to pay for services, data, and goods without human intervention. Cloudflare, which proxies roughly 20% of all web traffic, already sends over 1 billion HTTP 402 responses daily. On Solana alone, x402 has processed over 35 million transactions and $10 million in volume since launch. ([Linux Foundation announcement](https://www.sourcetrail.com/javascript/x402-foundation-the-new-backbone-for-ai-native-payments-on-the-open-web/), [Solana x402 overview](https://solana.com/x402/what-is-x402))

Two days later, [Visa announced](https://www.americanbanker.com/payments/news/visa-mastercard-expand-agentic-ai-deployments) new AI-powered payment dispute resolution and a partnership with Ramp to automate corporate bill payments. Mastercard expanded agentic payments to Hong Kong as part of building an international network for agentic commerce. [Morgan Stanley projects](https://commercetools.com/blog/ai-trends-shaping-agentic-commerce) nearly half of online shoppers will use AI shopping agents by 2030, accounting for approximately 25% of their spending. [IBM estimates](https://www.ibm.com/think/topics/agentic-commerce) agentic commerce could generate between $3 trillion and $5 trillion globally by 2030.

The pipes are being built. The money is starting to move. But nobody is verifying that the guardrails actually ran.

***

#### What a clearing house does

Before the [Depository Trust & Clearing Corporation](https://www.dtcc.com/) (DTCC) existed, every securities trade in the United States was two parties trusting each other to deliver. Brokers physically carried stock certificates between firms. Settlement took five business days. In 1968, the volume of trades overwhelmed the system so badly that the New York Stock Exchange had to close on Wednesdays to process the backlog. The "paperwork crisis" led to the creation of centralized clearing, and eventually the DTCC, which today settles over $2 quadrillion in securities transactions annually.

A clearing house is a neutral intermediary that guarantees settlement between parties that do not trust each other. It does not care who you are. It checks: did both sides meet the requirements? If yes, the trade settles. If no, it does not. The clearing house does not define what each participant's internal policies should be. It verifies that both sides did their homework and that the numbers match.

Agentic commerce is at the same inflection point the securities market hit in 1968. The volume is about to overwhelm the trust model. When a human shops, they trust Visa, and Visa trusts the merchant. When an AI agent buys from another AI agent at machine speed, there is no human trust anchor. There is no Wednesday to close the exchange and catch up.

***

#### The verification gap

The agentic commerce stack has three layers taking shape:

**Payment execution.** [x402](https://www.x402.org/) handles how money moves. An agent requests a resource, the server responds with HTTP 402 including the price in USDC, the agent signs a stablecoin transaction, attaches proof in the header, and retries the request. Settlement happens in seconds on chains like Base or Solana. No accounts, no subscriptions, no human intervention.

**Authorization.** Google's [Agent Payments Protocol (AP2)](https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol) handles who is allowed to spend and how much. It defines governance: what limits apply, how transactions are audited, and how consent is captured.

**Guardrail verification.** This is the gap. x402 moves the stablecoins. AP2 defines the spending authority. Neither one proves that the agent's guardrail policy was actually enforced on this specific transaction.

A [PYMNTS Intelligence report](https://www.pymnts.com/artificial-intelligence-2/2026/acquirers-may-win-agentic-commerce-by-building-the-guardrails/) published in March 2026 found that the limiting factor in agentic commerce is not computational capability but governance. Early investments are focused not on automation but on guardrails. Explainability tools, monitoring systems, and reversible transaction features are receiving more attention than fully autonomous execution.

[JPMorgan's agentic commerce analysis](https://www.jpmorgan.com/payments/newsroom/agentic-commerce-ai-future-shopping) raises the open questions the industry has not answered: "What is the definition of consumer consent in autonomous transactions?" and "What happens when an agent misinterprets a consumer prompt?"

ICME answers both directly.

The policy is consent. When a consumer's rules are compiled into formal logic and enforced by automated reasoning before every transaction, that is the most precise definition of consent possible in an autonomous system. Not a checkbox. Not a terms-of-service agreement. A mathematically enforceable set of constraints that the agent cannot override, argue with, or reinterpret. "Only buy office supplies under $100, no recurring charges" becomes formal logic that blocks any transaction outside those boundaries before the stablecoin moves.

And when an agent misinterprets a consumer prompt? The policy catches it. The agent tries to buy electronics for $500. The compiled policy says office supplies under $100. UNSAT. The misinterpretation never reaches settlement. The consumer's intent, expressed as compiled policy, stops the error before money moves. The ZK proof then provides a cryptographic receipt that this enforcement actually happened, verifiable by any party without trusting the agent or its operator.

***

#### Why automated reasoning, not another LLM

An LLM-based judge evaluating whether a transaction "seems legitimate" inherits the same weaknesses as the agents it monitors. Security researchers call this the "same model, different hat" problem. If an attacker can trick the main agent through a crafted prompt, the same technique can often trick the guardrail, because both are language models vulnerable to the same manipulation tactics. Prompt injection appears in over [73% of production AI deployments](https://www.obsidiansecurity.com/blog/prompt-injection), and even sophisticated guardrails have been bypassed with [100% evasion success](https://mindgard.ai/blog/outsmarting-ai-guardrails-with-invisible-characters-and-adversarial-prompts) in controlled experiments.

ICME PreFlight uses [automated reasoning](https://blog.icme.io/what-is-automated-reasoning/) to validate content against rules defined in plain English. The engine converts natural language policies into formal logic and checks proposed actions against a mathematical solver. When a check returns SAT, that is not "the model thinks it is fine." It is a mathematical proof that the proposed action is consistent with your rules. Research has found automated reasoning delivers up to [99% verification accuracy](https://arxiv.org/pdf/2511.09008) in detecting hallucinations and policy violations, with **100% accuracy** when policies are properly vetted.

The solver does not process emotional appeals, urgency arguments, or manipulated product descriptions. It checks whether the numbers match and whether the logical constraints hold. The agent loses the argument with the solver every time, because the solver does not have arguments.

***

#### Architecture

In a traditional clearing house, each participant has their own internal compliance policies. A hedge fund's risk limits are different from a retail broker's. The clearing house does not care about those internal policies. It only cares about the transaction: did both sides meet the settlement requirements?

ICME works the same way:

**Each participant compiles their own internal policies.** The buyer's agent might enforce spending limits, category restrictions, and preference compliance. The seller's agent might enforce pricing integrity, discount rules, and description standards. These are private. They are compiled into separate ICME policy\_ids and enforced independently by each agent before any transaction.

**The clearing house runs one policy.** It does not know or care what the buyer's spending limit is or what the seller's pricing rules say. It verifies that both sides submitted valid guardrail proofs and that the transaction-level facts are consistent.

**The ZK layer keeps everyone's rules private.** The buyer's ZK proof demonstrates that its internal guardrails passed without revealing what those guardrails are. The seller's ZK proof does the same. The clearing house verifies both proofs, confirms the transaction is consistent, and settlement proceeds. Neither side sees the other's proprietary policies.

***

#### Policy Example: Clearing house settlement

This is the single policy that governs the clearing house itself. It validates that both parties' guardrail proofs are present and valid, that the transaction amounts are consistent, and that the stablecoin payment terms match.

```bash
curl -s -N -X POST https://api.icme.io/v1/makeRules \
  -H 'Content-Type: application/json' \
  -H "X-API-Key: $ICME_API_KEY" \
  -d '{
    "policy": "Rule 1: The transaction may settle only if the buyer guardrail proof is verified and valid.\nRule 2: If the buyer guardrail proof is not verified or not valid, then settlement is not permitted.\nRule 3: The transaction may settle only if the seller guardrail proof is verified and valid.\nRule 4: If the seller guardrail proof is not verified or not valid, then settlement is not permitted.\nRule 5: The buyer stated transaction amount must match the seller stated transaction amount.\nRule 6: If the buyer stated transaction amount does not match the seller stated transaction amount, then settlement is not permitted.\nRule 7: The x402 payment amount must match the agreed transaction amount.\nRule 8: If the x402 payment amount does not match the agreed transaction amount, then settlement is not permitted.\nRule 9: The payment token must be an approved stablecoin.\nRule 10: If the payment token is not an approved stablecoin, then settlement is not permitted.\nRule 11: If any guardrail proof has expired, then settlement is not permitted.\nRule 12: If any required proof is missing, then settlement is not permitted."
  }'
```

**SAT: both proofs valid, amounts match, approved stablecoin**

```bash
curl -s -N -X POST https://api.icme.io/v1/checkIt \
  -H 'Content-Type: application/json' \
  -H "X-API-Key: $ICME_API_KEY" \
  -d "{
    \"policy_id\": \"$ICME_CLEARING_POLICY_ID\",
    \"action\": \"Settle transaction for 85 USDC. The buyer guardrail proof is verified and valid. The seller guardrail proof is verified and valid. The buyer stated transaction amount is 85 USDC. The seller stated transaction amount is 85 USDC. The x402 payment amount is 85 USDC. The x402 payment amount matches the agreed transaction amount. The payment token is USDC. The payment token is an approved stablecoin. No guardrail proof has expired. No required proof is missing. Therefore settlement is permitted.\"
  }"
```

```json
{ "ar_detail": "AR: allowed", "ar_result": "SAT", "result": "SAT" }
```

**UNSAT: buyer guardrail proof not verified**

```bash
curl -s -N -X POST https://api.icme.io/v1/checkIt \
  -H 'Content-Type: application/json' \
  -H "X-API-Key: $ICME_API_KEY" \
  -d "{
    \"policy_id\": \"$ICME_CLEARING_POLICY_ID\",
    \"action\": \"Settle transaction for 85 USDC. The buyer guardrail proof is not verified. The seller guardrail proof is verified and valid. The buyer stated transaction amount is 85 USDC. The seller stated transaction amount is 85 USDC. The x402 payment amount is 85 USDC. The x402 payment amount matches the agreed transaction amount. The payment token is USDC. The payment token is an approved stablecoin. No guardrail proof has expired. Therefore settlement is permitted.\"
  }"
```

```json
{ "ar_detail": "AR: action violates policy rules", "ar_result": "UNSAT", "result": "UNSAT" }
```

**UNSAT: transaction amounts do not match**

The buyer's agent agreed to 85 USDC. The seller's agent is claiming 100 USDC. This catches price manipulation between agreement and settlement.

```bash
curl -s -N -X POST https://api.icme.io/v1/checkIt \
  -H 'Content-Type: application/json' \
  -H "X-API-Key: $ICME_API_KEY" \
  -d "{
    \"policy_id\": \"$ICME_CLEARING_POLICY_ID\",
    \"action\": \"Settle transaction. The buyer guardrail proof is verified and valid. The seller guardrail proof is verified and valid. The buyer stated transaction amount is 85 USDC. The seller stated transaction amount is 100 USDC. The buyer stated transaction amount does not match the seller stated transaction amount. The x402 payment amount is 100 USDC. The payment token is USDC. The payment token is an approved stablecoin. No guardrail proof has expired. No required proof is missing. Therefore settlement is permitted.\"
  }"
```

```json
{ "ar_detail": "AR: action violates policy rules", "ar_result": "UNSAT", "result": "UNSAT" }
```

**UNSAT: x402 payment amount does not match agreed amount**

The agents agreed on 85 USDC, but the x402 payment header contains a different amount. This catches manipulation of the payment itself after both parties agreed on terms.

```bash
curl -s -N -X POST https://api.icme.io/v1/checkIt \
  -H 'Content-Type: application/json' \
  -H "X-API-Key: $ICME_API_KEY" \
  -d "{
    \"policy_id\": \"$ICME_CLEARING_POLICY_ID\",
    \"action\": \"Settle transaction for 85 USDC. The buyer guardrail proof is verified and valid. The seller guardrail proof is verified and valid. The buyer stated transaction amount is 85 USDC. The seller stated transaction amount is 85 USDC. The x402 payment amount is 120 USDC. The x402 payment amount does not match the agreed transaction amount. The payment token is USDC. The payment token is an approved stablecoin. No guardrail proof has expired. No required proof is missing. Therefore settlement is permitted.\"
  }"
```

```json
{ "ar_detail": "AR: action violates policy rules", "ar_result": "UNSAT", "result": "UNSAT" }
```

**UNSAT: unapproved payment token**

The transaction attempts to settle in a token that is not on the approved stablecoin list.

```bash
curl -s -N -X POST https://api.icme.io/v1/checkIt \
  -H 'Content-Type: application/json' \
  -H "X-API-Key: $ICME_API_KEY" \
  -d "{
    \"policy_id\": \"$ICME_CLEARING_POLICY_ID\",
    \"action\": \"Settle transaction for 85 tokens. The buyer guardrail proof is verified and valid. The seller guardrail proof is verified and valid. The buyer stated transaction amount is 85 tokens. The seller stated transaction amount is 85 tokens. The x402 payment amount is 85 tokens. The x402 payment amount matches the agreed transaction amount. The payment token is DOGE. The payment token is not an approved stablecoin. No guardrail proof has expired. No required proof is missing. Therefore settlement is permitted.\"
  }"
```

```json
{ "ar_detail": "AR: action violates policy rules", "ar_result": "UNSAT", "result": "UNSAT" }
```

**UNSAT: expired guardrail proof**

One of the guardrail proofs was generated too long ago. In high-frequency agent-to-agent commerce, a proof from even seconds ago may reflect stale state.

```bash
curl -s -N -X POST https://api.icme.io/v1/checkIt \
  -H 'Content-Type: application/json' \
  -H "X-API-Key: $ICME_API_KEY" \
  -d "{
    \"policy_id\": \"$ICME_CLEARING_POLICY_ID\",
    \"action\": \"Settle transaction for 85 USDC. The buyer guardrail proof is verified and valid. The seller guardrail proof is verified and valid. The buyer stated transaction amount is 85 USDC. The seller stated transaction amount is 85 USDC. The x402 payment amount is 85 USDC. The x402 payment amount matches the agreed transaction amount. The payment token is USDC. The payment token is an approved stablecoin. The seller guardrail proof has expired. Therefore settlement is permitted.\"
  }"
```

```json
{ "ar_detail": "AR: action violates policy rules", "ar_result": "UNSAT", "result": "UNSAT" }
```

***

#### How it works with x402 and stablecoins

The x402 protocol defines a simple flow: the agent requests a resource, the server responds with HTTP 402 including payment terms (amount, token, recipient address, network), the agent signs the stablecoin transaction, attaches proof in the `X-PAYMENT` header, and retries.

ICME slots into this flow at three points:

**Before the agent pays.** The buyer's agent runs its proposed action through its own internal ICME policy. "Purchase 85 USDC of office supplies. Category is authorized. Daily spend is within limit." If SAT, the agent proceeds. If UNSAT, it stops. A ZK proof is generated.

**Before the seller fulfills.** The seller's agent runs its proposed action through its own internal ICME policy. "Sell product at 85 USDC. Price matches catalog. No unauthorized discount applied." If SAT, the seller proceeds. If UNSAT, it stops. A ZK proof is generated.

**Before settlement.** Both ZK proofs are submitted to the clearing house. The clearing house runs Policy A: are both proofs valid? Do amounts match? Does the x402 payment amount match? Is the token approved? If SAT, the stablecoin moves. If UNSAT, it does not.

The stablecoin never moves until the clearing house confirms all proofs. This is the same principle that makes traditional clearing work: the asset does not transfer until both sides have met the requirements. The difference is that verification happens in under a second, at machine speed, with no human in the loop.

***

#### Try it out

**Compile the clearing house policy.** Call `makeRules` once for Policy A. Store the policy\_id as `ICME_CLEARING_POLICY_ID`.

**Each participant compiles their own internal policies separately.** These are private to each participant. The clearing house never sees them. It only sees the ZK proofs they produce. How participants build their internal stack (state tracking, content filters, spending limits) is their business. If their ZK proof is valid, the clearing house does not care how they got there.

**Settlement flow.** Before any x402 stablecoin transfer settles:

1. Buyer's agent runs `checkIt` against its own internal policy. Generates ZK proof.
2. Seller's agent runs `checkIt` against its own internal policy. Generates ZK proof.
3. Both proofs are submitted to the clearing house.
4. Clearing house runs `checkIt` against Policy A, confirming both proofs are valid and transaction facts are consistent.
5. If SAT, stablecoin settles via x402. If UNSAT, the transaction is held.

**Proof expiration.** Set a TTL appropriate to your transaction speed. For high-frequency agent-to-agent commerce, proofs should expire within seconds. A proof generated for a price quote that has since changed must not be accepted at settlement.

**Fail closed.** If the ICME API is unreachable or returns anything other than an explicit SAT at any layer, the stablecoin does not move. An unavailable guardrail is not implicit permission to settle.

***

#### What changes when the clearing house exists

Agents stop needing to trust each other. A buyer's agent can transact with a seller's agent it has never encountered before, across organizational boundaries, with no reputation history, no pre-existing relationship, and no human reviewing the transaction. The ZK proofs replace all of it.

Regulators get the audit trail they will inevitably require. Every settlement carries a cryptographic receipt proving which policies ran, on what data, with what result. Not a log entry that could be fabricated. A mathematical proof that can be verified independently by any third party in under a second.

The x402 Foundation launched with backing from Google, Microsoft, Visa, Mastercard, Stripe, and more than 20 other organizations. The pipes are being laid for trillions in agent-to-agent volume. The open question is not whether that volume is coming. It is who writes the default settlement policy that every agent in the ecosystem agrees to.

The DTCC did not become the most quietly profitable piece of financial infrastructure by building trading systems. It became essential by becoming the place where trades settle. The clearing house for agentic commerce will work the same way.


---

# 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/agentic-commerce-clearing-house.md?ask=<question>
```

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.