Exact

The exact scheme is a fixed-price payment scheme. The seller advertises one amount, the buyer signs for that exact amount, and the facilitator settles that payment for the request. Use exact when the final charge is known before the response is generated, such as a fixed-price API call, file download, or gated page.

Server Setup

TypeScript
Go
Python

import { HTTPFacilitatorClient } from "@x402/core/server";
import { paymentMiddleware, x402ResourceServer } from "@x402/express";
import { ExactEvmScheme } from "@x402/evm/exact/server";
import { ExactSvmScheme } from "@x402/svm/exact/server";

const facilitatorClient = new HTTPFacilitatorClient({
  url: "https://x402.org/facilitator",
});

const resourceServer = new x402ResourceServer(facilitatorClient)
  .register("eip155:84532", new ExactEvmScheme())
  .register("solana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1", new ExactSvmScheme());

app.use(
  paymentMiddleware(
    {
      "GET /weather": {
        accepts: [
          {
            scheme: "exact",
            price: "$0.001",
            network: "eip155:84532",
            payTo: "0xYourAddress",
          },
          {
            scheme: "exact",
            price: "$0.001",
            network: "solana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1",
            payTo: "YourSolanaAddress",
          },
        ],
        description: "Weather data",
        mimeType: "application/json",
      },
    },
    resourceServer,
  ),
);

routes := x402http.RoutesConfig{
    "GET /weather": {
        Accepts: x402http.PaymentOptions{
            {
                Scheme:  "exact",
                Price:   "$0.001",
                Network: "eip155:84532",
                PayTo:   "0xYourAddress",
            },
            {
                Scheme:  "exact",
                Price:   "$0.001",
                Network: "solana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1",
                PayTo:   "YourSolanaAddress",
            },
        },
        Description: "Weather data",
        MimeType:    "application/json",
    },
}

handler := nethttpmw.X402Payment(nethttpmw.Config{
    Routes:      routes,
    Facilitator: facilitatorClient,
    Schemes: []nethttpmw.SchemeConfig{
        {Network: x402.Network("eip155:84532"), Server: exactevm.NewExactEvmScheme()},
        {Network: x402.Network("solana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1"), Server: exactsvm.NewExactSvmScheme()},
    },
})(mux)

from fastapi import FastAPI

from x402.http import FacilitatorConfig, HTTPFacilitatorClient, PaymentOption
from x402.http.middleware.fastapi import PaymentMiddlewareASGI
from x402.http.types import RouteConfig
from x402.mechanisms.evm.exact import ExactEvmServerScheme
from x402.mechanisms.svm.exact import ExactSvmServerScheme
from x402.server import x402ResourceServer

app = FastAPI()
facilitator = HTTPFacilitatorClient(FacilitatorConfig(url="https://x402.org/facilitator"))

server = x402ResourceServer(facilitator)
server.register("eip155:84532", ExactEvmServerScheme())
server.register("solana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1", ExactSvmServerScheme())

routes = {
    "GET /weather": RouteConfig(
        accepts=[
            PaymentOption(
                scheme="exact",
                price="$0.001",
                network="eip155:84532",
                pay_to="0xYourAddress",
            ),
            PaymentOption(
                scheme="exact",
                price="$0.001",
                network="solana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1",
                pay_to="YourSolanaAddress",
            ),
        ],
        description="Weather data",
        mime_type="application/json",
    ),
}

app.add_middleware(PaymentMiddlewareASGI, routes=routes, server=server)

Upfront payment flow

By default, exact uses the authorization flow: the payment is verified before the resource handler runs and settled after. When your resource needs on-chain finality before execution — for example, a long-running handler on Solana where the signed transaction’s blockhash may expire before the handler finishes — you can opt in to the upfront flow instead. With upfront, settlement happens before the handler runs. The facilitator’s /settle endpoint both validates and commits the payment; /verify is not called. The client signs the same payload as in authorization; only the server-side ordering changes. To opt in, set paymentFlow: "upfront" in the route’s extra config:

TypeScript
Go
Python

app.use(
  paymentMiddleware(
    {
      "GET /weather": {
        accepts: [
          {
            scheme: "exact",
            price: "$0.001",
            network: "eip155:84532",
            payTo: evmAddress,
            extra: { paymentFlow: "upfront" },
          },
          {
            scheme: "exact",
            price: "$0.001",
            network: "solana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1",
            payTo: svmAddress,
            extra: { paymentFlow: "upfront" },
          },
        ],
      },
    },
    resourceServer,
  ),
);

