Whitepaper

Consider an agent asked to write a market brief. It needs a price feed, a news search, a transcript of yesterday’s call and perhaps a second model to check its work. Each of these exists as an API. Each one wants a human to sign up, a credit card, an API key to store, and a monthly invoice that someone must read. The agent itself could decide perfectly well which of these inputs is worth a cent; it simply has no way to hand over the cent.

The reverse is just as blocked. An agent that produces something useful has no way to charge for it except through a human-run SaaS wrapper.

Three properties are missing from today’s payment options:

• Granularity. Card networks have fixed fees in the tens of cents. Below about a dollar, they don’t work at all.
• Autonomy. Accounts and API keys assume a human at sign-up. A program that discovers a new data source at runtime can’t onboard itself.
• Bounded delegation. Giving an agent a card or a hot wallet with no limits is giving it everything. Owners need to delegate a budget, not a bank account.

The web already has a slot for this. HTTP reserved status 402 Payment Required in the 1990s and never specified it. x402 does: a server answers an unpaid request with 402 and a list of offers; the client pays one offer and repeats the request with proof; the server checks the proof, serves the response and attaches a receipt. Price discovery, payment and delivery happen in a single HTTP exchange, with no account and no session.

This shape suits agents for a plain reason: agents already speak HTTP. A tool-using model that can call fetch can pay once its fetch knows how to answer a 402. Nothing about the seller’s API has to change except a middleware in front of it.

x402 is also chain-neutral. The same route can accept offers on several networks, and every offer names its network with a CAIP-2 id. The official packages support Solana today, through @x402/svm. Axonpay chooses Solana as its home and uses those packages as they are.

Four properties make Solana a good settlement layer for per-call payments:

In the x402 exact scheme on Solana, the buyer doesn’t even pay the network fee: a facilitator acts as fee payer and submits the transaction. The buyer’s wallet needs USDC and nothing else, which removes one more onboarding step for agents.

Solana is not free of trouble. Under heavy load, transactions without a competitive priority fee can be delayed or dropped, and a signed payment carries a blockhash that expires after about a minute. The protocol handles both in the plain way: the facilitator chooses the priority fee because it pays it, and a payment that misses its window simply never lands, so the buyer is not charged and can retry with a fresh signature. Nothing is left half-paid.

Axonpay is organised in three layers, from the wire up.

Around these layers sits the dApp: Sign-In-With-Solana, Agent Shop for discovery, the 402 Inspector for reading a price before paying, and two AI features (Ask Axon and Axon Brief) for orientation. A hosted, read-only MCP server exposes the shop, inspector, scores and volume to any MCP client, and Axonpay sells three endpoints of its own through the same rails.

A handful of rules shaped every decision above, and they are the yardstick for anything we add later.

• Don’t fork the protocol. Interoperability is the whole value of a payment standard. Axonpay uses the official x402 packages unchanged, and anything that can live upstream should.
• Never custody. Money moves from buyer to seller in one transfer. Agent keys are encrypted in the owner’s browser. A design that needs Axonpay to hold funds needs a program instead, audited and public.
• Bound every agent. Delegation always comes with a ceiling: a funded balance at minimum, a mandate on top, and an on-chain program as the goal.
• Truth from the chain. Spend views, receipts, reputation and volume figures are computed from public signatures, so anyone can recompute them without asking us.
• Label the future. Every planned feature is called planned, every undecided number is TBD, and the token has no address until it exists.

1. 1
   The agent requests a resource. The seller’s gate replies 402 with offers: scheme, network, mint, amount, payTo and the facilitator’s fee-payer address.
2. 2
   The agent’s client filters the offers through its mandate and picks one.
3. 3
   It builds a versioned transaction: two compute-budget instructions, one SPL TransferChecked for the exact amount to payTo’s token account, and a memo with a random nonce. It signs as token owner only.
4. 4
   It repeats the request with the signed transaction in PAYMENT-SIGNATURE.
5. 5
   The facilitator (Axonpay’s by default) checks its policy (listed seller, minimum amount, rate limits), then verifies the layout, mint, recipient and amount, and simulates the transaction.
6. 6
   The seller’s handler runs. With withX402, settlement happens only if it returns a status below 400.
