DZEKA.EXE

INSERT COIN — PITCH AN IDEA

Got something worth a cabinet? One coin, one pitch. I read every one.

PROCESSING CREDIT…
CREDIT ACCEPTED
idea launched — I'll ping you soon
+1 CREDIT · PLAYER TWO JOINED
← BACK TO THE FLOOR
SYSTEM 02 · MISSION BRIEFING

Tollgate

An x402 facilitator and payment gateway in Rust — pay-per-call APIs, verified at the gate.

ROLESOLO — EVERYTHING
TIMELINE2026 — PRESENT
STACKRUST · AXUM · POSTGRES · REDIS · EVM
STATUSSHIPPED · M7 / M7 ↗
Live capture of the one-command demo: five legs through the real gate — an unpaid call answered with the price list, the same call paid for and served, that same header replayed and refused, a freshly signed authorization buying the tool call, and a valid signature from a payer who cannot cover it. The run is replayed a second time through tail so the five verdicts land together.

LEVEL 1THE PROBLEM

An autonomous agent cannot fill in a checkout form, and an API cannot hand credentials to a caller it has never met. x402 revives HTTP 402 for exactly that: the server answers an unpaid request with a price, the caller signs a payment authorization and retries, and the call goes through — no account, no invoice, no human in the loop. The 402 is the easy half; the gateway behind it has to verify the signature offline, refuse a nonce twice, know the payer can cover the charge before committing, and keep the signing key somewhere a request handler cannot reach. Tollgate is that gateway — the toll booth you put in front of an API so machines can pay per call.

LEVEL 2THE BUILD

Six Rust crates and three binaries: an HTTP gateway whose PaymentGate middleware answers an unpaid request with a 402 challenge, verifies the EIP-3009 authorization presented in the X-PAYMENT header, and proxies upstream only once the payment holds; a claim ledger in Postgres; nonce reservation in Redis via SET NX PX, which makes replay a race the second attempt loses rather than a lookup that might be stale; per-payer velocity and spend caps, plus an on-chain balanceOf check debited by claims already owed, so the gate refuses payments the payer cannot actually cover; and a separate settler binary that is the sole holder of the signing key and sweeps accepted claims on-chain. Redis and Postgres are env-gated — the gate runs without either. Every decision written up as an ADR.

Tollgate system architecture An agent presents an X-PAYMENT header carrying an EIP-3009 authorization to the gateway, whose PaymentGate middleware answers unpaid calls with a 402 challenge, reserves the nonce in Redis, records the claim in PostgreSQL, optionally checks balances on Base Sepolia and proxies paid calls to the upstream API; the isolated settler sweeps recorded claims every 60 seconds and is the only component that broadcasts transferWithAuthorization to the chain. TOLLGATE 6 Rust crates · 3 binaries agent X-PAYMENT / EIP-3009 402 challenge gateway axum reverse proxy pay or 402 PaymentGate tower middleware verify · reserve settler sole key holder batch sweeper proxy 200 upstream API origin service SET NX PX Redis nonce reservation optional · env-gated record claim PostgreSQL claim ledger optional · env-gated sweep 60s balanceOf · optional transferWithAuthorization Base Sepolia USDC · EIP-3009 L2 testnet Rust binary datastore external service system boundary

BOSS FIGHTTHE RESULT

Feature-complete: every milestone from M0 to M7 landed — the offline EIP-3009 verifier, the gateway and its PaymentGate middleware, the Redis replay guard, the claim ledger and the settler, a one-command end-to-end demo, and a benchmark suite. On one machine (release build, 2,048 requests at concurrency 32, loopback, in-process upstream) the full accept path — verify, reserve the nonce, record the claim, proxy — sustains 58,024 req/s at a 500 µs p50, and verifying a payment costs 97.5 µs on its own. 224 tests across 24 test binaries and 11 proptest properties at 65,536 cases each hold it in place. Base Sepolia only, not audited, no real funds have ever moved — a working testnet system with measured performance, not a production payment processor.

HIGH SCORES

  • 58,024REQ/SECFULL ACCEPT · LOCAL BENCH
  • 500 µsP50 LATENCYP95 813 µs · P99 1.01 ms
  • 97.5 µsPAYMENT VERIFYCRITERION · verify_payment
  • 224TESTS24 TEST BINARIES · 0 FAILING
  • 721KPROPTEST CASES11 PROPERTIES × 65,536 CASES
  • 96DECISIONSADRS · 6 CRATES / 3 BINARIES
NEXT LEVEL
Payment Rail