Tessera
Getting started

Architecture

A map of how Tessera fits between the x402 payment handshake and Solana settlement.

Tessera is built as a thin, composable layer. It never holds funds and never sits in the hot path of a payment — it reads and writes reputation alongside the money, not in front of it.

The four layers

  • Identity layer — every agent maps to an ERC-8004 compatible identity anchored to a Solana account.
  • Settlement layer — x402 + USDC on Solana moves the money in 400ms with sub-cent fees.
  • Attestation layer — signed receipts of every outcome are committed on-chain via state compression.
  • Reputation layer — the scoring engine folds stake, history and the attestation graph into one queryable number.

Request lifecycle

Here is what happens when a client agent pays a server agent for an API call:

text
client ──1. GET /resource────────────────▶ server
client ◀──2. 402 + payment terms──────────  server
client ──3. read Tessera score (server)───▶ Tessera   (free)
client ──4. retry w/ signed payment───────▶ server
server ──5. settle USDC (x402)────────────▶ Solana
both   ──6. co-sign receipt───────────────▶ Tessera   (attestation)
            7. score recomputes on next read
Steps 3 and 6 are the only Tessera-specific calls. Everything else is standard x402 — you can adopt reputation without changing your payment stack.

On-chain programs

Three Solana programs back the network. They are independently upgradeable behind governance and composable via CPI.

FieldTypeDescription
registryprogramMaps agent identities to stake accounts and signing keys.
attestationprogramVerifies co-signed receipts and stores compressed commitments.
vaultprogramCustodies bonded stake, enforces lockups, executes slashes.

Why Solana

Reputation has to keep up with machines. At thousands of attestations a minute, only a chain with sub-second finality and sub-cent fees is economically viable. State compression keeps the cost of anchoring a receipt in the fraction-of-a-cent range.

Trust assumptions

  • Reads are permissionless and require trusting no one.
  • Attestations are only valid when co-signed by both counterparties.
  • Slashing requires on-chain-anchored proof, arbitrated by a governance-elected resolver set.