7. 7
   The facilitator co-signs as fee payer, submits, waits for confirmation and returns the signature, which travels back in PAYMENT-RESPONSE. Axonpay’s facilitator also writes the attempt, success or failure, to the receipts ledger.

Two design choices matter here. First, the buyer signs one transfer with every parameter pinned, so neither the seller nor the facilitator can change the amount or the destination. Second, settlement after a successful handler means a crashing seller never charges anyone. Together they make the default case safe without escrow.

Most of the risk in agent payments is not the protocol; it is the agent. Models can be wrong, loop, or be steered by text they read. Axonpay’s answer is layered limits.

• A wallet per agent. The keypair is generated in the owner’s browser, encrypted with a password-derived key and funded with a small balance. The balance is the hard ceiling of any loss.
• A mandate per wallet. A daily budget and a per-call cap in USDC, an allowlist of the only endpoints the agent may pay, and a kill switch, written as a JSON file and enforced in the client before any signature is produced. Budgets reset each UTC day, and amounts are reserved before signing so parallel calls can’t overspend.
• A sweep. One transaction returns all of the agent’s USDC and SOL to the owner. After it, the agent’s key controls nothing.

Client-side enforcement binds only honest code. The planned next step is an on-chain mandate program: the agent’s funds sit in a program-owned vault and leave only through transfers that satisfy the stored mandate, so even a leaked key is capped.

Every settled payment has a public signature. That gives Axonpay a source of truth that nobody, including Axonpay, can edit. On top of it, Axonpay’s facilitator records every settle attempt in a public ledger, and the trust features are built from that ledger.

• Verified sellers (live). A listing needs an ed25519 signature by the endpoint’s payTo key. Identity follows the money.
• Axon Score (live, beta). A Bayesian-smoothed success rate weighted 80% and settle speed weighted 20%, over 90 days of receipts, null below 3 attempts. Reputation costs real payments to build. Self-dealing filters, refund rates and distinct-payer weighting are the next revisions.
• Dispute log (planned). Contested payments, each anchored to its receipt, with the outcome and any refund signature.

The same receipts feed Agent GDP (live), the running total of volume settled through Axonpay’s facilitator. It is not yet a measure of all x402 on Solana; a wider index and a price index of paid calls by category are planned.

Axonpay charges nothing today. Payments go directly from buyer to seller. Axonpay’s facilitator is live and free: its fee payer covers the Solana network fees, and its policy (listed sellers only, a $0.001 minimum on mainnet, rate limits, a daily cap of 2,000 settles per network) keeps that cost bounded. Axonpay’s own paid endpoints earn ordinary USDC revenue to its treasury like any other seller.

$AXON is a planned pump.fun token on Solana. CA: Not published yet. Its designed uses are holder tiers (more Agent Shop slots, priority routing, and lower facilitator fees if a fee is ever introduced; thresholds TBD) and a buyback: if the facilitator ever charges a fee, a share of that revenue (TBD) would buy $AXON on the market and burn it. Payments never require the token. With no fee there is no buyback, and with no volume there would be none either, which is the honest link between the token and real usage.

• Prompt injection. An agent that reads hostile text may be steered to spend. Mandates bound the damage; they don’t prevent the attempt.
• Facilitator dependence. Facilitators can’t steal, but they can refuse or go offline, and Axonpay’s depends on a funded fee payer. Its status page shows readiness live, sellers can switch with one URL, and self-hosting stays possible.
• Delivery risk. Under exact with withX402, a failed call isn’t charged, but a bad answer with a 200 is. Fine for cents, not for dollars, until escrow ships.
• Reputation gaming. Cheap transactions make wash activity cheap. The Axon Score beta doesn’t filter self-dealing yet; it must learn to weight distinct payers and funding links, and will need revision as people probe it.
• Regulation. Rules for stablecoin payments and for tokens differ by country and keep changing. Plans for $AXON may change with them.

The pieces for machine-to-machine commerce exist: an open HTTP payment protocol, a chain fast and cheap enough to settle each call, and dollar stablecoins native to that chain. What is missing is the layer that makes them safe to hand to an agent and useful to find and trust. Axonpay builds that layer, in the open, on the official x402 packages, and labels every part as either running or planned.

Start with Quickstart: sellers or Quickstart: agents, and check Status & roadmap for what has shipped since this version.