Zerker The x402 Gate

Verify payment without holding a key.

A priced route answers an unpaid call with 402 and a challenge. The caller retries with a signed authorization. Gateway checks it and forwards. No outbound call, no signing key, nothing held. The gate is open source.

Payments reference → See external delivery

gate shipped settlement in progress Apache-2.0 EIP-3009 · USDC on Base

HTTP/1.1 402 Payment Required zero-value simulation · no wallet

A real protocol shape, simulated authorization

Nothing runs until the gate is satisfied.

X-Payment-Required: x402
scheme: exact
network: base
amount: 0.00 USDC
resource: /pricing

Waiting for authorization.

Response held at the Gateway

The exchange

Challenge, sign, forward.

x402 is a challenge and response protocol for stablecoin payment authorizations, stewarded by the Linux Foundation's x402 Foundation. A call to a priced route with no X-PAYMENT header is told the price.

Unpaid call

402 Payment Required
X-Payment-Required: x402
scheme:   exact
network:  base
amount:   0.01 USDC
resource: /v1/proxy/{id}

No invocation record is created. An unpaid call never reaches your upstream.

Retry, with authorization

$ curl localhost:8080/v1/proxy/{id} \
    -H "X-PAYMENT: <signed EIP-712 payload>" \
    -d '{}'

202 Accepted  ← forwarded exactly as an
                unpriced call would be

The mechanic

Four checks, none on-chain.

Verification is local and synchronous. It runs inside the Gateway process on every call to a priced route: signature and parameter checks, with no network call and no key to protect.

The check	What it proves	Needs
The EIP-712 signature is valid	The authorization came from the account it claims	Nothing. No outbound call, no RPC node, no signing key
`value` meets the price	They authorized enough, not merely something
`asset`, `network` and `to` match	They signed for what you advertised, not a cheaper chain or another payee
It is inside its validity window	The authorization is live, not expired or post-dated

On failure, 402 again with a coarse reason. On success, the call is forwarded exactly as an unpriced call would be.

The boundary

Verifying is not collecting.

With no facilitator configured, a route stops at the gate. You hold proof the caller could pay, but no funds have moved. On-chain settlement is in progress. When it lands, the same route gains one step between verify and forward.

	Gate only	Gate + settlement (in progress)
Verification	Local, synchronous	Local, synchronous — unchanged
Money movement	None	The facilitator submits on-chain
Replay protection	Best-effort	Authoritative — the nonce is consumed on-chain
Receipt	None	A settlement sub-record on the invocation, with the transaction hash
On failure	`402`, no invocation created	Invocation ends `settlement_failed` — the upstream never runs

Gate-only replay protection is best-effort. Without a settlement step to consume the on-chain nonce, a valid signed payload could be replayed against a gate-only route. Enabling settlement closes this.

Settlement runs before the upstream call and fails the call if it fails, so a call cannot be served but unpaid. On-chain submission is still in progress.

Custody

Gateway never holds a signing key.

Submitting a transaction requires someone to hold a gas key. Gateway delegates that step to a facilitator, which you can run yourself under the same Apache-2.0 license.

Capability	Tier
The x402 payment gate — verify an authorization before forwarding	OSS
Raw payment capture, readable over the API	OSS
Self-hosting a facilitator — the `/settle` server	OSS
Settlement and collection, fee modes, a managed facilitator	Planned commercial

The facilitator is self-hostable under Apache-2.0, but its on-chain settlement is still in progress. The planned commercial product is convenience, not permission to run the protocol.

Custody posture →

Catalog, routing, MCP, observability, and the gate are one Go process. Run it on your own hardware and read the source.

Quickstart → Back to the catalog