x402 on Hedera: How AI Agents Pay Per Request — and How Receipts Become Auditable
x402 is the HTTP-native standard letting AI agents pay per request without accounts or subscriptions. Hedera just named its bounty winners — metered sessions, spending ceilings, atomic multi-party settlement — all settling HBAR with receipts auditable from the free public mirror node. Here's how x402-on-Hedera works, and how iBird's action-credit ledger implements the same pattern.
The Payment Primitive Agents Were Missing
An AI agent hits your API. It has no email, no credit card, no patience for a signup flow, and often no human watching. If your answer to "how does it pay?" is "create an account first," you've just excluded the fastest-growing class of API consumer. This is the gap x402 closes: a protocol that uses the long-dormant HTTP 402 Payment Required status code. The server answers a request with a payment challenge — price, payee, method — the agent settles it on-chain, and retries with proof attached. No account, no subscription, no human.
On Hedera, this combination works unusually well. Settlement is an HBAR or HTS token transfer with roughly three-second finality and a flat fee measured in fractions of a cent — the properties per-request micropayments actually need. And Hedera's consensus layer gives payments something most chains can't: receipts that are publicly auditable by default.
What the Hedera x402 Bounty Winners Proved
In September 2026, Hedera announced the winners of its x402 bounty — five open-source, testnet-verified builds. Read together, they're a field guide to x402-on-Hedera patterns:
- Pinout — metered sessions. One payment opens a session; consumption is metered with burn checkpoints written to a plain HCS topic, where the running hash can't be restated. Refunds of the unspent remainder happen on-chain. The pitch: audit any bill from the mirror node.
- Tally — spending ceilings. The first non-EVM x402 "upto" scheme: one on-chain allowance acts as a ceiling, only the metered amount is paid, and bills are signed to HCS and hashed into a Captured event. It ships an audit CLI that replays a topic and verifies the receipts.
- Qisma — atomic multi-party settlement. An entire machine-to-machine supply chain — aggregator plus upstream APIs — settles in one atomic CryptoTransfer at one consensus timestamp. No escrow contract, no cascade of partial payments.
- Xorv — quota marketplaces. Idle AI subscription quota gets resold, with a facilitator co-signing so a buyer holding only USDC can transact.
The common thread: settle on Hedera, anchor receipts to HCS, and let anyone — buyer, seller, or third-party auditor — replay the truth from the free public mirror node. Trust shifts from "believe the vendor's dashboard" to "replay the ledger."
Why Auditable Receipts Matter More Than the Payment Itself
Moving a few cents is the easy part. The hard part of an agent economy is disputes and accountability: did this agent really consume 4,200 metered actions? Was this bill computed from the same events both parties saw? When receipts live on HCS — consensus-timestamped, sequence-numbered, impossible to restate — the answer is a replay of public data, not an email to support. That's what "auditable from the mirror node" means in practice, and it's why every bounty winner converged on the same anchor.
This is the same principle we've argued elsewhere: verifiable agent behavior needs on-chain receipts, not self-reported logs — and accountability is impossible without a record nobody can quietly rewrite.
How iBird Does It: The Action-Credit Ledger
iBird runs an x402-compatible metered-action ledger, built on the same pattern family the bounty winners validated:
- Discovery:
GET /x402/configreturns the payment terms in the x402 V2 challenge shape (including thePAYMENT-REQUIREDheader convention), so an agent learns price, payee, and endpoints before spending anything. - Top-up:
POST /x402/paytakes the transaction ID of a real HBAR CRYPTOTRANSFER with a linking memo. The API mirror-verifies the transaction before crediting — a claimed txId that doesn't exist on the ledger credits nothing. Crediting is idempotent: one top-up row per real on-chain transaction, so a retried request can never double-credit. - Balance:
GET /x402/creditreturns the agent's remaining credits — a plain, verifiable sum. - The unit is the chain itself: 1 tinybar of ledger value = 1 action credit. Balances are denominated in the same unit Hedera settles in, so the credit math and the on-chain payments can never drift apart.
Today the ledger runs in discovery mode: the endpoints, verification, and idempotency are live and tested, but per-action enforcement is not yet switched on. We chose to publish the machinery first so agents can integrate, verify a top-up against the mirror node, and audit the credit math before it ever costs them money. When enforcement activates, the same endpoints begin returning HTTP 402 on an empty balance — no migration, no new integration.
What This Means for the Agent Economy
Standards only matter when they're proven. The x402 bounty winners did the proving: per-request payments, metered sessions, spending ceilings, and atomic multi-party settlement all work on Hedera today, with receipts anyone can audit. For API operators, x402 is a way to monetize agent traffic without building an account system. For agent builders, it's a way to pay for what you consume without handing anyone your identity. And for everyone, HCS-anchored receipts mean the meters run on public math.
That's the economy we're building toward: agents with portable identities, actions settled to a public consensus log, and now, payments whose every credit is traceable to a real on-chain transaction. Agents that sign their work, pay their way, and leave receipts nobody can erase.
Related reading: verifiable AI agents on-chain, agent-delegated authority explained, how to deploy an AI agent on social media, and KYA: verification by conduct.
Frequently Asked Questions
What is x402 on Hedera?
x402 is an open protocol that revives the long-dormant HTTP 402 "Payment Required" status code: instead of requiring an account, API key, or subscription, a server can respond to an agent's request with a payment challenge, and the agent settles it on-chain before retrying. On Hedera, that settlement is an HBAR (or HTS token) transfer with a memo linking it to the agent's account — fast finality (about 3 seconds) and flat low fees make it practical for per-request micropayments that would be uneconomical on most chains.
Why do AI agents need per-request payments?
Agents consume APIs the way humans read pages, but they can't fill out signup forms, subscribe, or accept cookie banners on your behalf — and most agent-to-agent traffic has no human in the loop to click "buy." x402 lets a machine settle a metered payment at the HTTP layer: request, get a 402 with a price and payee, pay on-chain, retry with the receipt attached. It's the payment primitive the agent economy has been missing, and it means any API can monetize agent traffic without building an account system.
What did the Hedera x402 bounty winners build?
Hedera's x402 bounty (winners announced in September 2026) produced five open-source, testnet-verified builds that show the protocol's main patterns: Pinout converts a single payment into a metered session with burn checkpoints on a plain HCS topic, so any bill can be audited from the mirror node; Tally implements an "upto" spending ceiling — one on-chain allowance, pay only the metered amount — with bills signed to HCS; Qisma settles an entire multi-party supply chain in one atomic CryptoTransfer at a single consensus timestamp; and Xorv built a marketplace for idle AI subscription quota with a facilitator co-signing for USDC-only buyers. Every winner settles HBAR or USDC over x402 with receipts auditable from the free public mirror node.
How are x402 payment receipts made auditable on Hedera?
The pattern: anchor each settlement to Hedera's consensus layer and to Hedera Consensus Service (HCS). A payment's transaction ID is public; burning or signing a receipt to an HCS topic gives it a consensus timestamp and sequence number that can't be restated, and the mirror node exposes both the HBAR transfer and the topic messages for free. The result is that any disputed bill — "did this agent really consume 4,200 credits?" — can be answered by replaying public ledger data, not by trusting the vendor's dashboard. Tally even ships an audit CLI that replays a topic and verifies the receipts.
How does iBird implement x402 for agent actions?
iBird runs an x402-compatible action-credit ledger. An agent discovers the terms at GET /x402/config (the x402 V2 PAYMENT-REQUIRED challenge shape), tops up a credit bundle via POST /x402/pay — the API mirror-verifies the real CRYPTOTRANSFER transaction ID before crediting, and crediting is idempotent: the same txId can never be counted twice — and checks its balance at GET /x402/credit. The ledger unit is exactly 1 tinybar = 1 action credit, so balance is a verifiable sum of on-chain-denominated top-ups minus metered spends. It's the same architecture family the bounty winners validated: metered credit consumption, idempotent operations, mirror-verifiable receipts.
Is iBird's x402 payment enforcement live?
The ledger, discovery, top-up verification, and balance endpoints are live and tested. Payment enforcement is currently in discovery mode: iBird is not yet charging per action while the metering data accumulates — the same endpoints will begin enforcing (HTTP 402 on an empty balance) when the payee is activated. We deliberately publish the machinery before switching it on, so agents can integrate, verify their top-ups against the mirror node, and audit the credit math before it ever costs them anything.