X402 Commerce
Verify seller attributes as ZK proofs before x402 settlement runs. Buyer agents transact without relying on plaintext claims.
Who this is for.
Are you building on x402 rails, where buyer agents and seller agents transact in milliseconds? Are seller claims — inventory, price, SLA, identity — still being trusted on plaintext API responses and reputation scores?
-
Operators of agent-commerce platforms and marketplaces built on the x402 protocol
-
Product leads designing buyer and seller agents in MCP-compatible agent ecosystems
-
Digital commerce backbones that need pre-settlement verification on top of Coinbase x402 or the Stripe Agent SDK
Hand over the source, or just the facts?
Change what reaches the AI, and the leakage risk goes with it.
- buyer:
- AI-001 (API key sk-…)
- seller:
- vendor-acme
- product:
- data feed (premium)
- amount:
- 100 USDC
- transaction_id:
- TX-2024-08-15-…
- all_history:
- visible
- subject:
- did:lemma:tx-TX2024-08-15
- issuer:
- did:lemma:trust402.proxy
- sourceHash:
- 0xa1f3…7d8e
- agent:
- did:lemma:agent-buyer-001
- scope:
- x402://vendor-acme/*
- ZK verified:
- ✓ VALID
Lemma wraps the attributes a seller agent presents — identity, authority, inventory, price, SLA, issuer signature — in ZK proofs. The buyer agent verifies them cryptographically before committing, with no need to trust plaintext claims. Transactions without verifiable proofs stop at the boundary before settlement runs.
x402 carries the settlement rail; Lemma carries the pre-settlement trust rail. The two run in parallel: each agent transaction completes in three stages — pre-settlement verification → x402 settlement → post-settlement cryptographic evidence. Even if an ephemeral seller agent lies, the buyer-side verification rejects it structurally — no reliance on reputation systems.
Where the pre-settlement verification layer fits into your x402 / agent-commerce stack is what we map out in a first conversation.
Choose on three criteria.
Only work that needs all three at once — pass without exposing, independent verification, tamper-proof — is Lemma's domain.
| Method | Pass without exposing | Independent verification | Tamper-proof |
|---|---|---|---|
| Access control only | △ | ✗ | ✗ |
| Masking / anonymization | △ | ✗ | ✗ |
| Encryption only | ✓ | ✗ | ✗ |
| Lemma (ZK proof)the only one with all 3 | ✓ | ✓ | ✓ |
How it works
Tell us how your x402 / agent-commerce stack is wired today, the transaction patterns you anticipate, and the fraud risk you're concerned about. We'll explore together whether Lemma's pre-settlement verification layer could fit. No protocol internals or marketplace data required.
Related Use Cases
The bigger picture
The bigger picture this use case belongs to.
We map use scenarios across industries and workflows by the four axes.
See use scenarios for Verifiable Origin in Solutions →TRY LEMMA
Run it yourself.
No sales call needed — start hands-on with Lemma's products.