Agent autonomy
An agent needs to act quickly, but an unrestricted wallet turns a helpful assistant into a high-risk payment rail.
DOCUMENTATION / START HEREBounded agentic commerce
Payments for agents.
Boundaries for people.
Seedhape is the policy and orchestration layer above smart-account permissions and x402 settlement. It lets AI agents buy from approved merchants while keeping the user in control of scope, budget, and evidence.
In one sentenceThe user funds and authorizes a bounded wallet once; the agent spends only within those limits; merchants receive exact USDC payments; every decision is recorded.
01 / WHY IT EXISTSAI can decide what to buy.
AI can decide what to buy.
It should not decide everything about money.
Wallet primitives are not a product
Smart-account permissions and payment settlement are necessary primitives, but they do not express which merchant, product, or resource an agent may use.
Agent context is not policy
An agent can find a valid payment route and still choose the wrong host, product, price, or recipient without a commerce-aware control layer.
Autonomous commerce needs evidence
Users and operators need to see what was requested, why it was allowed or refused, and what actually settled.
02 / THE SOLUTION
A control layer between intent and settlement.
Seedhape separates the parts that are often bundled together: the agent asks, policy evaluates, a wallet signs, the facilitator settles, and the ledger explains what happened.
AGENT / MCPIntent
→SEEDHAPEMandate + policy + ledger
→MERCHANT APIx402 paywall
Human wallet / custody adapter signs within the approved boundaryFacilitator verifies → USDC settles directly to merchant
03 / WHO IT IS FOROne system,
One system,
four clear jobs.
Buyers
Set the limits, fund the wallet, review the exact recipient and amount, and revoke access whenever you choose.
Explore →AI agents
Discover paid resources, request quotes, and call structured MCP tools. The agent gets bounded authority—not a seed phrase.
Explore →Merchants
Add an x402 paywall to an existing API, receive USDC directly, and keep a receipt and settlement trail.
Explore →Operators
Run the control plane, inspect activity and health, configure the network, and connect an approved custody adapter.
Explore →04 / HOW A PAYMENT WORKSPreparation is not authorization.
Preparation is not authorization.
Authorization is not settlement.
That separation is the safety model. The agent can explore and prepare; a payment is signed only after the mandate and policy checks pass.
Discover
The agent finds a product or resource through the merchant catalog.
Quote
Seedhape requests the price and checks the asset, network, recipient, and resource.
Authorize
A mandate and policy decide whether the request is inside the buyer’s boundaries.
Authorize
The selected wallet provider authorizes a bounded payment capability; Seedhape never receives the root key.
Settle
The facilitator verifies and settles USDC directly to the merchant wallet.
Record
The outcome, FX snapshot, and ledger event are available for history and reporting.
05 / USE ITStart with the path
Start with the path
that fits your trust level.
Manual browser checkout
Open /checkout, connect an EVM wallet on Base Sepolia, review the merchant, amount, asset, and recipient, then sign one x402 payment.
Connect an agent
Open /authorize to define a merchant, host, product, budget, transaction count, and expiry. Then connect Claude or another MCP client to POST /mcp.
Use your permission layer
MetaMask ERC-7710 is the first demo provider. Seedhape keeps the commerce policy and orchestration boundary portable to other permission providers.
Set boundaries ↗Protect an API
Wrap Express, Hono, or node:http with the merchant SDK. Return an x402 challenge for paid routes and keep health and docs open.
Open merchant guide ↗06 / SAFETY + RECORDSThe controls are practical.
The controls are practical.
The limits are honest.
What is checked
- Mandate exists, is active, and was not revoked.
- Merchant host, exact resource, payee, asset, and network match.
- Per-payment, period, count, expiry, and burst limits hold.
- Price and unusual-spend signals can require confirmation.
- Policy runs before any payment credential is created.
What is recorded
- Intent, quote, refusal reason, payment outcome, and receipt.
- Provider, permission context, merchant, product, and settlement reference.
- Mandates and the full spend ledger can be exported for audit.
- Failed or refused requests remain visible instead of disappearing.
07 / REFERENCEConnect the pieces
Connect the pieces
without guessing.
MCP tools
commerce_catalogDiscover products and their payment requirements.commerce_prepare_purchaseCreate a short-lived checkout link. No funds move.wallet_statusView wallet, network, permission, and allowance status.mandate_propose / list / revokeCreate, inspect, or immediately revoke bounded authority.quote / payInspect a 402 price, then pay with an exact mandate hash.spend_history / audit_exportReview settled and refused activity and export an audit trail.Hosted endpoints
POST /mcpStreamable HTTP MCP transport for Claude and compatible clients.GET /api/healthBasic deployment health check.GET /api/statusNetwork, merchant, FX, mandate, and spend summary.GET /api/merchant/catalogDiscoverable merchant products.GET /api/spendsRecent payment records for the configured runtime.GET /api/commerce/activityMerchant-side commerce and settlement events.