routes := x402http.RoutesConfig{
    "GET /weather": {
        Accepts: x402http.PaymentOptions{
            {
                Scheme:  "exact",
                Price:   "$0.001",
                Network: x402.Network("eip155:84532"),
                PayTo:   evmAddress,
                Extra: map[string]interface{}{
                    "paymentFlow": "upfront",
                },
            },
            {
                Scheme:  "exact",
                Price:   "$0.001",
                Network: x402.Network("solana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1"),
                PayTo:   svmAddress,
                Extra: map[string]interface{}{
                    "paymentFlow": "upfront",
                },
            },
        },
    },
}

routes = {
    "GET /weather": RouteConfig(
        accepts=[
            PaymentOption(
                scheme="exact",
                price="$0.001",
                network="eip155:84532",
                pay_to=evm_address,
                extra={"paymentFlow": "upfront"},
            ),
            PaymentOption(
                scheme="exact",
                price="$0.001",
                network="solana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1",
                pay_to=svm_address,
                extra={"paymentFlow": "upfront"},
            ),
        ],
    ),
}

The authorization flow remains the default. Clients prefer authorization when both flows are offered; the server signals the resolved flow to clients via extra.paymentFlow in the 402 response. See Payment flows for a comparison of all flows.

Client Setup

TypeScript
Go
Python

import { x402Client } from "@x402/core/client";
import { ExactEvmScheme } from "@x402/evm/exact/client";
import { ExactSvmScheme } from "@x402/svm/exact/client";
import { createKeyPairSignerFromBytes } from "@solana/kit";
import { base58 } from "@scure/base";
import { privateKeyToAccount } from "viem/accounts";

const evmSigner = privateKeyToAccount(process.env.EVM_PRIVATE_KEY as `0x${string}`);
const svmSigner = await createKeyPairSignerFromBytes(
  base58.decode(process.env.SVM_PRIVATE_KEY!),
);

const client = new x402Client();
client.register("eip155:*", new ExactEvmScheme(evmSigner));
client.register("solana:*", new ExactSvmScheme(svmSigner));

import (
    x402 "github.com/x402-foundation/x402/go/v2"
    exactevm "github.com/x402-foundation/x402/go/v2/mechanisms/evm/exact/client"
    exactsvm "github.com/x402-foundation/x402/go/v2/mechanisms/svm/exact/client"
    evmsigners "github.com/x402-foundation/x402/go/v2/signers/evm"
    svmsigners "github.com/x402-foundation/x402/go/v2/signers/svm"
)

evmSigner, err := evmsigners.NewClientSignerFromPrivateKey(os.Getenv("EVM_PRIVATE_KEY"))
if err != nil {
    log.Fatal(err)
}

svmSigner, err := svmsigners.NewClientSignerFromPrivateKey(os.Getenv("SVM_PRIVATE_KEY"))
if err != nil {
    log.Fatal(err)
}

x402Client := x402.Newx402Client().
    Register("eip155:*", exactevm.NewExactEvmScheme(evmSigner, nil)).
    Register("solana:*", exactsvm.NewExactSvmScheme(svmSigner))

import os

from eth_account import Account

from x402 import x402Client
from x402.mechanisms.evm import EthAccountSigner
from x402.mechanisms.evm.exact.register import register_exact_evm_client
from x402.mechanisms.svm import KeypairSigner
from x402.mechanisms.svm.exact.register import register_exact_svm_client

client = x402Client()

account = Account.from_key(os.getenv("EVM_PRIVATE_KEY"))
register_exact_evm_client(client, EthAccountSigner(account))

svm_signer = KeypairSigner.from_base58(os.getenv("SVM_PRIVATE_KEY"))
register_exact_svm_client(client, svm_signer)

Casper Setup

The Casper implementation uses CEP-3009 (transfer_with_authorization) — Casper’s adaptation of EIP-3009 for CEP-18 tokens. The client signs an off-chain EIP-712 authorization; the facilitator relays it on-chain and pays the gas. Install the Casper package:

npm install @x402/casper

Server

import { x402ResourceServer } from "@x402/core/server";
import { ExactCasperScheme } from "@x402/casper/exact/server";

const resourceServer = new x402ResourceServer(facilitatorClient)
  .register("casper:casper-test", new ExactCasperScheme());

