# The Z-ZERO Whitebook > You are reading the **agent rendering** of https://z-zero.xyz/whitebook. > Human rendering: same URL from a browser (or /whitebook?human=1). > Quick agent guide (install, API, SOP): https://z-zero.xyz/agent.md > This document is deep background for evaluating Z-ZERO — it is NOT required to transact. **The payment bridge between AI agents and the real economy.** Why the agent economy needs a bridge instead of another rail, how the dual-gateway architecture works, the security model behind it — and what you can verify yourself today. Proof chips: ✓ Live on Base mainnet (tx 0xdfd1f2f824e1232c3e03c52485332570ff01fbb0340c5571f699ed1218735d7a) · ✓ On npm (z-zero-mcp-server) · ✓ Works in any MCP client · try: `curl -L z-zero.xyz` Last updated 30 Jul 2026 · Third-party figures below carry their source and date. Contents: 01 Vision & thesis · 02 Why now · 03 Architecture · 04 Security model · 05 AI-first web · 06 Roadmap --- ## 01 · Vision & thesis ``` [ HUMAN WEB ] ⇄ [ Z-ZERO — the payment bridge ] ⇄ [ AGENT WEB ] fiat merchants USDC on Base · MCP card checkouts ``` AI agents can already research products, compare prices, and decide what to buy. What they cannot do is **pay** — because for the vast majority of real-world merchants, the only door that exists is a card checkout built for human hands. Those merchants are not going to integrate a crypto rail, an agent protocol, or a new API one by one. Most will never integrate anything at all. The industry's answer so far has been to build **new rails** — agent-native payment protocols that work beautifully wherever the merchant has adopted them, and nowhere else. Rails are necessary, and the giants are building them well. UCP, co-developed by Shopify and Google, gives agents a structured way to discover merchant capabilities and run checkout — once the merchant exposes a UCP endpoint. But rails only reach the merchants that opt in. Z-ZERO takes the complementary position: **a bridge, not another rail.** Agents hold stablecoin (USDC on Base, gasless). When they need to buy from the fiat web, Z-ZERO issues a single-use, amount-locked virtual card at the moment of purchase and automates the checkout the merchant already has. The merchant doesn't need to build anything new — it receives a standard, fully funded card payment through its existing checkout. This is not a fringe workaround: Visa's Trusted Agent Protocol explicitly anticipates a card being securely entered into an existing checkout by an automated browser. Z-ZERO addresses that recognized execution path before every merchant has adopted an agent-native API. The category has a name, too: Z-ZERO is an **agent payment bridge** — revenue is a per-transaction take-rate on the volume that crosses it. No merchant fee, because the merchant integrates nothing. Four design principles govern everything in this document: | Principle | Meaning | |---|---| | Zero merchant integration | Work with the checkout that exists today, not the API a merchant might adopt in three years. | | Human authorization built in | Every payment path starts from a human-approved boundary: budgets, limits, revocable keys, explicit approvals. | | The agent never holds credentials | No card number, no CVV, no private key ever enters the AI model's context or environment — the same isolation direction reflected in Visa's agentic payment containers and UCP's opaque payment credentials. | | Settlement-agnostic by design | USDC on Base is the active configuration, not the identity. Additional stablecoins or EVM chains are configuration, not rewrites. | > The rails are live. The bridge is Z-ZERO. ## 02 · Why now Infrastructure is running ahead of demand. That gap is the window — and every fact below carries a date. | Date | Fact | |---|---| | 11 Sep 2025 | PCI Security Standards Council publishes AI-payments guidance recommending payment tokens or single-use PANs, plus merchant, spend and time limits — the same principles Z-ZERO is built on. | | 2026 | AWS ships x402 payment enforcement at the edge — a "Monetize" action in CloudFront and WAF, settling USDC on Base. (The Defiant) | | 30 Jun 2026 | 140+ major companies announce a shared stablecoin (OUSD, launching late 2026). The multi-stablecoin future is now consensus — which favors neutral bridge layers. (Fortune) | | 02 Jul 2026 | Visa: AI agents complete real purchases at independent EU merchants, with 31 issuing banks live. | | Early Jul 2026 | Cloudflare opens the waitlist for its x402 Monetization Gateway. (Cloudflare blog) | | Year one of x402 | 169M payments, 590k buyers, 100k sellers — machine-to-machine API micropayments, as reported by Coinbase. Proof the rail lane works where integration exists; commerce at unintegrated merchants remains the gap. | Market context: - **$300B → $1.45T** — stablecoins in circulation today → projected 2035 (Morningstar); $33T transacted in 2025, +72% YoY - **$8B → $1.5T** — agentic commerce 2026 → projected 2030 (Juniper); US agentic shoppers $190–385B by 2030 (Morgan Stanley) - **+138% / +54%** — AI-referred retail traffic YoY / conversion lift vs non-AI traffic (Adobe, May 2026) — early, from a small base Read those two panels honestly and a specific picture emerges. The top one is **incumbents building supply**: card networks, cloud providers and standards bodies wiring agent payments into production infrastructure, on real dates. The bottom one says demand is **forming, not proven** — traffic and conversion signals are sharply up, but from a small base. We state that plainly rather than claiming an explosion that hasn't happened. That asymmetry — capability ahead of adoption — is the window. The moment agent buying becomes routine, the layer that already connects agents to the vast majority of merchants who never integrated anything becomes very hard to displace. The time to build and prove that layer is before the wave, not after it. > Capability is here. Adoption isn't. That gap is the window. ## 03 · Architecture A dual-gateway system: humans govern through one door, agents execute through another — and credentials never cross the line. Z-ZERO separates **governance** from **execution**. The human owner uses a dashboard: deposit USDC, set budgets and limits, create and revoke agent keys, approve what needs approving. The agent uses an open MCP server (published on npm, works with any MCP-capable model). Sensitive material — private keys, card numbers — lives on neither side of the conversation with the model. It stays inside the platform boundary, touched only at the moment of use. ``` GOVERNANCE GATEWAY EXECUTION GATEWAY HUMAN → DASHBOARD AGENT → MCP SERVER (budgets · limits · keys · (Passport Key zk_live_… · approvals) request token · execute checkout) \ / ▼ ▼ [ Z-ZERO PLATFORM — keys & cards live ONLY here ] wallet ops · card issuing · token ledger · kill switch │ ▼ headless browser → merchant's existing checkout ``` ### 03.1 Smart routing: one tool, two payment paths The agent calls one tool with a checkout URL. Z-ZERO detects what the merchant accepts and routes accordingly: | Path | When | How | |---|---|---| | Fiat — JIT card | Merchant accepts cards only (the default for the vast majority of the web) | Issue a single-use virtual card locked to the exact order amount, auto-fill the existing checkout form, burn the card | | Crypto — USDC on Base | Merchant accepts on-chain USDC | Pay from the agent's smart account — gasless, gas sponsored via an ERC-7677 paymaster | | x402 (planned) | Merchant supports HTTP 402 | One HTTP request — no browser automation needed | ### 03.2 The just-in-time card flow Read this flow against the industry direction: Visa TAP describes the same browser key-entry case and lets a merchant verify that the credential being entered is the one bound to an approved agentic payment container. Z-ZERO already isolates and constrains the credential as shown below; TAP's signed merchant-verifiable container and Visa onboarding would still require future integration work; no certification is claimed here. 1. **Read the total** — the agent reads the final price on the merchant's checkout page — say $49.99. 2. **Issue & fund** — the platform verifies the agent's on-chain USDC balance, debits it (gasless), and has a licensed issuing partner create a virtual card whose limit is exactly $49.99, single-use, self-expiring. In the same moment the purpose criteria are recorded and locked against later edits — see 04.6. 3. **Token, not card** — the agent receives an opaque one-time token — a random 128-bit string with a 1-hour lifetime. It contains no card data and cannot be converted into any. 4. **Automated checkout** — the platform presents the locked criteria back to the agent, which must answer before it can pay: what it is actually looking at, and go or pause. On pause nothing is charged. On go the token is resolved server-side and a headless browser types the card into the merchant's form; the answer is sealed into the receipt with the outcome. Card data exists only in volatile memory for the seconds the checkout takes, then is discarded — success or fail. 5. **Settle & close** — confirmed → the token is burned. Declined → cancel the token; the hold is refunded on-chain. Either way the card dies at the issuer after one transaction. Card lifetime: seconds in memory — single-use · amount-locked · self-expiring. ### 03.3 Wallets & keys: no keys to steal Agent wallets are ERC-4337 smart accounts on Base, derived deterministically from a single protected master seed plus a per-agent index. **The database stores only public addresses and indices — zero key material.** A database breach yields no card numbers and no private keys — nothing that can move funds on its own. Signing happens in memory at transaction time. Today these wallets are platform-managed, bounded by human budgets, rate limits and the kill switch; scoped user-controlled permissions (ERC-7715) are on the roadmap. **Because keys never exist in the agent's environment, even a fully prompt-injected agent cannot extract keys or card data — spending stays inside the human-set budget and rate limits, one amount-capped transaction at a time, and the Passport Key is revocable at any moment.** ## 04 · Security model The agent never holds the card. It holds a one-time ticket — and even the card behind the ticket is built to die. The industry has converged on the principle here — the PCI Security Standards Council's September 2025 guidance recommends payment tokens and single-use PANs for AI-driven payments; Visa's agentic architecture carries payment credentials in signed containers; and UCP tells platforms to use opaque, tokenized credentials rather than raw card data. Z-ZERO implements that shared security direction for the unintegrated web. We claim no secret knowledge, protocol conformance or certification; what follows is simply the implementation, described precisely enough to be evaluated. ### 04.1 Four layers that fail safely | If this leaks | Properties | Outcome | |---|---|---| | KEY PASTED IN CHAT | auto-rotated on connect · dead in seconds · one key = one machine | transcripts hold only corpses | | TOKEN | expires in 1h · single-use · owner-bound | no card can be extracted | | CARD | single-use · exact amount only · self-expires | damage is boxed in | | DATABASE | no card numbers stored · no private keys stored | nothing that moves funds on its own | ### 04.2 Tokens, not encryption The token an agent holds is not an encrypted card — it is a random string with **no mathematical relationship** to any card number, worthless unless a live server answers yes to owner, validity and single-use, and revocable with one call. The same principle — tokenization in place of stored credentials — underpins wallets like Apple Pay; Z-ZERO applies it to agents. | | Encrypted card data | Z-ZERO token | |---|---|---| | What a thief obtains | The real card, locked | A meaningless random string | | What unlocking requires | The key — steal it, break it, or find a bug | A live server that says yes to owner + validity + single-use checks | | Revocable after a leak? | No — exposed ciphertext is exposed forever | Yes — burn the token, it becomes paper | | Prize if fully defeated | A real card, spendable anywhere | A single-use card locked to one amount, already expiring | ### 04.3 The credential ladder Three credentials, each living shorter and carrying less power than the one above it — and exchanging one for the next always requires both the credential AND proof of the identity it was issued to: ``` PASSPORT KEY zk_live_… created once by the human · revocable any time │ used to REQUEST a ticket ▼ PAYMENT TOKEN random 128-bit · 1 hour · single-use · exact amount │ ticket + identity together REDEEM the card ▼ VIRTUAL CARD seconds in memory · single-use · amount-locked ``` ### 04.4 Two independent self-destruct clocks The 1-hour token lifetime is enforced by the Z-ZERO platform. The card's own death — void after one transaction, expired within a day — is enforced **at the issuer layer, outside our infrastructure**. Even if an issued card leaked in full, its death still arrives on that second clock — one no one at Z-ZERO, and no one inside a breach, can stop. **RAM-only execution, stated precisely:** real card credentials exist only in volatile memory for the few seconds needed to complete a checkout — by design never written to disk, database, or logs — and are discarded immediately after the transaction, success or fail. ### 04.5 Defense in depth, enumerated - **Amount locking** — a $15 card is declined for a $16 charge at the issuer level; overspend is blocked outside our own code. - **Single-use everything** — tokens burn after redemption; cards void after one authorization. - **Idempotency** — network retries cannot double-charge; same request, same single result. - **No card data at rest** — there is no PAN database to breach, by construction. - **Zero key material in the DB** — wallet keys are derived at signing time, never stored. - **Row-level security** — every table is scoped so users can only ever touch their own data. - **SSRF & transport guards** — non-HTTPS and private-network targets are rejected outright. - **Rate limits + kill switch** — on-chain transfers are throttled per user; one switch freezes all card activity platform-wide. ### 04.6 The second chain: proof of purpose Conventional payment evidence is strong at two things: proving a payment was authorized, and proving where the value went. Agentic commerce needs a third thing linked to those two — **a record of the delegated purpose, of what the agent said it was looking at, and of how the purchase actually turned out.** Google's AP2 identifies the same missing evidence and formalizes it as cryptographically signed Intent and Payment Mandates: what the owner allowed, and which final cart was authorized. Z-ZERO's purpose chain below solves the analogous problem on an ordinary card checkout that never implemented AP2. It is an internal signed audit record today — conceptually aligned, not AP2 conformance. For a human buyer that gap is tolerable: the reason lived in a head that can be asked afterwards. For an agent, the "why" is precisely the part that was delegated to software — which makes it the part that can go wrong. And mechanically, a correct purchase and a wrong one are identical: same card, same amount, same merchant, same settlement. So alongside the money chain — a signed intent during issuance, before any checkout runs; a signed receipt once the merchant confirms; later attestations recording settlement or reversal — the platform keeps a second chain for purpose: | Moment | What is recorded | |---|---| | At issuance | The criteria the agent records as the owner's instruction — a few lines, signed and locked *before* anyone knows the outcome. | | The second before the card is filled | The platform hands those same criteria back, and the agent must answer before it can pay: what it is actually looking at, and `go` or `pause`. On `pause` nothing is charged. | | After the purchase | That answer is sealed into the signed receipt together with the outcome. | Three design decisions, each avoiding a specific failure: - **The criteria track the owner's words, not a fixed checklist.** "A hat, under $10" is exactly two lines. A five-line template would score the three lines the owner never mentioned as "no match", and block a good purchase. - **Lock the question before the answer.** The agent writes the exam before sitting it. Asked for both at once, an agent will phrase the question to fit the answer it already has. - **The platform re-presents the criteria; the agent never retypes them.** An agent quoting from memory softens the question — "the owner wanted something nice" — until everything matches. **What this does not prove:** - **It does not stop an agent from lying.** A fully compromised agent can declare a match and proceed. This is not a wall — it turns an unattributable loss into an attributable one. - **The platform does not adjudicate the declaration.** It never sees the page. It is a notary, not a judge: it certifies the answer it received, not the truth of what was on screen. The MCP requires that answer before checkout runs; the platform seals it into the receipt after the merchant confirms. - **It does not score shopping quality.** Deliberately. This is payment infrastructure, not a shopping assistant. - **It is not a KYC or AML control.** It is a record of purpose. It replaces no compliance obligation. The distinction that matters: the money chain says a payment of this size reached this merchant. The purpose chain says **what the card was issued for, and what the agent said it was looking at when it spent** — a record rather than a gate. Agent-native rails are building comparable mandate records inside their own protocols. What is unusual here is where it runs: on an ordinary card checkout the merchant never integrated, with the card number never entering the model's context — so the record is produced under the same isolation that keeps the credential out of the agent's reach. Implemented in the platform and in the published MCP server. Described here as architecture: no claim is made about volume, and none about losses it has prevented. ### 04.7 Where the moat actually is None of the four properties below is unique on its own — stablecoin wallets exist, virtual cards exist, agent toolkits exist, browser automation exists. The product is the **combination**, shipped and live: 1. A new single-use card, created at purchase time and funded from stablecoin — not a pass-through to a card the user already has 2. Open MCP — works with any MCP-capable model, no walled garden 3. Checkout automation at merchants as they are today — nothing for the merchant to build or install 4. Card data never enters the model's context — the agent sees a token, nothing more **One of these properties compounds.** Every attempt can produce structured evidence about field formats, address quirks, flow changes and final outcomes. Evidence is promoted into shared merchant knowledge only after a later outcome or human review verifies it. The combination gets this launched; the verified execution history and the two-sided outcome data it feeds accrue only with time on the bridge. The architecture direction for that loop is: ``` SIGNED INTENT ↓ AGENT VERIFIES FINAL CHECKOUT BEFORE A CREDENTIAL IS ISSUED ↓ BOUNDED EXECUTION ↓ FAILED ATTEMPT / VERIFIED OUTCOME ↓ RAW FACT → HYPOTHESIS → VERIFIED KNOWLEDGE ↓ MERCHANT HINTS → BETTER NEXT EXECUTION ``` Facts do not become hints automatically. They cross a verification gate through a later transaction outcome, a targeted re-probe, or human review. The primitives are copyable; a verified history of real merchant outcomes must be earned. *Architecture direction, not a claim that the full loop is live today. The signed-intent, signed-receipt and structured-event backend is implemented; the verification/promotion loop and the accumulated outcome corpus are not yet claimed as a live moat.* ## 05 · AI-first web One address, two renderings: humans see pixels, agents see protocol. You can verify this in one command: ``` $ curl -L z-zero.xyz # → returns AGENT.md: site map, MCP install, API, error codes, SOP ``` Most "AI-ready" websites bolt documentation onto a human page and hope agents can parse it. Z-ZERO inverts that: **the agent never needs the human page.** We run the first AI-first surface on our own front door — dogfooding the demand side of the bridge. ``` GET https://z-zero.xyz │ the server reads User-Agent + Accept ┌────┴──────────────────────────────┐ ▼ ▼ BROWSER (Mozilla/5.0…) AGENT (curl / Claude / GPTBot) HTML — the marketing site AGENT.md — site map · MCP install · API · SOP search crawlers → always HTML · same content, two renderings — negotiation, not cloaking ``` Because no user-agent list catches every agent, discovery is layered four deep — an agent that slips past one layer hits the next: - **L1 — Content negotiation at the edge:** Accept: text/markdown or a known AI/CLI user-agent → the same URL serves AGENT.md instead of HTML. - **L2 — Published standards:** /llms.txt and /llms-full.txt (llmstxt.org) · /.well-known/agent.json — an A2A Agent Card declaring five payment skills for agent-to-agent discovery. The server itself is published in the official MCP Registry as `io.github.Dempty-glitch/z-zero-mcp` — the index MCP clients resolve against (https://registry.modelcontextprotocol.io/v0/servers?search=z-zero). - **L3 — Signposts inside the human page:** an agent-notice comment at the top of the markup and schema.org JSON-LD — the first thing a stray agent parses points it back to the protocol surface. - **L4 — A header on every response:** X-Agent-Guide: /llms.txt rides on every URL of the site — any touchpoint leads to the payment SOP in one hop. Live on production since 12 Jul 2026, verified across twelve scenarios. The nicest proof was unplanned: the first time an AI-integrated browser opened a preview of the site, it was served the agent rendering automatically — the system recognized an agent before we ever demoed it. ## 06 · Roadmap What is live, what is next, and where this goes — stated without dates we can't defend. **● LIVE TODAY** - Gasless USDC on Base mainnet — real transaction verifiable on-chain - Just-in-time single-use cards with automated checkout at unmodified merchants - Open MCP server on npm — smart routing, balances, human approvals, spending limits - A merchant checkout knowledge base that learns from failed form fills — field formats, address quirks, flow changes — so the next agent's legitimate purchase completes reliably - The AI-first web surface described in section 05 **▸ NEXT** - **Out-of-band transaction approval** — the owner approves a payment on a channel independent of the machine running the agent, before any card exists. It completes a three-source chain of authority: the human approves, the agent declares (04.6), and the issuer enforces the per-card cap and single use at authorization. - x402 as a third payment path — one HTTP request where merchants support it - Additional stablecoins and EVM chains — by design a configuration entry, not a rewrite - More merchants that just work. Sharper human controls. **▹ THE LONGER ARC** - **Know-Your-Agent (KYA):** every bridge crossing produces settled, two-sided transaction data. The question in agent commerce shifts from "can this agent pay?" to "should this agent be trusted to pay?" — and the layer that answers it accrues only with time on the bridge. - **User-controlled smart accounts:** scoped, revocable spend permissions held by the user, not the platform — the ERC-7715 direction. Roadmap items describe engineering direction, not promises with dates. Anything here may ship earlier, later, or differently as the market moves. --- ## Verify, don't trust - On-chain proof: https://basescan.org/tx/0xdfd1f2f824e1232c3e03c52485332570ff01fbb0340c5571f699ed1218735d7a - Run the MCP server yourself: https://www.npmjs.com/package/z-zero-mcp-server - API reference: https://z-zero.xyz/docs/api - Get started: https://z-zero.xyz/ · Agent guide: https://z-zero.xyz/agent.md Building rails we should bridge to, issuing infrastructure, or capital for this layer — hung@z-zero.xyz Third-party figures are cited with source and date; market projections are single-analyst estimates. This document describes a system; it is not an offer of securities and makes no compliance certifications. © 2026 Z-ZERO · The payment bridge for the agent economy