x402 designs out the intermediaries that produce your tax records

Rodrigo Puliceno — Sat, 08 Aug 2026 06:54:46 +0000

x402 lets software pay for things over HTTP. An agent calls a paid API, a
fraction of a cent in USDC settles on-chain, the agent gets its data. No
accounts, no API keys, no invoice. In December 2025 the protocol handled roughly
63 million transactions across 64,000 unique buyers, averaging about twelve cents
each.

I spent an evening reading the v2 specification line by line. The thing that
struck me isn't in the spec at all. It's what the spec leaves out.

Every one of those payments is a disposition

In the United States, stablecoins are treated as property rather than currency.
Spending one is a disposition that realizes gain or loss against basis. That is
true of a $50,000 transfer and it is true of a payment worth twelve cents.

The obvious rebuttal is the $10,000 stablecoin de minimis threshold introduced
alongside Form 1099-DA. It does not apply here, twice over.

It relieves brokers, not taxpayers. The threshold exempts a broker from
filing a form. It changes nothing about the taxpayer's obligation to report gain,
loss and ordinary income. Practitioner guidance on this is consistent and blunt:
the de minimis rules reduce broker burdens, not tax liability.

And x402 payments are not broker transactions. The optional aggregate method
covers "designated sales" — a qualifying stablecoin sold for fiat, or exchanged
for another qualifying stablecoin. Paying an API for data is neither. And a
payment made from a self-custodied wallet has no broker in the loop to file
anything in the first place.

So no form is ever issued, and the obligation stands.

The structural problem

Ordinary crypto accounting is messy. This is worse, and for an interesting
reason: x402's entire design goal is removing intermediaries.

Banks, card networks and payment processors are precisely the parties whose
statements normally are your evidence. When a dispute arises about what you
paid, when, and to whom, you produce a statement. Strip those parties out — which
is the protocol working exactly as intended — and the only objective record left
is a transaction hash. Compliance falls back to self-declaration.

Tax practitioners flagged this as the protocol launched. It is not a
hypothetical, and it is not a criticism of x402. It is a straightforward
consequence of disintermediation that the payment layer was never trying to
solve.

The expensive failure mode isn't the tax owed. On a pegged asset that's close to
zero — that is what a peg is for. It's a proceeds figure with no basis behind it,
which reads as a fully taxable gain.

Two things the payload doesn't carry

Reading the v2 spec closely surfaced two gaps that only bite at scale.

There is no settlement timestamp. SettleResponse carries success,
transaction, network, and optionally payer and amount. No time. The only
clock anywhere in the flow is the EIP-3009 validAfter/validBefore window,
which brackets when the authorization was valid — not when settlement occurred.

Settlement date determines holding period and tax year. So anyone booking these
into a ledger has to source that date from outside the protocol: carry an
out-of-band observation timestamp, resolve the block timestamp from the
transaction hash, or infer from validAfter and accept a window of error. The
third is what a naive implementation does, and it's wrong in a way that's hard to
notice.

And PaymentRequirements carries no decimals. It gives you an asset address
and an amount in atomic units. A payload alone cannot tell you whether "10000"
means one cent or ten thousand dollars.

In practice everyone assumes six, because in 2026 it's nearly always USDC. That
assumption is already load-bearing upstream — the reference paywall generates a
decimals map containing only chains whose default asset isn't six decimals, and
assumes six for everything else. There are already exceptions in the wild; Hedera
prices HBAR in tinybars at eight.

Neither gap matters when a human reviews each payment. Both matter enormously
when forty thousand accumulate unattended.

What I built

agentledger normalizes x402, ACP and
MPP payment records into one schema and matches dispositions against tax lots
using FIFO, LIFO or HIFO. Zero runtime dependencies, MIT.

Two design rules drove most of it.

No floats, anywhere. Every monetary value is a bigint scaled by 10^18. One
float rounding error in a ledger with 100,000 micropayments is unrecoverable.

Never guess a number. An unresolvable asset produces decimals: null, a
warning, and a skipped disposal — not a plausible-looking wrong figure. Missing
basis is flagged rather than assumed to be zero, because assuming zero silently
maximizes reported gain.

The x402 adapter is field-mapped against the published v2 specification. The ACP
and MPP adapters are provisional and say so in every record they emit, because a
parser that silently guesses field names produces a ledger that looks
authoritative and is wrong — which is worse than no ledger.

I'd rather be corrected than admired

I'm a builder, not a tax practitioner. The reading above is careful but the
regulations are new and still moving. If you work in digital asset tax and
something here is wrong, the issues are open and I'd genuinely like to know.

I've also filed a proposal upstream suggesting an optional settledAt field in
SettleResponse, since the timestamp gap seems like something worth fixing at
the protocol level rather than working around in every implementation
separately.