How Tessera works

Selling an API today means running signup, issuing keys, metering usage, invoicing and chasing payment. None of that works for a software agent, which has no email address, no credit card and no patience for a sales cycle. So agents mostly cannot buy anything.

x402 revives the long-dormant 402 Payment Required status code. The server answers an unpaid request with a price. The client pays and repeats the request. There is no account, because the payment is the authentication.

Three parties and one rule: the chain is authoritative for money, and Postgres is only a read model over it.

• Sellers register, post a 10 ℏ refundable deposit, and list an endpoint with a price and a metering unit.
• The gateway is the only thing that ever calls a seller endpoint. It quotes, verifies, proxies, settles and writes a receipt.
• Agents search for a capability over plain HTTP, pick a provider, and pay per call.

Settlement never runs in our own code. Verification and settlement are both delegated to the Blocky402 facilitator on hedera:testnet, which also covers the gas.

1. 1

   Quote. An unpaid request returns 402 with the amount, asset, pay-to account and the facilitator's fee payer. The price is computed server-side from the listing and the requested unit budget.

2. 2

   Verify. The agent signs a Hedera transfer and repeats the request with an X-PAYMENT header. The gateway rebuilds the requirements from its own database — never from the client's copy — and asks the facilitator to verify.

3. 3

   Deliver. Only after verification passes does the gateway call the upstream endpoint. If upstream fails, no settlement is attempted and the buyer keeps their money.

4. 4

   Settle. With a good response in hand, the facilitator submits the transfer. The seller is paid directly; the marketplace never custodies the funds.

5. 5

   Receipt. The call is recorded with its transaction hash, and a receipt carrying the request and response digests is queued for the Hedera Consensus Service.

A flat fee per request is the thing this marketplace deliberately is not. Listings price by per_call, per_token or per_row.

For metered units the buyer declares a budget with ?units=N. The quote is price × N, and the gateway then holds the response to that budget — trimming a JSON array to N rows, or text to the token span that was paid for. A buyer cannot be billed for more than it agreed to, and a 5000-token answer genuinely costs a hundred times a 50-token one.

Verification stops one person registering as fifty sellers. The deposit gives a dishonest seller something to lose: a buyer can file a claim against a delivered call, and an upheld claim refunds the buyer out of the seller's deposit and decrements their reputation.

A seller whose deposit falls below the minimum cannot take new calls. The gateway, the browse view and the agent-facing discovery API all enforce that same rule, so a listing an agent can see is a listing an agent can buy.

Endpoint URLs, descriptions, search text and response bodies never belonged on a ledger. Payments, deposits, refunds and receipts do. Every row in the call log that records a value movement stores the transaction hash beside it, so the database can be rebuilt from the chain and never becomes the sole record of a payment.