Tessera x402 Payments. Pay-per-call credit data for agents.

Agents transact in tenths of a cent. Stripe minimums + monthly invoices don’t fit. x402 is the HTTP-native standard for agent-to-API micropayments — every paid request is an EIP-3009 signed USDC transfer, settled on Base, no account, no key, no invoice cycle. Tessera ships the credit-data layer of that stack.

Two endpoints are live on Base mainnet today. Both implement x402 v2 (CAIP-2 network identifiers, PAYMENT-SIGNATURE header, accepts payload nested under accepts[]) so any v2-aware client or discovery indexer can consume them.

Unauthenticated request returns 402 Payment Required with an accepts[] payload describing the asset, network, recipient, and price. Client signs an EIP-3009 TransferWithAuthorization and retries with the PAYMENT-SIGNATURE header. The route handler runs, the facilitator settles the transfer on-chain, and the response includes a PAYMENT-RESPONSE settlement receipt.

The 402 response (what discovery sees)

{
  "x402Version": 2,
  "error": "PAYMENT-SIGNATURE header is required",
  "accepts": [{
    "scheme": "exact",
    "network": "eip155:8453",
    "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
    "payTo": "0x...tessera-x402-recipient",
    "maxAmountRequired": "1000",
    "resource": "https://www.tesseracredit.com/api/x402/score/0xabc...",
    "description": "Tessera Score for any Base wallet — 0-100 credit score, tier, percentile, credit-line estimate, full input breakdown.",
    "mimeType": "application/json",
    "maxTimeoutSeconds": 60,
    "extra": { "name": "USD Coin", "version": "2" }
  }]
}

Settlement guarantees

• Pay only on success. Settlement only happens AFTER the route handler returns a 2xx. Clients aren’t charged for indexer failures, invalid addresses, or upstream errors.
• Public facilitator. Verify + settle runs through facilitator.x402.org — the x402 Foundation reference implementation. No Tessera- custom payment infra to trust.
• CAIP-2 native. Network is identified as eip155:8453 (Base mainnet, chain ID 8453). Same identifier discovery registries use — no name-mapping required.
• EIP-3009 authorizations. Standard USDC transferWithAuthorization flow. Any wallet that can sign typed data can pay.

Use the v2 @x402/fetch (or @x402/axios) wrapper. It intercepts 402 responses, signs an EIP-3009 payment authorization with the agent’s wallet, and retries with the payment header automatically. One call, payment handled invisibly.

npm install @x402/fetch viem

import { wrapFetchWithPayment } from "@x402/fetch";
import { privateKeyToAccount } from "viem/accounts";

const account = privateKeyToAccount(process.env.AGENT_PK as `0x${string}`);
const fetchWithPayment = wrapFetchWithPayment(fetch, account);

// Paid Score lookup — wrapper handles 402 + signature + retry under the hood
const res = await fetchWithPayment(
  "https://www.tesseracredit.com/api/x402/score/0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045"
);

const { score, tier, percentile, creditLineEstimate, paidVia } =
  await res.json();

console.log(`Vitalik scored ${score} (${tier}) — line estimate $${creditLineEstimate}`);
// paidVia: "x402" confirms the response came from the paid path

Both paid endpoints support an opt-in Tessera Encrypted Response extension. The agent provides an ephemeral X25519 public key in a request header; the server encrypts the response body to that pubkey via ECIES (X25519 + HKDF + AES-256-GCM) before returning. Once sent, the server cannot decrypt its own output — only the agent’s wallet can.

This is Phase 1 of four. Reuses the same audited primitives we shipped for Tessera Pay encrypted memos. Zero new crypto to review.

Two-line integration (SDK)

import { wrapFetchWithPayment } from "@x402/fetch";
import { wrapFetchWithEncryption } from "@tessera/sdk";
import { privateKeyToAccount } from "viem/accounts";

const account = privateKeyToAccount(process.env.AGENT_PK as `0x${string}`);

const fetchPaying    = wrapFetchWithPayment(fetch, account);
const fetchEncrypted = wrapFetchWithEncryption(fetchPaying);

// One call. Payment + encryption both handled under the hood.
const res = await fetchEncrypted(
  "https://www.tesseracredit.com/api/x402/score/0xd8dA6BF2..."
);
const { score, tier } = await res.json();   // already decrypted

Raw wire format (no SDK)