// In your route config — price must be specified as an explicit asset amount:
{
  "GET /data": {
    accepts: [
      {
        scheme: "exact",
        price: {
          amount: "1500000000", // atomic units
          asset: "0cb6f94834c60510d532b0ae077b18b4100874a4c867396d61c2b13c790ead52", // contract_package_hash
          extra: { name: "csprUSD", version: "1" },
        },
        network: "casper:casper-test",
        payTo: "007a9f9948cb7b258d18f3c5e85780372971b5b40096e724c9e596c284a01445fa",
      },
    ],
    description: "Data endpoint",
    mimeType: "application/json",
  },
}

Client

import { createClientCasperSigner } from "@x402/casper";
import { ExactCasperScheme } from "@x402/casper/exact/client";
import { x402Client } from "@x402/core/client";

// Default algorithm is ED25519; pass 2 for secp256k1
const casperSigner = await createClientCasperSigner(process.env.CASPER_PRIVATE_KEY!);

const client = new x402Client()
  .register("casper:*", new ExactCasperScheme(casperSigner));

Facilitator

import { createFacilitatorCasperSigner } from "@x402/casper";
import { ExactCasperScheme } from "@x402/casper/exact/facilitator";
import { x402Facilitator } from "@x402/core/facilitator";

const casperSigner = await createFacilitatorCasperSigner(
  process.env.CASPER_PRIVATE_KEY!,
  1, // 1 = ED25519, 2 = secp256k1
  {
    rpcUrlConfig: { "casper:casper-test": process.env.CASPER_RPC_URL! },
    // Optional: enable speculative execution for preflight validation
    // speculativeRpcUrlConfig: { "casper:casper-test": process.env.CASPER_SPECULATIVE_RPC_URL! },
  },
);

const facilitator = new x402Facilitator()
  .register("casper:casper-test", new ExactCasperScheme(casperSigner));

The asset field is the 32-byte hex contract_package_hash of the CEP-18 token. The extra.name and extra.version fields are required — they are used to construct the CEP-3009 EIP-712 domain separator.

XRPL Setup

The XRPL implementation uses payer-signed Payment transactions. The payer pays the XRPL transaction fee; facilitator-sponsored fees are not supported. Install the XRPL package:

npm install @x402/xrpl

Server

import { x402ResourceServer } from "@x402/core/server";
import { ExactXrplScheme } from "@x402/xrpl/exact/server";

const resourceServer = new x402ResourceServer(facilitatorClient)
  .register("xrpl:*", new ExactXrplScheme());

// In your route config:
{
  "GET /data": {
    accepts: [
      {
        scheme: "exact",
        price: {
          amount: "1000000", // 1 XRP in drops
          asset: "XRP",
        },
        network: "xrpl:1", // XRPL testnet
        payTo: "rYourXrplAddress",
      },
    ],
    description: "Data endpoint",
    mimeType: "application/json",
  },
}

Client

import { Wallet } from "xrpl";
import { x402Client } from "@x402/core/client";
import { createXrplWalletSigner } from "@x402/xrpl";
import { ExactXrplScheme } from "@x402/xrpl/exact/client";

const wallet = Wallet.fromSeed(process.env.XRPL_SEED!);
const signer = createXrplWalletSigner(wallet);

const client = new x402Client()
  .register("xrpl:*", new ExactXrplScheme(signer));

Facilitator

import { x402Facilitator } from "@x402/core/facilitator";
import { ExactXrplScheme } from "@x402/xrpl/exact/facilitator";

const facilitator = new x402Facilitator()
  .register("xrpl:*", new ExactXrplScheme());

XRPL supports two asset transfer methods via extra.assetTransferMethod:

Method	Description
`sequence`	Uses the payer account’s current sequence number. Default. One pending payment per account at a time.
`ticketSequence`	Uses a pre-created XRPL Ticket. Allows multiple concurrent pending payments per account.

For ticketSequence payments, the client automatically creates a ticket when none is available. To provision tickets explicitly:

import { createTickets, createXrplWalletSigner } from "@x402/xrpl";

const ticketSequences = await createTickets(signer, "xrpl:1", 5);

Cardano Setup

The Cardano implementation uses a client-signed, facilitator-submitted model: the client builds and signs the complete transaction but never broadcasts it. The facilitator verifies and submits it after the resource handler runs. Install the Cardano package:

