# Billateral — The Receipt Layer for the Agent Economy > Source: https://billateral.io > Status: pre-launch / development. No live paid service yet. > Operator: SKRRT LLC (Wyoming). > General partner: Alien. ## Tagline Proof for AI payments. Every transaction your agent makes, signed by buyer **and** vendor — on-chain. ## What Billateral is, in one paragraph AI agents are starting to spend real money. Today, when they do, the business gets a blockchain transaction hash — no vendor name, no invoice, no proof of what was bought. Billateral turns every agent payment into a real receipt, signed by **both** the buyer and the vendor and anchored on-chain, so the books, the CPA, and the IRS all see the same thing. At any regular shop the register prints two copies of every receipt — one for the merchant, one for the customer. Billateral is that, for AI agents. ## How the product is shaped Billateral is an **x402 facilitator gateway** — a plugin pair that sits on the payment path on both sides of the wire: - **`@billateral/x402`** is a vendor-side facilitator plugin. It slots into x402 server middleware (Express, Hono, FastAPI) and emits a vendor-side attestation alongside every paid request: line items, tax ID, business purpose, terms. - **`@billateral/agent`** is an agent-side client wrapper. It carries the buyer's delegation proof, co-signs the vendor attestation, and pushes the bilaterally-signed receipt into the next anchor batch. Billateral never holds funds. The agent pays the vendor directly via x402 — Billateral observes only the metadata and receipt artefact. Our own billing runs in USD, debited from a prepaid balance the customer tops up by card or ACH. **Not a money transmitter, not an MSB.** ## What one Billateral receipt does, in five jobs 1. Audit defense — bilateral signatures and an on-chain commitment make the record non-repudiable for either party. 2. 1099-NEC preparation — vendor identity and tax ID are part of the signed payload. 3. $10,000+ IRS alerts (Form 8300) — high-value payments are flagged at the receipt boundary, not after the fact. 4. Agent-to-agent delegation — the receipt carries the full delegation chain through swarms. 5. Clean export to a CPA — selective disclosure of one receipt, one vendor, one quarter, or a year, with a completeness proof. --- ## Chapter 01 — Why now Four things are converging, all at once: - **Payments went live (2025).** The x402 standard turns any API into something an AI can pay for instantly. Sending money is solved. Keeping track of what was bought is not. - **Agents hire agents (2025–26).** The major AI labs have all shipped protocols that let one agent delegate work — and money — to another. By the time a payment settles, it may have passed through three different bots. - **The IRS is catching up (2024–27).** Form 1099-DA, stricter enforcement of Form 8300, and FinCEN scrutiny on programmable money all land in the next eighteen months. Records must go back seven years. - **CFOs get the bill (2026).** Every agent deployment is hitting a finance review. The controller asks one question — "where's the receipt for this?" — and today nobody buying or building AI agents can answer it. We think that's a product. --- ## Chapter 02 — The problem The IRS does not care that a bot pressed "pay." The business still needs a record — and the chain doesn't hold one. What the chain sees today is a wallet paying a wallet. That is the entire surface area of an x402 settlement: a tx hash, a payer address, a network identifier. No vendor identity. No tax category. No business purpose. No counterparty signature. An agent can trigger a $10,000+ transaction, tripping Form 8300, and the business has fifteen days to file — without a human ever seeing the request. The evidence the CPA will ask for does not exist. The five gaps: - **I. Agents don't sign receipts.** They don't know the business's tax ID. They don't categorize expenses. They don't generate invoices. "Our agent bought it" is a shrug, not a defense. - **II. Vendors don't attest.** A PDF invoice in your inbox is unsigned by both parties. It proves nothing beyond the sender's willingness to send one. - **III. Accounting software is blind to agent spend.** Ledgerbook ingests transactions. It cannot ingest cryptographic bilateral proof of what was purchased and why. - **IV. Swarms hide the paper trail.** When agent A delegates to agent B who hires agent C, the trail of authority disappears. The IRS sees one wallet; the reality is a dependency graph. - **V. 1099-DA lands in 2026.** Crypto brokers report. Businesses paying via agents need vendor documentation ready today — not in the quarter a notice arrives. --- ## Chapter 03 — How it works Five stages. Each one leaves a cryptographic trace. None require a human in the loop. 1. **Stage I — Agent initiates a payment.** Over x402, a wallet tool, or any supported rail. The agent carries a verifiable delegation from its business entity, via the agent-id standard at MVP. 2. **Stage II — Vendor signs line items.** Server-side middleware emits a vendor-side attestation: "I provided this service on this date for this amount, against this business purpose." 3. **Stage III — Buyer co-signs on behalf of.** The buyer-side agent signs with its delegation key. The receipt now bears both signatures, independently verifiable against both public keys. 4. **Stage IV — Encrypt, pin, batch.** Receipt body is encrypted to both parties only. Pinned to IPFS. Hashed with a blinding nonce. The hash enters a Merkle batch alongside thousands of others. Hash construction: `sha256(json || pk_vendor || pk_buyer || r) → merkle_root`. 5. **Stage V — Anchor on Base.** The Merkle root is written on-chain via EAS (Ethereum Attestation Service). The chain learns nothing beyond "a batch exists." Both parties hold an offline-verifiable inclusion proof — forever. --- ## Chapter 04 — The receipt Every Billateral record is a structured, bilaterally-signed object. Human-readable as a PDF, machine-readable as JSON, legally-defensible as evidence. Example fields on a receipt: - Receipt no.: `01HXA4·BQG·C7D9·Q91T` - Issued: `2026-04-15 · 14:30:12 UTC` - Rail: `x402 on Base · USDC` - On-chain tx: `0x4a1b…b37e` - Vendor: `Lumen Data API Ltd` (vendor tax ID `XX-XXXXXXX`) - Buyer: `Northstar Labs Ltd` (buyer tax ID `XX-XXXXXXX`) - Agent: `agent:did:research-agent-v3` - Authority: `auth:2026-04-15/research-runtime` - Category: `data-and-api-services` - Purpose: `Q2 market research runtime` - Line items: `1,000 financial-data API calls — $12.50` - Total: `$12.50 USD (FMV at time of tx)` - Vendor signature: `0x4a1b3c9d0e7a·b37e2f…` - Buyer signature (via agent): `0x9c0e7a1b3c4d·f024e8…` - Anchor: `BATCH #41 · EAS · Base`, root `0x7f4a…c21e` ### Public verification `verify.billateral.io` — any third party pastes a receipt proof and validates it in-browser against the on-chain commitment. No login. No account. The CPA the business already has, on the page they already trust. Signature check runs locally; Merkle inclusion proof checks against a Base RPC. ### Selective disclosure Share one receipt, one vendor, one quarter, or the whole year. An optional completeness proof lets the business prove they've shared all receipts for a period — the count is baked into the Merkle root, so any omission is cryptographically detectable. --- ## Chapter 05 — Security and privacy The chain learns nothing. The parties learn everything. A content-hiding commitment anchors the receipt's existence without exposing its contents. Only the two parties — and the auditors they authorize — can read it. | § | Property | Primitive | | --- | --- | --- | | 04.1 | End-to-end encryption to an explicit reader list (buyer, vendor, admin, granted auditors). Reader list is append-only, so adding an auditor never re-encrypts the body and on-chain commitments never need to be re-anchored. | HPKE · RFC 9180 | | 04.2 | Bilateral signatures. Both parties sign the same structured payload before it is finalized. Neither side can alter the record after the fact without invalidating the other's signature. | Ed25519 · secp256k1 | | 04.3 | Content-hiding commitments. On-chain state per batch is a single Merkle root: no parties, no amounts, no business details. Auditors verify inclusion offline with a proof the business hands over. | EAS on Base | | 04.4 | Trust-scored counterparties. Each party carries a trust score derived from verified tax ID, bilateral-signing history, agent-id provenance, and dispute record. Agents can refuse to transact below a threshold. | pre-commit, agent-side | | 04.5 | Stage 2 (post-seed) — zero-knowledge aggregation, range proofs, capability-based access grants. The commitment scheme is SNARK-compatible by construction; no forced migration. | Noir / Circom | If Billateral's servers are compromised, an attacker sees commitments and ciphertext, not contents. A competitor sniffing on-chain state learns "Billateral anchored a batch this hour" — and nothing more. Vendor list, spend, categories: invisible. --- ## Chapter 06 — Swarms and delegation When agents hire agents, the paper trail holds. An agent managed by another agent is still spending the business's money. Billateral records the whole dependency path — not just the wallet that pressed "pay." Example tree (mocked): ``` ▼ orchestrator · "research-v3" agent:did:…a1 │ ├─ entity: Northstar Labs Ltd EIN: XX-XXXXXXX │ └─ delegation: q2-research-runtime │ ├─ ▸ researcher · "scout-2" agent:did:…b4 │ ├─ ● PAID $12.50 lumen-data-api rx-01H·Q91T bilateral ✓✓ EAS batch 41 root 0x7f…c21e │ └─ ● PAID $4.00 search-index-svc rx-01H·R02F bilateral ✓✓ EAS batch 41 root 0x7f…c21e │ └─ ▸ transcriber · "scribe-1" agent:did:…c7 ├─ ● PAID $0.80 whisper-hosted-api rx-01H·S14A bilateral ✓✓ EAS batch 41 └─ ● PAID $2.20 summary-agent-svc rx-01H·S14B bilateral ✓✓ EAS batch 42 Σ run total $19.50 · 4 / 4 bilateral · attributed to Northstar Labs Ltd · category data-and-api-services ``` The CFO sees a flat ledger. The auditor, if asked, sees the tree. The chain sees a single commitment. --- ## Chapter 07 — Dashboard preview The operator console is in design. Top up a USD balance; watch agents debit it in real time. Each receipt's body is encrypted once; the list of who can read it is append-only — agent, vendor, or admin can grant a new auditor at any time, before or after creation, with the same one-line operation. Numbers in the preview are mocked; nothing is billed today. --- ## Chapter 08 — FAQ **Q·01 Is this an accounting system?** No. Billateral produces the receipt — the primitive evidence. A ledger (Ledgerbook, Greenbook, Chainbook, Cryptoledger) ingests those receipts and handles reporting. Billateral is the layer between the agent and the ledger, not a replacement for either. **Q·02 Can the vendor refuse to co-sign?** Yes — which is its own signal. If a vendor declines to co-sign after 72 hours, the receipt is marked **unilateral**. The buyer still holds a non-repudiable attestation on the signing side, plus the on-chain payment. A pattern of unilateral receipts with a given vendor pulls their trust score down. **Q·03 Who can see a receipt?** The buyer, the vendor, and anyone either party explicitly shares a proof with — typically a CPA or auditor. Billateral's servers store only encrypted blobs and commitments; we cannot decrypt receipts. The chain sees a Merkle root per batch and nothing else. **Q·04 What does the accountant do?** Whatever they already do. The business exports a per-receipt proof or an audit bundle and sends it via the channel they already use. The accountant verifies at `verify.billateral.io` or via the `billateral-verify` CLI. No logins. No role management. **Q·05 Does this work for human payments too?** Yes — the schema generalizes. Agent-first at launch because that's the market with the acute unmet need; human-initiated spend uses the same primitive and the same exports. **Q·06 Does Billateral handle the money?** No. The agent pays the vendor directly via x402; funds never touch us. We see only the metadata, and only after both sides have signed it. When paid access opens, our fee is debited from a prepaid USD balance the customer tops up by card or ACH (like Twilio or OpenAI credits) — the bank and CFO see a normal SaaS line, not a crypto inflow. We are **not a money transmitter** and not an MSB. **Q·07 What happens if Billateral goes down?** Receipts already exist. They are pinned to IPFS, committed on Base, and held by both parties. The hosted service provides indexing, sync, and exports — but the cryptographic layer is offline-verifiable by any third party with a Base RPC endpoint and the `billateral-verify` CLI. --- ## Integration surface — facilitator plugins Billateral integrates as an x402 facilitator on both ends of the wire. Two SDKs, no servers in the money path. ### Vendor side — `@billateral/x402` Drops into the x402 server middleware as a plugin: ```ts import { paymentMiddleware } from "x402-express"; import { billateral } from "@billateral/x402"; app.use(paymentMiddleware({ network: "base", payTo: "0x…", plugins: [ billateral({ apiKey: process.env.BILLATERAL_KEY, vendor: { name: "Lumen Data API Ltd", taxId: "XX-XXXXXXX" }, }), ], })); ``` Every paid request now carries a vendor-side signature, awaits the buyer's co-signature, and anchors into the next batch on Base. Express, Hono, and FastAPI shapes ship at MVP. ### Agent side — `@billateral/agent` Wraps the agent's HTTP client. First-class adapters ship for **OpenClaw**, AgentKit, Crewly, Loomkit, AutoForge, Northwind AI SDK, MCP tool-server runtimes, and raw HTTP clients. The wrapper attaches the delegation proof, co-signs the vendor attestation, and emits the receipt to Billateral for batching. ### Custody boundary Funds flow agent → vendor directly via x402. Billateral's plugins observe and sign metadata; they do not move money. SaaS fees are billed in USD against a prepaid dashboard balance. **Not a money transmitter, not an MSB.** --- ## Standards and primitives referenced - **x402** — HTTP-native micropayment protocol (Coinbase). Billateral is a facilitator gateway on this protocol. - **Base** — Ethereum L2. - **EAS** — Ethereum Attestation Service (anchor target). - **HPKE** — Hybrid Public Key Encryption, RFC 9180. - **Ed25519, secp256k1** — signature schemes. - **Form 1099-DA, Form 8300, FinCEN** — US tax and AML regimes Billateral is built to satisfy. - **agent-id** — the project's emerging standard for verifiable agent delegation; used at MVP. --- ## Contact Direct contact addresses are not published in this document to limit harvesting. The site exposes them through the live pages below; the postal address routes to the same Skrrt LLC entity for any channel that needs paper. - Privacy and data-subject requests: https://billateral.io/privacy (Contact section) - Security disclosures: https://billateral.io/privacy (Security section) - Legal: https://billateral.io/terms (Contact section) - Postal: c/o Northwest Registered Agent Service Inc, 30 N Gould St, Ste N, Sheridan, WY 82801, United States - GitHub: https://github.com/skrrt-sh ## License The Billateral name, logo, copy, design, and code on the site are owned by SKRRT LLC. Reading, linking, and screenshotting are fine. Repackaging the content as your own is not.