Receipts for the agent economy
Agents are paying you.
Where are your receipts?
Billateral turns every agent payment you accept into a signed, itemized receipt. One copy for you, one for your buyer, so your books, their books, and anyone either of you authorizes all see the same thing.
An agent paid you. That is all anyone knows.
When an AI agent buys from you, you get a payment reference and nothing else. No counterparty, no invoice, no record of what was sold to show an accountant or a tax authority. Your buyer's books are just as blind. "An agent bought it" is not an audit defense.
That is the whole record. Good luck in an audit.
Two copies of every receipt. One for you, one for your buyer.
At any register the receipt prints twice: one for the merchant, one for the customer. Billateral does that for AI agents. When an agent pays you, you sign an itemized receipt of the sale, it seals, and each side walks away with a copy that opens with its own key. The proof is anchored on a public chain, so neither of you can quietly rewrite history. Hence the name: two copies, two owners, one truth.
Sealed like a window envelope: anyone can check it arrived intact, only the two keys can open it.
One receipt. Five jobs it does for you.
-
Revenue you can invoice
Every agent payment becomes an itemized, signed record: who paid, for what, when. Ready for your accountant.
-
Know your buyer
See a domain-verified operator behind the agent that paid you, not just an anonymous wallet. Operators whose agents already sign the requests they send have nothing to set up at all.
-
Audit defense
A signed, timestamped record of who bought what, from whom, and why. Sealed at settlement, verifiable years later.
-
Works even one-sided
The buyer's agent has never heard of us? You still issue the same signed, sealed receipt on your side.
-
Buyers prefer you
Buyers get their copy automatically. The vendor with receipts is the vendor agents are told to choose.
Every agent payment, accounted for.
How it works
- 01
An agent pays you
Over the payment rails agents already use. Nothing changes about how money moves.
- 02
You sign what was sold
The payment already carries the buyer's authorization. You add the part it is missing: a signed, itemized statement of what the money actually bought.
- 03
Sealed, anchored, shared
The receipt is encrypted so only you, your buyer, and the people either of you authorizes can read it. Its fingerprint is anchored on a public chain forever, and your buyer holds a copy that opens with their own key.
Sneak peek · not yet deployed
One quiet dashboard for your side of it.
Built and passing its tests, not yet running anywhere you can reach. You will sign in with a passkey, so there is no password to phish; watch receipts land as your store issues them; and control exactly who can open them, down to a single accountant.
Receipts as they land
Every receipt your store issues appears in one index, each linked to its proof on a public chain.
Readers, not logins
Add your accountant by name and send one setup link. The list of people who can open your receipts is yours to edit; removing someone takes one click and stops them opening anything issued afterwards.
Keys that rotate
One credential connects your store. If the API key leaks, rotate it from the console; your passkey stays the root credential.
The chain proves it exists. Only you can read it.
Private by default
The receipt is encrypted to you and your buyer. Not to us, not to an indexer, not to the public.
We cannot read it
We host the list of readers, but we cannot read the receipt. Only the people on it can. Even if our servers were compromised, there is nothing to see but encrypted data.
Verify without an account
Verification is a static page and a public chain lookup, so anyone you share a receipt with checks it in their browser. No login, no onboarding.
Outlives us
Receipts are anchored on a public chain and held by both parties. They stay verifiable even if Billateral disappears.
Built for the people who sign off on the books.
Agent spending is landing on finance reviews now. New crypto-broker reporting, cash-equivalent thresholds, and multi-year retention rules all arrive over the next several quarters.
Audit bundles
Pull every receipt for a counterparty, a quarter, or a full year into one export: line items, identities, timestamps, and the on-chain proof for each. Your auditor gets evidence, not screenshots.
Selective disclosure
Share exactly one receipt, or a whole period, with exactly one person. Access is granted per reader and every receipt knows who can open it. Removing a reader is forward-looking: it stops them opening anything issued afterwards.
Your existing ledger
Billateral produces the receipt; QuickBooks, Xero, or NetSuite handle the rest. Evidence in, entries out.
Insights are your call
By default we only see that a receipt exists, never what is inside. If you want spend insights from us, you choose which receipts to share. Off by default, never resold.
Solana, behind the same seam.
Billateral was built Base-first, where receipts anchor through EAS, and Solana is an additive second rail. Payments settle over x402 exact-svm; receipts anchor through the Solana Attestation Service (SAS). Same product, same receipt, second rail: a vendor points at it with two credentials, and nothing about how they already take payment changes.
A fixed ~296-byte on-chain account carries one commitment for any number of receipts, so the per-receipt cost of anchoring falls as each batch fills.
One anchor, many receipts
A single SAS attestation commits to N receipts at once under one Merkle root: an index-ordered sha256 tree with domain-separated leaves. Each receipt keeps its own Merkle inclusion proof.
Rent that amortizes
The on-chain batch account is a fixed ~296 bytes no matter how many receipts it covers, so the per-receipt cost of anchoring falls as each batch fills.
Same setup, second rail
The vendor integration does not change shape. Point it at the Solana rail with the same two credentials; the way payments already settle for you stays exactly as it was.
A chain-family seam
The abstraction is chain-family shaped, not chain-specific. Two rails slot in behind the same seam today; more slot in behind it later.
Neither rail is deployed yet. The batching scheme, its tree and its verifier are built and tested; nothing has been anchored on any mainnet, and the cost of batched anchoring is calculated from rent tables rather than measured on chain. The batching itself is split out as a standalone MIT-licensed library, so anyone can batch attestations or check a single proof without us — though it is not on a package registry yet either.
When agents hire agents, the trail should still hold.
One agent delegates to another, which hires a tool, which subcontracts a third. Four parties, three payments, one business on the hook. Each of those payments gets its own sealed receipt. Linking them into a single chain of authority, so an auditor can walk the whole tree, is the next protocol milestone. The receipt format already reserves the field for it.
Questions finance, legal, and engineering ask.
Can I use it today?
No. The protocol and a working build exist and the test suites are green, but nothing is deployed: there is no hosted service to point at and the packages are not on npm. This site is a waitlist and nothing more. Everything ships publicly when it is ready, and the waitlist is how you hear about it the moment it does.
Is this an accounting system?
No. Billateral produces the receipt, the underlying evidence. Whatever ledger you already use ingests it. We are the layer between the agent and your books, not a replacement for either.
Who can see a receipt?
You, your counterparty, and anyone either of you explicitly shares it with, typically a CPA or an auditor. We store only encrypted data; we cannot read your receipts.
Does Billateral handle the money?
No. Your agent pays the vendor directly; the funds never touch us. We are not a money transmitter. When paid access opens, our fee comes from a prepaid balance you top up by card or ACH, a normal SaaS line on your books.
What if the buyer's agent does not support Billateral?
You still issue a signed, sealed receipt on your side. Receipts work even when the buyer is a vanilla agent. When both sides participate, the buyer gets their copy too and the record becomes bilateral.
How do you know who the buyer actually is?
Three different things get sold as "verified identity", and we keep them apart. Key control proves the same key signed and paid: real continuity, but it says nothing about who anyone is, and a wallet made a minute ago passes. An anchored claim is the operator of a domain saying that wallet is theirs, published under a name they provably control, so you re-check it against that domain without trusting us. Third-party attestation is an outside party doing diligence and vouching that an entity is real; we do not ship one of those today, and we would rather say so than let the weaker two be mistaken for it. Every receipt records which check was actually run, and the vendor sets the floor they will accept.
How is this different from agent authorization standards?
Authorization standards like AP2 prove an agent was allowed to buy before the payment; the payment rail proves money moved. Billateral proves what was actually bought, by whom, sealed at settlement time. They compose: authorization before the payment, our receipt after it.
Does this work for human payments too?
Yes. The same receipt works whether an agent or a person pressed pay. We start with agents because that is where the need is most acute.
What happens if Billateral goes away?
A receipt, once issued, is anchored on a public chain and held by both parties. The hosted service adds indexing, sync, and exports, but anyone can verify a receipt without us — that independence is the point of the design.
We are building it in the open.
Billateral is in active development. No round closed, no paid users, nothing deployed: a public spec, a working build, and green test suites. Get on the list, or build with us.