npm install @x402/cardano

Server

import { x402ResourceServer } from "@x402/core/server";
import { ExactCardanoScheme } from "@x402/cardano/exact/server";
import { masumiEscrowAddress, toMasumiSellerSigner } from "@x402/cardano";

const resourceServer = new x402ResourceServer(facilitatorClient)
  .register("cardano:*", new ExactCardanoScheme());

// Address-to-address payment
{
  "GET /data": {
    accepts: [
      {
        scheme: "exact",
        price: {
          amount: "1000000", // 1 USDM (6 decimals)
          asset: "c48cbb3d5e57ed56e276bc45f99ab39abe94e6cd7ac39fb402da47ad.0014df105553444d",
        },
        network: "cardano:mainnet",
        payTo: "addr1YourCardanoAddress",
        maxTimeoutSeconds: 600,
      },
    ],
  },
}

Client

import { x402Client } from "@x402/core/client";
import { ExactCardanoScheme } from "@x402/cardano/exact/client";
import { toClientCardanoSigner } from "@x402/cardano";

const provider = {
  blockfrost: {
    baseUrl: process.env.BLOCKFROST_PREPROD_URL!,
    projectId: process.env.BLOCKFROST_PROJECT_ID!,
  },
};

const clientSigner = toClientCardanoSigner({
  mnemonic: process.env.CARDANO_MNEMONIC!,
  network: "cardano:preprod",
  provider,
});

const client = new x402Client();
client.register("cardano:*", new ExactCardanoScheme(clientSigner));

Facilitator

import { x402Facilitator } from "@x402/core/facilitator";
import { ExactCardanoScheme } from "@x402/cardano/exact/facilitator";
import { toFacilitatorCardanoSigner } from "@x402/cardano";

const facilitatorSigner = toFacilitatorCardanoSigner({
  network: "cardano:preprod",
  provider,
});

const facilitator = new x402Facilitator()
  .register("cardano:preprod", new ExactCardanoScheme(facilitatorSigner));

The facilitator only broadcasts the client’s signed transaction — it requires no funded wallet.

Cardano asset transfer methods

The Cardano implementation supports three asset transfer methods via extra.assetTransferMethod:

Method	Description
`default`	Address-to-address payment. Standard x402 flow.
`masumi`	Locks funds into the Masumi `vested_pay` escrow for agent-to-agent payments with refund and dispute mechanics.
`script`	Locks funds into any server-defined contract with an optional arbitrary datum.

For testnet funds, get test ADA from the Cardano testnets faucet and preprod tUSDM from the tUSDM faucet.

Network Implementations

The exact scheme has network specifications for EVM, SVM, AVM, Stellar, Aptos, Casper, Hedera, TON, Cardano, Keeta, Sui, Concordium, NEAR, and XRPL.

SVM Smart Wallet Support

By default, the SVM facilitator only accepts transactions from standard (EOA) wallets using static instruction-layout validation. To also accept payments from Solana smart wallets (Squads, Swig, SPL Governance, etc.), enable simulation-based verification when constructing ExactSvmScheme on your facilitator:

TypeScript
Go

import { ExactSvmScheme } from "@x402/svm/exact/facilitator";
import { toFacilitatorSvmSigner } from "@x402/svm";

const svmSigner = toFacilitatorSvmSigner(svmAccount);

facilitator.register(
  "solana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1",
  new ExactSvmScheme(svmSigner, undefined, {
    enableSmartWalletVerification: true,
  }),
);

import (
    svmmech "github.com/x402-foundation/x402/go/v2/mechanisms/svm"
    svm "github.com/x402-foundation/x402/go/v2/mechanisms/svm/exact/facilitator"
)

settlementCache := svmmech.NewSettlementCache()

facilitator.Register(
    []x402.Network{"solana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1"},
    svm.NewExactSvmScheme(svmSigner, &svm.Config{
        SettlementCache:               settlementCache,
        EnableSmartWalletVerification: true,
    }),
)

When EnableSmartWalletVerification is enabled, transactions that fail static validation (because they contain smart wallet program instructions) are re-verified by simulating the transaction and inspecting CPI inner instructions for a valid TransferChecked. Only programs in the built-in allowlist (Squads Multisig v4, Squads Smart Account, Swig, SPL Governance, Metaplex Core, Lighthouse) can reach this path.