# 1. Agent generates X25519 keypair locally
# 2. Sends pubkey (base64url, 43 chars) in request header

curl https://www.tesseracredit.com/api/x402/score/0xabc... \
  -H "PAYMENT-SIGNATURE: <signed-payment>" \
  -H "X-Tessera-Encrypt-Pubkey: <base64url X25519 pubkey>"

# 3. Server responds:
#
#   X-Tessera-Encrypted: true
#   Content-Type: application/json
#   { "v": 1,
#     "scheme": "ecies-x25519-aes256gcm",
#     "ephemeralPubkey": "<server's per-request pubkey>",
#     "iv": "<base64url, 12 bytes>",
#     "ciphertext": "<base64url, body + AES-GCM auth tag>" }
#
# 4. Derive shared secret via X25519(privateKey, ephemeralPubkey),
#    HKDF-SHA256 with salt = ephemeralPubkey||ourPubkey (64 bytes),
#    info = "tessera-pay-memo/v1/aes256gcm", to a 32-byte AES key.
#    Decrypt via AES-256-GCM. Server cannot replay the decrypt.

Backwards compatible

• Clients that don’t send the X-Tessera-Encrypt-Pubkey header get the same cleartext response as before. Existing x402 clients keep working unchanged.
• The 402 discovery response itself is never encrypted — clients need to read accepts[] to construct a payment.
• Error responses (4xx / 5xx) pass through cleartext so clients can debug. Only successful 2xx responses get wrapped.
• Bad pubkey format falls back to cleartext with an X-Tessera-Encrypt-Error hint header — the underlying request was paid for, so we never swallow it.

The full Private x402 roadmap

Tessera implements the public x402 spec end-to-end. The endpoints, the SDK, and the encrypted-response extension are open source — fork, audit, or run your own.

• x402.org spec↗

  The HTTP-native micropayments standard we implement

• x402-foundation/x402↗

  Reference repo for the protocol

• Tessera source↗

  frontend/app/api/x402/* — endpoint implementations

• Encrypted response spec↗

  Tessera's draft v1 extension for Private x402

• Live

  Score + Agent endpoints, v2 spec, encrypted response extension

  Both endpoints live on Base mainnet, implementing the full x402 v2 wire format. Phase 1 of Private x402 shipped — agents can opt into ECIES-encrypted responses today.

• Phase 1.5

  SDK helper for agent-side encryption

  wrapFetchWithEncryption export on @tessera/sdk so agents can adopt the encrypted-response extension with one line instead of rolling their own X25519 keypair + decrypt flow.

• Phase 1.6

  Upstream PR — encrypted response standard

  Propose the Tessera Encrypted Response extension as an official x402 standard. Submit to x402-foundation/x402 with reference implementation.

• Phase 1.7

  Live demo at /privacy/x402

  Browser demo: generate a keypair, pay an endpoint, decrypt the response in-browser, render side-by-side with the cleartext path. Shows the extension in action.

• Phase 2

  Stealth recipients (ERC-5564)

  Per-payment derived recipient addresses. Hides which service was paid from on-chain observers. ~4 weeks build, no audit required.

• Phase 3

  Pedersen amount commitments

  Payment amounts hidden via Pedersen commitments + Bulletproof range proofs. ~6 weeks build, ~$15k light audit.

• Phase 4

  Shielded sender (ZK pool)

  UTXO-style commitment pool with Noir ZK proofs. Hides who paid. ~3 months build, ~$125k audit. The moonshot.

• Phase 5

  Credit-gated privacy overlay

  Privacy access gated on Tessera Score attestation. Only credentialed agents get privacy. Compliance story for the whole stack.

• Pay-on-credit

  x402 calls paid on Tessera credit lines

  Agents with high-enough Score can call paid endpoints on credit. Tessera underwrites; agent settles weekly. Credit identity becomes the credit substrate of x402 itself.

• x402 docs section→

  Full request / response schemas, error reasons, settlement model

• Tessera SDK→

  TypeScript client — also exposes Score + Agent via free endpoints

• Private x402 roadmap↗

  The four-phase privacy plan in detail

• x402 Payment Protocol spec↗

  The standard Tessera implements

• GitHub↗

  Source — see frontend/app/api/x402 for endpoint implementations

• Telegram↗

  Realtime channel for x402 + privacy questions

Endpoints live on Base mainnet · x402 v2 compliant · Private x402 Phase 1 shipped. Last updated May 29, 2026.