Nanopayments solved the cost problem.
Hive solves the audit trail.
When an agent pays in fractions of a penny, you don't get to skip compliance. You just have to rebuild it. A thousand sub-cent calls a minute, with no gas fee per transaction, still need a SHOD attestation for each spend, a scope receipt for each trade, and a decryption lens for each role that reads it. Without that, the CFO, the auditor, and the regulator are all reading one line that says "agent did stuff" and just trusting it. Hive built the envelope every one of those nanopayments travels through, signed off-chain and verifiable offline; any chain anchor must be separately selected and specified.
Unified balanceOne balance, one authorization surface
Paying for everything from one balance is a real upgrade. It also concentrates the thing you have to be able to prove. Once an agent can draw on a single balance, the interesting question stops being whether the money moved. It becomes what that agent was allowed to do with the balance, and whether anything else moved against it while nobody was reading.
Here is a live example from a public x402 paywall. It offers two ways to pay the same 0.001 USDC on Base. One uses EIP-3009 and expires in 300 seconds. The other draws on a Gateway balance and sets maxTimeoutSeconds to 2592000 with a minValiditySeconds floor of 604800. Same asset, same amount, and an authorization window 8,640 times wider. The payload does not record which rail the agent chose, or who said it could.
This is not a custody problem. Circle is explicit that the burn intent is signed by the user, and that without that signature Circle cannot move a depositor's USDC on its own. Depositors keep ownership and a 7-day trustless withdrawal. Credit where it is due, that part is solved.
What is still open is the record. Circle's technical guide describes the spendable balance as an offchain ledger that the Gateway System decrements when it issues an attestation, and increments again if that attestation expires unused. That works fine until two parties read it differently. A merchant holding an attestation and an agent operator holding a burn intent are both reading a record kept by the same third party, and neither one holds anything that says what the spend was for.
Three receipts that close it
- authority.carriage. The scope the operator actually admitted travels all the way to the effect record, signed. If an agent spent outside its mandate, the receipt shows it without either side having to take a position.
- effect.quiescence. A signed statement that nothing prohibited landed against the balance during a bounded interval. That is the artifact a 30-day window needs, and no ledger read can produce it after the fact.
- meter.witness. Twenty-two gates binding the settled amount to the work delivered. x402 proves the charge cleared. This proves the charge matched what the API did.
Sources, all public: Gateway contract addresses, Gateway technical guide, Gateway overview, x402 payment schemes. Circle is not a Hive customer or partner and nothing above describes a deployment. Every figure here is read from the public payload and the public docs.
Why now
The agent stack that shipped in May 2026 covers wallets, service discovery, command-line orchestration, and nanopayments as small as $0.000001. The x402 protocol brings back HTTP 402 as the way machines shake hands on a deal. Sub-cent commerce isn't a thought experiment anymore. It runs today.
None of those releases shipped with an audit-grade envelope, though: something an institutional CFO, a tax attorney, a federal regulator, and an internal audit team can each read on their own, from the same record. Without that envelope, every nanopayment is a black box. With it, every nanopayment can be proven.
Hive built that envelope before the rest of the stack landed. That's the receipt format, the policy attestation engine, and the selective disclosure cryptography. It's ready today, built for Base, and works with any stablecoin, any gateway, any x402 facilitator.
Angle 1 The gap between agent wallet and audit-ready spend
Today's agent stacks give you a wallet that holds USDC with policy controls, a marketplace to discover services, a CLI to script flows, and a payment rail that batches sub-cent calls. That's a complete commerce loop. It's not a complete compliance loop.
A real compliance loop needs three things today's stacks don't generate. First, a signed attestation, made before the transfer leaves the wallet, proving the spend passed the operator's policy. Second, a scope receipt with a time limit, proving the agent was authorized for that exact action at that exact moment. Third, an envelope that can be decrypted selectively, so each reader downstream only sees the slice they're allowed to see.
Without those three things, the wallet is just a checking account, the marketplace is just a directory listing, and the audit log is just a spreadsheet. With them, the same stack becomes something a public company could run on.
Angle 2 SHOD: six gates fire faster than the nanopayment itself
SHOD is Hive's policy attestation engine. It runs six independent checks on every spend an agent tries to make: daily cap, jurisdiction, sanctions, counterparty allowlist, KYC tier, and position limit. All six have to pass locally before the wallet signs. If even one fails, the transfer never broadcasts.
Built for nanopayment speed
- The checks run right at the agent, not over the network. There's no round trip per spend. Policies are signed and cached locally, so SHOD checks the current spend state in microseconds.
- The attestation batches together with the payment. SHOD writes one signed attestation per settlement window, the same way nanopayment gateways already batch their on-chain settlement.
- Only the operator's policy decides. The wallet provider, the marketplace, and the gateway don't get to make decision calls. The customer's signed policy bundle is the only thing that decides.
- Failure is quiet and safe. If a check fails, the transfer just never signs and never broadcasts. There's no half-failed state and no exception to chase down.
Angle 3 HAHS: scope receipts agents present at the door
HAHS stands for Hive Agent Handshake. It's a signed scope receipt with a time limit that the agent hands over along with the payment request. The merchant receiving it, or the x402 facilitator, checks the receipt's signature before delivering the service. The receipt spells out what the agent was allowed to do, who allowed it, and for how long.
For x402 facilitators and merchants
- Drops right into any x402 setup. The 402 response carries the merchant's price, and the agent's retry carries the payment authorization plus the HAHS scope receipt. The facilitator checks both.
- The scope has a time limit. A receipt might be valid for the next 60 seconds, for spends up to $0.10, against counterparty class X. Once that window closes, the receipt is dead.
- You can check it without calling anyone. It only needs a public key to verify. There's no live lookup to Hive. The merchant runs the check inside their own facilitator.
- It holds up under scrutiny later. The scope receipt is exactly what a federal regulator asks for after the fact: proof the agent had authority to do what it did.
Angle 4 ViewKey: one signed JSON, four decryptions
The same nanopayment creates something at least four different people need to see: the CFO needs the total spend, the tax attorney needs the cost basis, the regulator needs the compliance attestations, and the merchant needs the payment confirmation. Right now, those four people get four different exports. ViewKey gives you one signed JSON file and four decryption keys instead. Each role only unlocks its own slice.
For an agent making thousands of calls a minute, this changes everything about how the system works. With ViewKey, the audit log is the one source of truth, and each reader pulls their own view straight from it. Without ViewKey, you're exporting four spreadsheets every reconciliation period and just hoping they match.
Architecture Where Hive sits in a nanopayment stack
- Agent wallet: calls Hive's SHOD attestation engine before it signs. The policy bundle belongs to the customer.
- x402 facilitator or merchant: checks the HAHS scope receipt before delivering the service. It's a public-key check, with no callback to Hive.
- Settlement gateway: batches attestations together with payment settlement. One on-chain anchor per window.
- Downstream readers: the CFO, tax, regulator, and audit teams each decrypt their own ViewKey lens from the same signed JSON.
What integration looks like
If you're building or running a sub-cent agent payment rail, adding Hive means one HTTP call before the wallet signs and one verification step at the facilitator. There's no protocol change, no custody change, and no SDK lock-in.
The full envelope is documented at the A2A spec, with a live demo at /agent-call-demo showing an autonomous agent spending USDC on Base, with all six SHOD gates firing visibly and a dual-signed receipt anchored at the end.