TypeScript: toFacilitatorSvmSigner() is required when enabling smart wallet verification — it provides the simulateTransactionWithInnerInstructions, getConfirmedTransactionInnerInstructions, getTokenAccountBalance, and fetchAddressLookupTables methods needed for simulation-based verification.Go: Your signer must implement SmartWalletRPCCapabilities (i.e. SimulateTransactionWithInnerInstructions, GetConfirmedTransactionInnerInstructions, GetTokenAccountBalance, and FetchAddressLookupTables) — NewExactSvmScheme panics at startup if EnableSmartWalletVerification is true and the signer does not satisfy this interface.

Additional options:

TypeScript
Go

Option	Type	Default	Description
`enableSmartWalletVerification`	`boolean`	`false`	Enable simulation-based verification for smart wallet transactions.
`smartWalletMaxComputeUnits`	`number`	`400000`	Maximum compute units allowed for smart wallet transactions.
`smartWalletMaxPriorityFeeMicroLamports`	`number`	`50000`	Maximum priority fee in microlamports for smart wallet transactions.
`smartWalletAllowedPrograms`	`string[]`	Built-in list	Allowed smart wallet program addresses. Only transactions invoking a program in this list reach simulation-based verification.
`maxPriorityFeeMicroLamports`	`number`	`5000000`	Maximum compute unit price in microlamports accepted on the static path. The facilitator pays the transaction fee, so this bounds the priority fee a payer can make it pay.
`maxComputeUnits`	`number`	No limit	Maximum compute unit limit accepted on the static path. An SPL transfer with a memo uses ~20k CU; a low ceiling still leaves ample headroom for wallet-injected instructions.
`maxRequiredSignatures`	`number`	No limit	Maximum number of required signatures. Every signature adds 5,000 lamports of base fee paid by the facilitator. A typical x402 payment needs two (payer + fee payer).

Field	Type	Default	Description
`EnableSmartWalletVerification`	`bool`	`false`	Enable simulation-based verification for smart wallet transactions.
`SmartWalletMaxComputeUnits`	`*uint32`	`400000`	Maximum compute units allowed for smart wallet transactions.
`SmartWalletMaxPriorityFeeMicroLamports`	`*uint64`	`50000`	Maximum priority fee in microlamports for smart wallet transactions.
`SmartWalletAllowedPrograms`	`[]string`	Built-in list	Allowed smart wallet program addresses. Only transactions invoking a program in this list reach simulation-based verification.
`MaxPriorityFeeMicroLamports`	`*uint64`	`5000000`	Maximum compute unit price in microlamports accepted on the static path.
`MaxComputeUnits`	`*uint32`	No limit	Maximum compute unit limit accepted on the static path.
`MaxRequiredSignatures`	`*uint8`	No limit	Maximum number of required signatures. Every signature adds 5,000 lamports of base fee paid by the facilitator.
`SettlementCache`	`*SettlementCache`	New cache	Shared settlement cache for duplicate detection. Pass the same instance to V1 and V2 SVM schemes.

EVM Transfer Methods

The EVM implementation supports two transfer methods:

Method	Description
`eip3009`	Uses token-native `transferWithAuthorization`, commonly for USDC. This is the default when supported.
`permit2`	Uses Uniswap Permit2 plus the x402 exact proxy, so it can support ERC-20 tokens without EIP-3009.

Permit2 may require a one-time approval. The gas sponsoring extensions can let the facilitator handle that approval path for compatible tokens.

Welcome

Getting Started

Core Concepts

Payment Schemes

Extensions

Advanced Concepts

Guides

Developer Tools

SDK Features

Server Setup

Upfront payment flow

Client Setup

Casper Setup

XRPL Setup

Cardano Setup

Cardano asset transfer methods

Network Implementations

SVM Smart Wallet Support

EVM Transfer Methods

Examples

Specs

See Also

​Server Setup

​Upfront payment flow

​Client Setup

​Casper Setup

​XRPL Setup

​Cardano Setup

​Cardano asset transfer methods

​Network Implementations

​SVM Smart Wallet Support

​EVM Transfer Methods

​Examples

​Specs

​See Also

Server Setup

Upfront payment flow

Client Setup

Casper Setup

XRPL Setup

Cardano Setup

Cardano asset transfer methods

Network Implementations

SVM Smart Wallet Support

EVM Transfer Methods

Examples

Specs

See Also