AI agents can already search catalogs, compare options, and recommend a product.
That is useful, but it is not commerce.
Commerce begins when the recommendation becomes a commitment:
- Who approved the purchase?
- Where does the money go?
- What state is the order in?
- Which product variant and inventory snapshot did the buyer accept?
- What evidence survives if fulfillment fails?
- How does a return reach the right address?
Most agent demos stop before these questions. WebAZ is an open-source protocol trying to make the messy part after "buy" explicit, inspectable, and usable by both humans and AI agents.
What is live now
WebAZ now runs two real settlement rails. On neither rail does WebAZ take custody of the principal.
1. Direct Pay
The buyer pays the seller directly, off-platform. WebAZ records the payment-instruction snapshot, risk acknowledgement, order state, and evidence, but it does not verify the payment method, guarantee the payment, or issue the seller's refund.
This path is intentionally simple for sellers who already have a preferred way to receive money.
2. USDC on-chain escrow
Real USDC can be locked in an immutable contract on Base mainnet. WebAZ does not hold a key that can redirect those funds to an arbitrary address. The contract constrains exits to the original buyer, the voucher-bound seller, or the fee sink, and enforces a per-order amount cap on-chain.
An important boundary: the contract has not had a third-party security audit. The current compensating controls are a deliberately small immutable surface, hard transaction caps, a deposits-only pause, and enumerated fund exits. This is a live rail, not a claim of zero risk.
The less glamorous work that makes a store usable
Payment is only one part of a purchase. Recent WebAZ releases also added operational pieces that independent sellers need:
- Multi-dimension product variants with batch price and stock entry
- Enable, disable, edit, and delete controls for variants
- Inventory-aware buyer selection with out-of-stock options disabled
- Price ranges before selection and the exact price after selection
- Product-scoped shipping settings
- A structured seller return address, snapshotted when an order is accepted so later store edits cannot rewrite an existing order's return destination
These are not flashy agent demos. They are the state transitions that determine whether a real order can be understood later.
One protocol surface for people and agents
Humans can use the WebAZ PWA. Agents can connect through the live Remote MCP endpoint.
Public product discovery is available anonymously. Authenticated writes can use OAuth 2.1 authorization code flow with PKCE, while selected higher-risk actions retain a Passkey approval boundary. A fixed shopping MCP surface also gives clients a narrow product-discovery interface instead of exposing every available tool.
The goal is not to remove the human from commerce. It is to make the handoff between human intent and agent execution visible.
Safety work continues behind the interface
The newest merged work includes a dormant, read-only dual-RPC shadow observer for a future escrow path. It cannot write to the chain, has no signer, changes no money or order semantics, and is not connected to production routing.
That distinction matters. Infrastructure can be tested against live conditions without quietly becoming a live payment path.
The thesis
Agent-native commerce will need more than a shopping chatbot and a payment button. It needs shared state, explicit authority, bounded money movement, fulfillment evidence, and recovery paths that another human or agent can inspect.
WebAZ is building that protocol in the open, one complete state transition at a time.
- Browse without an account: https://webaz.xyz/#discover
- Connect an agent: https://webaz.xyz/mcp
- Inspect the code: https://github.com/webaz-protocol/webaz
Which part of the post-purchase loop is hardest in your own agent or commerce workflow: approval, settlement, fulfillment evidence, or returns?
Top comments (0)