Overview
The problem, and what sip402 is
x402 already describes batch-settlement — streaming, session-based payments where you pay as a resource is delivered and settle in batches. But the only binding anyone shipped, cloudflare:402, is centralised: a credit balance the network holds, settled off-chain, with the network as merchant-of-record. You stream now and trust an intermediary to settle later. The trust-minimised, on-chain version was in the spec but never built.
sip402 builds it. One MetaMask ERC-7715 Advanced Permission becomes a standing, revocable session; an agent sips small USDC draws against it as a paid AI stream is delivered — batched on-chain, capped by ERC-7710 caveats, gasless via 1Shot, and cancellable mid-sentence. Money, caps, and revocation are on-chain; no intermediary ever holds the buyer's funds. x402 prices the request; sip402 prices the delivery.
Grant
One ERC-7715 permission: a periodic USDC cap.
Spend
The agent batch-redeems commitments against it.
Enforce
The chain reverts the over-cap draw and the revoke.
Mechanics
How it works
A buyer grants one periodic delegation (the session). Each request, the buyer's agent signs a redelegation to the seller (the commitment). The seller verifies it by simulating the redemption, serves immediately, accumulates the voucher, and redeems a batch of vouchers in one transaction. The period caveat enforces the cap on-chain; revoking the root delegation makes the next draw revert.
Buyer (treasury smart account) │ openSession: ERC-7710 Erc20PeriodTransfer delegation, cap $X / period ▼ Agent (session key) ← redelegateSession (A2A): orchestrator → specialists │ createCommitment: a redelegation agent→seller for this request's amount ▼ Seller (@sip402/server) │ verify by simulation · accumulate vouchers ▼ Delegation Manager ── redeemDelegations (BATCH) ──▶ USDC: treasury → seller ERC20PeriodTransferEnforcer caps the total; over-cap reverts (dry-tab) testnet: seller submits directly · mainnet: 1Shot relayer (gas in USDC)
Install
The packages
Chain config, SipMeter accounting, the Settler (DirectRedeem on testnet / OneShot on mainnet via 1Shot), 1Shot client.
Buyer: openSession, redelegateSession (A2A), createCommitment (redelegation-as-payment), revokeSession.
Seller: verifyCommitment by simulation, CommitmentAccumulator (accept + batch-redeem), x402 HTTP middleware, SSE.
Reference seller reselling Venice behind an OpenAI-compatible gateway; StreamingDrawer for live per-batch draws.
Build
Quickstart
Install the client and open a session against a USDC treasury.
pnpm add @sip402/client
# in your agent
import { openSession, createCommitment } from "@sip402/client";
# 1. one periodic grant (the tab)
const session = await openSession({ tokenAddress: USDC, periodAmount, periodDuration });
# 2. per request, sign a redelegation to the seller (the sip)
const commitment = await createCommitment({ session, payTo, amount });Try it
Run the demo locally
The interactive Grant → Spend → Enforce demo ships with its own backend — it signs and submits real transactions, so it needs a funded key and an RPC, and runs on your machine rather than a static host. It lives in apps/demo.
# 1. clone + install (pnpm workspace) git clone https://github.com/RomarioKavin1/sip402 cd sip402 && pnpm install # 2. configure the demo backend cp apps/demo/.env.example apps/demo/.env # PRIVATE_KEY=0x... throwaway key, funded on Base Sepolia # SIP_NETWORK=base-sepolia # BASE_SEPOLIA_RPC_URL=https://sepolia.base.org # 3. run (frontend + backend, port 3402) pnpm --filter @sip402/demo dev # open http://localhost:3402
Connect MetaMask (Base Sepolia, with Advanced Permissions), approve one ERC-7715 grant, and the agent sips against it while the chain enforces the cap. Full prerequisites and troubleshooting are in apps/demo/README.md ↗.
Spec
Binding requirements
The binding implements x402 batch-settlement across two networks (eip155:8453 Base mainnet, eip155:84532 Base Sepolia). Seven network requirements, summarized from the spec:
Compare
Differentiation
vs upto
upto settles at most once, after full delivery, trusting the server's metering. sip402 settles many times against one standing authorization; the cap is enforced on-chain, not asserted by the server; and the buyer can revoke mid-stream.
vs @metamask/x402
The official package does per-request delegated payment via a hosted MetaMask facilitator. sip402 adds the session + batched-settlement layer and settles through 1Shot (self-hostable, no ETH float), making the commitment a redelegation — so A2A redelegation is the payment primitive itself.
vs batch-settlement / cloudflare:402
Cloudflare's binding is credit-backed, fiat, off-chain, network-as-merchant-of-record. sip402 is the capital-backed, on-chain, self-custodial binding of the same scheme.
Questions
FAQ
Isn't it supposed to be fully on-chain?
Money, caps, and revocation are on-chain. HTTP and AI inference are off-chain by necessity. sip402 binds the payment to the delivery without asking you to trust the server with custody or with the meter.
What stops the agent from overspending?
The ERC20PeriodTransferEnforcer. Any draw (or batch of draws) past the periodAmount reverts atomically on-chain — the buyer's signature isn't required to stop it.
Why a separate seller / splitter package?
The seller verifies commitments, accumulates vouchers, and batch-redeems. @sip402/splitter is the reference seller reselling Venice; it's what the live demo's inference path runs through.
Does it need a bundler?
No. Testnet redeems directly via the Delegation Manager. Mainnet settles through the 1Shot relayer with gas paid in USDC — no ETH float, self-hostable.
Evidence
Proven on-chain
Every row is a real transaction. The counts differ on purpose: Base Sepolia is free, so every requirement is proven there; mainnet runs spend real USDC and gas, so the two production rails (gasless 1Shot redemption and paid Venice inference) are each proven once on Base mainnet.