Pay-then-prove vs sign-then-settle
The entire architectural divide comes down to one question: does the client broadcast their own transaction, or does a third party do it for them?
Client → GET /api/data Gateway ← 402 + invoice Client → broadcasts MsgSend on-chain Client → GET /api/data + X-Payment-Proof Gateway → verifies tx on Neutaro LCD Gateway ← 200 OK (proxied)
Client → GET /api/data Server ← 402 + PAYMENT-REQUIRED header Client → signs EIP-3009 authorization Client → GET /api/data + PAYMENT-SIGNATURE Server → POST to Facilitator /settle Facilitator → broadcasts tx on-chain Server ← 200 OK + PAYMENT-RESPONSE
ClawPurse: 2 parties, 0 intermediaries. x402: 3 parties, facilitator controls settlement.
Feature-by-feature comparison
| Dimension | ClawPurse Gateway | x402 (Coinbase) |
|---|---|---|
| Trust model | Peer-to-peer. No intermediary. Gateway verifies directly on-chain. | Facilitator-dependent. Coinbase (or third-party) verifies and settles every payment. |
| Settlement | Client broadcasts their own transaction. Full control, full visibility. | Client signs an authorization. Facilitator broadcasts. Client hopes it settles. |
| External dependencies | Zero. Single binary + SQLite + Neutaro LCD API. Nothing else. | Facilitator service (Coinbase-hosted), EIP-3009 or Permit2 token support, SDK integration. |
| Prepaid balances | Built-in. Deposit once, deduct per request. No repeated on-chain txs. | Not supported. Every request requires a fresh payment cycle. |
| Route-level pricing | One env var: GATEWAY_ROUTES="/expensive/*=1.0,/cheap/*=0.001" |
Per-endpoint middleware config with SDK. |
| Audit trail | Complete local ledger in SQLite — every invoice, payment, balance change, tx hash. | Settlement records live on the facilitator. Server gets a response, not a queryable history. |
| Client requirements | Any Neutaro wallet. Standard MsgSend + memo. No SDK, no signing library. | EIP-3009 or Permit2 signing (EVM), SPL authorization (Solana), XDR building (Stellar). Per-chain SDK required. |
| Deployment | docker compose up -d — one command, done. |
Server middleware + facilitator endpoint config + SDK + wallet setup. |
| Verification speed | Waits for on-chain confirmation (seconds to minutes depending on block time). | Instant cryptographic signature verification. Resource served before settlement completes. |
| Gas costs for client | Client pays gas on every MsgSend (cheap on Neutaro, but nonzero). | Gasless. Facilitator pays gas. Client only signs. |
| Multi-chain | Neutaro / Cosmos SDK. | EVM (Base, Ethereum, Polygon, Avalanche), Solana, Stellar, Sui, Algorand, Hedera, Aptos. |
| Ecosystem size | Neutaro / Timpi / ClawPurse ecosystem. | 5,400+ GitHub stars, 193 contributors, backed by Coinbase, Cloudflare, Anthropic, Circle. |
| Overpayment protection | Client controls the tx. Accidental overpayment is possible (gateway checks ≥ amount). | Signed authorization specifies exact amount. Facilitator can't charge more. |
| Replay protection | Memo-based invoice matching. Works, but memos are user-controlled. | Cryptographic nonces enforced at the smart contract level. Replay impossible by design. |
Where ClawPurse Gateway wins
🛡 No facilitator dependency
x402 routes every payment through a facilitator — a third-party service that verifies signatures, broadcasts transactions, and controls when settlement happens. Currently, that facilitator is overwhelmingly Coinbase itself. Circle is building a competing one, but the ecosystem remains centralized around a single operator.
ClawPurse Gateway talks directly to the Neutaro blockchain via its public LCD API. There is no middleman who can go down, censor transactions, rate-limit your payments, or extract fees. If the chain is running, your gateway is running. Self-sovereign by architecture, not by promise.
⚡ Prepaid balance accounts
An AI agent making 1,000 API calls through x402 needs 1,000 separate payment cycles — each one requiring a signed authorization, facilitator verification, and on-chain settlement. That's 1,000 blockchain transactions for 1,000 HTTP requests.
ClawPurse supports prepaid balance deposits. An agent deposits NTMPI once, then sends requests with an X-Client-Id header. The gateway deducts per-call from the local balance. Zero additional on-chain transactions. Zero latency overhead. This is the difference between a payment protocol and a payment system.
📦 Deployment simplicity
ClawPurse Gateway is a single TypeScript process with a SQLite file. Set two env vars (GATEWAY_PAYMENT_ADDRESS and JWT_SECRET), run docker compose up -d, and you have a production payment gateway. No external services, no SDK integration, no facilitator endpoint configuration.
x402 requires installing framework-specific middleware (@x402/express, @x402/evm, @x402/svm), configuring a facilitator URL, setting up chain-specific wallet infrastructure, and managing SDK dependencies per target blockchain. The "one line of code" marketing becomes several hundred lines once you include the SDK, wallet, and facilitator plumbing.
🔍 Full local audit trail
Every invoice, payment, balance change, and transaction hash is stored in the gateway's local SQLite database. You own the data. You can query it, export it, audit it. The payment_log table records direction, route, client ID, and timestamp for every event.
x402's settlement records live on the facilitator's infrastructure. The server receives a PAYMENT-RESPONSE header confirming success, but doesn't automatically maintain a queryable, auditable local history. For compliance and financial reporting — especially when combined with Basis Timpi for cost basis tracking — local data sovereignty matters.
🔓 Any wallet can pay
Paying through ClawPurse Gateway requires one thing: the ability to send a standard Cosmos SDK MsgSend with a memo field. That's every Neutaro wallet that exists — Keplr, Leap, the ClawPurse CLI, or a raw REST call. No special signing library, no chain-specific SDK, no EIP-3009 knowledge.
x402 clients need to understand EIP-3009 transferWithAuthorization signing on EVM, or Permit2 witness patterns, or SPL token authorization on Solana, or XDR transaction building on Stellar. Each chain has its own complex client-side integration that requires a dedicated SDK.
Where x402 wins
We're not here to pretend the comparison is one-sided. x402 has genuine architectural advantages in specific scenarios.
⏱ Instant verification
x402's facilitator verifies a cryptographic signature, not an on-chain transaction. Verification is instantaneous — the resource can be served before settlement even completes. ClawPurse waits for actual block confirmation, which introduces latency depending on Neutaro's block time and the operator's confirmation requirement.
⛽ Gasless client experience
x402 clients never pay gas. The facilitator broadcasts the transaction and absorbs gas costs. ClawPurse clients pay gas on every MsgSend. On Neutaro the cost is negligible, but it's still an extra balance the client must maintain.
🌍 Multi-chain ecosystem
x402 supports 8+ blockchains today with active PRs adding more. A single x402 client can pay on whichever chain the server accepts. ClawPurse is purpose-built for Neutaro. If your use case requires multi-chain payment optionality from day one, x402 has broader reach.
Choose your architecture
Choose ClawPurse Gateway if…
You want zero third-party dependencies, peer-to-peer settlement with no facilitator, a single Docker command to deploy, prepaid balance accounts for high-frequency agents, a full local audit trail, and the simplicity of "any wallet can pay." You're building on Neutaro and the Timpi ecosystem, and you want self-sovereign infrastructure you control end-to-end.
Choose x402 if…
You need instant signature-based verification, gasless client experience, multi-chain payment flexibility across EVM/Solana/Stellar, and broad ecosystem compatibility with Coinbase-backed tooling. You're building for AI agents that need to autonomously discover and pay for services across many different blockchains.
They're not mutually exclusive. The most powerful architecture may be a gateway that speaks both protocols — ClawPurse's native flow for Neutaro-native clients and x402's header format for interoperable agents. That's where we're headed.