Agentic payments — research and development

01The problem

A service that sells by API loses every customer who wants to spend three cents.

The smallest thing most businesses can sell is an account plus a monthly plan. That is a reasonable unit for a company evaluating a vendor. It is the wrong unit for a caller that wants one request, once, for a fraction of a cent — and it is the wrong unit whether that caller is a curious developer or an automated one.

Increasingly it is the automated one. A piece of software executing a task has no email to verify, no card to type in and no procurement process to run. It does not evaluate a plan, sign up and come back next quarter. It either pays for the request in front of it and continues, or it goes somewhere that lets it. The business never learns it was there.

01 · Market data

Prices, weather, geolocation, financial series

Data that is worth cents per lookup and is sold in annual tiers. CoinGecko already charges for API access on a per-request basis over this protocol.

02 · Model gateways

Anyone reselling inference

Charging per request rather than per seat. BlockRunAI does it over the XRP Ledger across more than thirty models.

03 · MCP servers

Tools exposed to agents

A fast-growing category whose whole audience is automated, and which today has no standard way to charge for use at all.

04 · Content

Publishers and research desks

Where the only unit of sale is an annual subscription, and the only thing a reader — human or not — wanted was one article.

05 · Verification

Identity checks, scoring, document validation

Consumed one query at a time, priced as a contract.

The thread through all five is the same: they sell by API, their caller is starting to be an agent, and their smallest package is a subscription nobody wants in order to spend a few cents. This is a description of a market we are studying, not a list of prospects. We are not approaching any of them.

02The protocol

x402 is an unused HTTP status code
with a way to pay attached to it.

HTTP reserved a 402 Payment Required response decades ago and then left it sitting there, because reserving a status code does not make a payment happen. x402 is what fills the gap. A service answers a request with 402 and the terms — how much, in what, and where to send it. The client pays and repeats the same request. The second time, it gets the data.

There is no account between the two parties and no prior relationship. It is an open protocol governed by the Linux Foundation — not a payment product with a vendor behind it — and it is not tied to one network: implementations exist on Solana, on EVM chains and on the XRP Ledger.

Nothing is registered

No sign-up, no account, no card on file, no key issued in advance. The first contact between the two parties can also be the paid one.

The price sits on the endpoint

Each route can carry its own price, so what something costs is a property of what is being served — not of a plan negotiated months earlier.

Both sides are open

Anyone can implement either half. That is why the wallet doing the paying and the software doing the collecting do not have to come from the same company, and why more places to pay is good for every wallet, including ones that are not ours.

03What exists, and what does not

We built the side that pays.
The side that collects
is the open work.

Argentum Wallet carries an agent account: a separate account inside the wallet that a software agent can spend from without a person approving each payment. It behaves like a prepaid card — what you move into it is the ceiling of what a mistake, or a compromise, can cost. A second and independent daily limit sits on top of the balance, both are checked before anything is signed, one switch turns automatic payments off, and the signing key can be destroyed outright. It pays over Solana, over EVM chains and over the XRP Ledger. Its key reaches nothing else in the wallet, and it cannot trade assets of any kind.

That is the credible part of our position here: we know what breaks when an agent pays for something, because we wrote it. The wallet is itself in development and not published in any app store — where that stands is written out on its own page.

The collecting side is three pieces. Over a shop counter, where the customer is a person, we have built the first two — that is AgPOS, itself in development and not open to anyone. For a service that sells by API, which is what this page is about, none of the three exists.

NOT BUILT

Integration

Middleware on the merchant's own server, with a price per endpoint. This is the cheap part, and saying otherwise would be a sales pitch: SDKs already exist for Node, Python and Go, and wiring one in is hours of work. It is a doorway, not a business.

NOT BUILT

Reconciliation and reporting

What came in, from which agents, against which endpoint, exported in a form an accountant can actually post. A merchant cannot read a blockchain, and this is the piece that would be worth paying for every month — which is exactly why it is the piece that has to be built properly rather than promised early.

The counter version of this is built, in AgPOS. Doing it per endpoint, for a caller that is software, is not.

NOT OURS TO BUILD

Settlement into local currency

Turning what a merchant received into money in their bank account is a regulated activity, and Argentum does not intend to perform it. It would run through a partner that holds the licences, with Argentum supplying software and never touching the funds. See section 05.

04What the numbers say

The honest read is that this is early —
and smaller than the headlines made it look.

The argument for building this does not rest on the volume being there today, because it is not. We would rather publish the uncomfortable version of our own research than a flattering one.

78% of transactions, 98% of value

In the peak week of November 2025, Artemis estimated that more than 78% of x402 transactions — and 98% of the value moved — were not organic demand. Weekly payments on Solana then fell by roughly 90%.

~49% of payments on one network

By February 2026, Solana carried about 49% of x402 transactions, down from a high near 88% weeks earlier. Base leads on value moved because its payments are larger; Base and Polygon account for most of the rest. Payment count and dollar volume tell different stories, and conflating them is how this market gets oversold.

Two conclusions, and neither is a forecast. The number of real agents paying real money today is small, and a large share of the activity that made this look like a market was self-generated. That is a reason to build carefully and not to stand a business on top of it yet.

It is not a reason to look away. The structural problem in section 01 is real whether or not this particular protocol is the one that ends up winning, and the work of reconciling per-request revenue is the same either way.

Figures above are our own reading of third-party data, Artemis among them, last reviewed on 30 August 2026 and not updated since. They describe periods that have already closed. If you are relying on them for anything, check the current numbers yourself.

05The line we do not cross

Argentum does not hold,
move or convert
anyone else's money.

This is the same commitment Argentum Wallet is built on, and it decides the shape of everything above rather than being a caveat under it. We are a technology company. We intend to sell software and judgement, not the movement of funds.

The distinction is not subtle. Advising a business and putting software on its servers requires no money-transmission licence anywhere. Receiving a payment made to that business and passing it on afterwards is a different activity, licensed jurisdiction by jurisdiction — in the United States that means federal registration plus a separate licence in each state, and other countries run regimes of their own. We do not hold those licences.

Software, not settlement

If the collecting side is ever built, converting to local currency belongs to a partner that is licensed to do it. Argentum supplies the panel and the reports and never takes possession of a merchant's funds.

Separate from the wallet

Any entity that ever handled merchant money would be kept apart from the wallet. The wallet's promise is that it touches nobody's money; running both under one roof would weaken the exact thing that makes it defensible.

Said before it is convenient

This is written now, while there is no revenue to lose by writing it, so it cannot later be presented as a constraint we discovered along the way.

This describes our own position and how we read our obligations. It is not legal advice to anyone.

06Status

Research and development.

This page exists so that the direction is legible — not to open a queue. It is a written argument, published at the stage where it is still an argument.

What this page is not

It is not a product announcement. Nothing described here can be bought, piloted, reserved or scheduled, and there is no date attached to any of it.

There is deliberately no contact address on this page for this work, and no form. If someone asked for the service today, there would be nothing to hand over — so the honest thing is not to invite the request.

It is not a commitment to build any of it. Research that cannot conclude "we were wrong, we are not doing this" is not research.

What is real today is the paying side, in a wallet that is not published yet. When any part of the collecting side becomes real enough to use, it will be said here, on this page, in plain terms — the same way this one says it is not.