SKRRT LABS · IN DEVELOPMENT · 2026
AGENT ID · ALIEN
WAITLIST · OPEN
Billateral.
PROOF FOR AI PAYMENTS.
Every transaction your agent makes,
signed by buyer and vendor — on-chain.
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 your books, your CPA, and the IRS all see the same thing. Trust the agent. Prove the agent.
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.
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.
Form 1099-DA, stricter enforcement of Form 8300, and FinCEN scrutiny on programmable money all land in the next 18 months. Records must go back seven years.
The controller asks one question: "where's the receipt for this?" Today, nobody buying or building AI agents can answer it. We think that's a product.
The IRS does not care that a bot pressed “pay.” The business still needs a record — and the chain doesn’t hold one.
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.
{
"success": true,
"payer": "0xb37e…",
"transaction": "0x4a1b…",
"network": "base:8453",
// what did they buy? ?
// on whose behalf? ?
// under what authority? ?
// what tax category? ?
// fair market value USD? ?
}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.
Five stages. Each one leaves a cryptographic trace. None of them require a human in the loop, and none of them leave the paper trail to chance.
Over x402, a wallet tool, or any supported rail. The agent carries a verifiable delegation from its business entity — via our agent-id standard at MVP.
Server-side middleware emits a vendor-side attestation: “I provided this service on this date for this amount, against this business purpose.”
The buyer-side agent signs with its delegation key. The receipt now bears both signatures — independently verifiable against both public keys.
Receipt body encrypted to both parties only. Pinned to IPFS. Hashed with a blinding nonce. The hash enters a Merkle batch alongside thousands of others.
The Merkle root is written on-chain via EAS. The chain learns nothing beyond “a batch exists.” Both parties hold an offline-verifiable inclusion proof — forever.
Every Billateral record is a structured, bilaterally-signed object. Human-readable as a PDF, machine-readable as JSON, legally-defensible as evidence.
Verification is designed to run client-side: any third party pastes a receipt proof into a static page and validates it in-browser against the on-chain commitment. No login, no account — the CPA you already have can verify a receipt without onboarding to anything new. Signature check runs locally; the Merkle inclusion proof checks against a Base RPC. The hosted verifier ships alongside the SDK at MVP.
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.
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.
The receipt body is encrypted to a list of explicit reader public keys — buyer, vendor, admin, and any auditor either party grants access to. Not to Billateral. Not to an indexer. Not to a third party.
If our servers are compromised, the attacker sees commitments and ciphertext — not contents. The reader list is append-only, so adding an auditor never re-encrypts the body, and on-chain commitments never need to be re-anchored.
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.
This is the property that makes a Billateral receipt a genuine receipt — not just an invoice in an inbox. Both sides independently hold the same cryptographically-bound artifact.
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.
A competitor sniffing on-chain state learns "Billateral anchored a batch this hour" — and nothing more. Your vendor list, your spend, your categories — invisible.
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 you set.
Raise the threshold for treasury-size payments. Lower it for dust-sized API calls. The policy is enforceable at the payment boundary, not post-hoc in the books.
Stage 2 adds aggregation proofs ("total paid to vendor X in 2026 is exactly $60,000" — without revealing line items), range proofs, and capability-based access grants.
Phase 6 layers on top of Phase 1. The commitment scheme is SNARK-compatible by construction. No forced migration; no broken history.
An agent managed by another agent is still spending your money. Billateral records the whole dependency path — not just the wallet that pressed “pay.”
Agent A delegates a research task to agent B, which hires paid tool C and subcontracts transcription to agent D. Four entities, three payments, one taxpayer on the hook.
Billateral follows the delegation chain. Every receipt carries the full dependency path — which agent authorized which, under whose entity, for which business purpose. No transaction leaves the process unattributed.
The CFO sees a flat ledger. The auditor, if asked, sees the tree. The chain sees a single commitment.
▼ 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 root 0x7f…c21e
│
└─ ● PAID $2.20 summary-agent-svc rx-01H·S14B
└─ bilateral ✓✓ eas · batch 42 root 0xe2…9a08
─────────────────────────────────────────────
Σ run total $19.50
receipts 4 / 4 bilateral
attributed to Northstar Labs Ltd
tax category data-and-api-services
A peek at the operator console we're building. Top up a USD balance, watch your 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 below are mocked for illustration; nothing is billed today.
The body is encrypted once with a fresh key K. That key is wrapped independently to every reader. Adding a reader later just appends a new wrap — the body ciphertext stays bit-identical forever.