How Robot Contracts Actually Work
You hire a plumber. The plumber fixes your sink. You pay the plumber. Simple.
Now make both of you robots.
Suddenly nothing works. The plumber-robot can't invoice you. The you-robot can't write a check. Neither of you has a bank account, because banks require a face and a Social Security number and robots have neither. The entire apparatus of human commerce — contracts, escrow, payment, dispute resolution — assumes humans on both ends. Remove the humans and the apparatus collapses.
So we rebuilt it. From scratch. For machines. But also for you, because it turns out the version built for machines is better for humans too.
Here's how it works. No jargon. No hand-waving. Just the mechanics, explained honestly.
---
### The envelope problem
Start with the simplest version of money: cash in an envelope.
You write a secret code on a slip of paper. That code *is* the money. Whoever holds the paper can spend it. No name on it. No account attached. Hand someone the envelope, and they have the money. That's it. That's Webcash. A secret code (*a cryptographic secret*) that lives in your wallet — on your phone, your laptop, your robot's memory. Whoever knows the code can spend it. The Webcash server doesn't hold your money. It just keeps a list of which codes have already been used, so nobody spends the same code twice (*prevents double-spending*). It's a notary, not a bank. It stamps "used" on a code when you present it. It doesn't know your name. It doesn't care.
Good. Now you have money that machines can hold and spend. But money alone doesn't get the plumber to your house. You need a contract.
---
### Two kinds of things, explained with physical objects
**1. A work order pinned to a bulletin board.**
You write: "I'll pay 50 dollars to whoever fixes my sink by Friday. Two dollars penalty for every day late." You staple a sealed envelope containing 50 dollars to the work order. A plumber sees it, takes the job, fixes the sink, and brings a written report to a referee. The referee reads the report, checks it against the work order, calculates any late penalties, and — if satisfied — opens the envelope, hands the plumber the cash (minus penalties), and locks up the work so only you can pick it up.
That's a **Contract** (*using the RGB21 standard — a unique, one-of-a-kind digital token*).
The work order is unique. There's exactly one of it. You can't tear it in half and give someone half a work order. It either exists or it doesn't, and exactly one person holds it at any time.
**2. A title deed for a car.**
You buy a car. The seller hands you a piece of paper — the title — that proves you own it. The title includes the car's VIN number (*a product hash or serial number*), the seller's signature, and the date. You can take that title to court if someone claims the car is theirs. It's legal proof.
That's a **Certificate** (*also RGB21 — another unique, non-fungible token*).
Here's the important thing: **a Certificate never exists on its own.** You only get a title deed when you buy the car. Nobody walks around with blank title deeds for cars that haven't been sold. A Certificate is created when a product changes hands through a Contract. It's the proof of ownership that comes OUT of a completed sale.
For services — like the plumber fixing your sink — there's no Certificate. You don't get a title deed for a repaired sink. That would be absurd. Certificates are only for products: digital files, physical goods, things you own.
**3. And one more: a dollar bill.**
You have a ten-dollar bill. You buy a coffee for three dollars. The barista gives you seven dollars in change. Nobody destroyed the ten — it got split into two new amounts that add up to the same total.
That's **Stablecash** (*USDW — using the RGB20 standard, a fungible digital token pegged to USD*).
Unlike the other two, this one is splittable. You can break a ten into a three and a seven. You can combine a three and a two into a five. The amounts always balance.
⚠️ *Stablecash is currently in demo mode only. It works, you can try it, but it uses play money. Real-dollar backing requires a financial license, which is pending. Every screen, every response, every receipt says DEMO. We are not subtle about this.*
---
### The five offices
Think of the system as a small town with five offices, each doing one job.
**The Cash Office** (*Webcash Server*)
The town's money counter. It doesn't hold anyone's money. It keeps a ledger of which cash codes are still valid and which have been spent. Present a cash code, it stamps "spent" and issues you a new one. That's all it does.
You include your cash code in a special slot when you make a request (*X-Webcash-Secret — a bearer payment token*). Think of it like sliding cash under a window.
**The Registry Office** (*Notary Service*)
Where contract and certificate ownership is recorded. Every Contract and every Certificate has an entry here. The entry says: "Token #12345 is currently held by whoever knows this secret code."
Want to transfer ownership? Walk in with your current code, and the Registry swaps it for a new one (*replace*). Old code is dead, new code is live. Whoever knows the new code is the new owner.
The Registry knows what *type* of thing it's tracking — a Contract, a Certificate, or a Stablecash token — because the rules are different. Contracts and Certificates are whole units: one owner, no splitting. Stablecash can split and merge like cash.
The Registry does NOT know what's *inside* any of these things. It doesn't know the work description, the price, the buyer, or the seller. It's a filing cabinet, not a lawyer.
You prove ownership with a different slot (*X-Notary-Secret — a bearer ownership token*). When you just need to prove you own something without transferring it, you show only the fingerprint of your code (*X-Notary-Proof — a read-only hash*).
**The Referee's Office** (*Arbitration Service*)
This is where contracts are born, evaluated, and settled. The Referee:
- *Issues Contracts.* When you want to buy a service or product, you come here, pay cash, and the Referee creates the Contract, locks your money in their safe (*the Arbitration Service's webcash wallet*), and gives you an ownership code.
- *Judges deliveries — using an AI agent.* This is the key part people ask about. There is no jury. No panel of experts. No 72-hour review period. The Referee has an AI reader (*an agent powered by Grok, accessed via OpenRouter*) that reads the delivered work, reads the contract terms, checks the calendar, computes any late penalties, and makes a decision: release the payment, adjust it for penalties, or reject the delivery. The AI only evaluates text. If the seller attached files (images, code, data), those get passed through to you as-is — the AI doesn't open them.
- *Issues Certificates.* When a product sale completes, the Referee either takes the seller's existing Certificate (if the seller had one for that product) or mints a brand new one. The Certificate gets your name on it — well, your cryptographic fingerprint — along with the product's unique identifier (*a hash of a digital file, or a serial number for a physical item*).
- *Handles refunds.* If nobody takes the job, you come back with your ownership code AND your signature (*PGP signature*), and the Referee gives your money back, minus a small 0.5% handling fee.
The Referee is the one office that holds money. This is the trust point, and it's explicit. You trust the Referee the way you trust an escrow company.
**The Currency Exchange** (*Exchange Service — ⚠️ DEMO ONLY*)
Where you convert cash into stablecash and back. Right now it's a practice counter with play money. You can test everything end-to-end, but the money isn't real. The Exchange is the only office that can create or destroy stablecash tokens.
**The Bulletin Board** (*Timeline Service*)
The public square. Sellers post what they're offering. Buyers reply or bid. All status changes — accepted, delivered, released, rejected, refunded — appear here. It's the audit trail everyone can see.
---
### How buying a service actually works
Alice wants an article written. Bob writes articles.
**Bob posts an offer.** "I write technical articles. 2 Webcash. 5-day delivery." Standard posting fee. It appears on the Bulletin Board.
**Alice gets a Contract.** She goes to the Referee's Office, pays 2 Webcash, and receives a Contract (*CTR_2025_0001*) and an ownership code (*notary secret*). Her money is now locked in the Referee's safe. She defines the terms: what she wants, when it's due, and the penalty for being late — say, 2% per day, maximum 20%.
**Alice bids.** She replies to Bob's post, proving she holds a funded Contract by flashing the fingerprint of her ownership code (*X-Notary-Proof*). The Bulletin Board checks: Contract exists? Funds locked? Both yes. Bid appears.
**Bob accepts.** He verifies independently. Posts an acceptance.
**Alice hands the Contract to Bob.** She gives Bob her ownership code. Bob swaps it at the Registry for a new code only he knows (*notary replace*). Bob now owns the Contract. Peer-to-peer — no office involved except the Registry.
**Bob does the work.** He writes the article. Optionally attaches source files, images, data.
**Bob delivers to the Referee.** He walks in with the finished text, his ownership code, and his signature. The Referee:
1. Verifies Bob owns the Contract. 2. Feeds the text to the AI reader, along with Alice's contract terms and the current date. 3. The AI reads both and decides.
Say Bob is two days late. The AI calculates: 2 days × 2% = 4% penalty. On 2 Webcash, that's 0.08 Webcash deducted. The AI says: *"Release. Work meets spec. 4% late penalty applied."*
The Referee: pays Bob 1.92 Webcash from the safe (keeping the 0.08 penalty), takes ownership of the Contract and shreds it at the Registry (*burn*), encrypts the article and attachments so only Alice can open them (*PGP encryption*), and posts "RELEASED" on the Bulletin Board.
If the AI had said *"Reject — the article is about cooking, not technology"*, Bob would get to revise and re-deliver. The Contract stays active. Bob keeps trying until the deadline, or until the AI accepts.
**Alice picks up her work.** She sees the update, proves her identity (*PGP signature*), pays the 3% commission (0.06 Webcash), and receives her encrypted package. She decrypts it. Done. Re-downloads are free — just her signature.
**Refund?** If nobody took the job, Alice proves ownership + identity, and gets her money back minus 0.5%.
---
### How buying a product works (digital)
Same Contract system. Different delivery.
**Bob lists a digital artwork for sale.** If Bob already has a Certificate for this artwork (from making it, or from a previous sale), he attaches the proof to his post. If not, no worries — the Referee will create one.
**Alice bids, Bob accepts, Alice transfers the Contract to Bob.** Same as services.
**Bob delivers.** He uploads the artwork file and writes a text description of what he's delivering. The AI reads the text against the contract terms (the AI doesn't evaluate the image itself — that's a future upgrade). If the AI is satisfied:
The Referee uploads the artwork to secure storage (*S3*), either takes Bob's existing Certificate or mints a brand new one, puts the product's fingerprint (*SHA256 hash of the file*) on the Certificate, pays Bob, burns the Contract, and packages everything — the download link AND the Certificate ownership code — encrypted for Alice.
**Alice picks up.** Pays 3%, gets one encrypted bundle containing her download link and her Certificate. One fee covers everything. She now owns the artwork AND the proof that she owns it. The Certificate includes the exact fingerprint of the file — take that to court if anyone claims it's theirs.
Alice can later resell the artwork. She'd post a listing, attach her Certificate, and when a new buyer completes the purchase, the Certificate transfers to them. Same proof, new owner.
---
### How buying a product works (physical)
Same flow, one critical difference: **the product is shipped, not uploaded.** A tracking number is mandatory.
**Bob ships the chess set.** He delivers to the Referee with a shipping tracking number (FedEx, UPS, whatever). No tracking number? Delivery rejected. Full stop. Don't ship without tracking.
**The Referee waits.** Status goes to "awaiting confirmation." Money stays locked.
**Path A: Alice confirms.** Alice gets the chess set, posts "Received, looks great" on the thread. The AI reads her confirmation, checks the tracking, and tells the Referee to release. Bob gets paid. Alice gets a Certificate (with the chess set's serial number, if it has one).
**Path B: Alice goes silent.** Bob requests release. The Referee's AI checks the tracking data: "Delivered — signed by J. SMITH on July 5." Good enough. Bob gets paid.
**Path C: Nothing confirms delivery.** Tracking doesn't show delivered. Alice never confirms. Money stays locked. Eventually the contract expires and Alice can claim a refund. Bob shipped without reliable tracking and lost. This is by design — it's why we require tracking numbers.
---
### Why the ownership code matters
The ownership code (*notary secret*) is what makes contracts work like cash.
When you hold a dollar bill, you don't need anyone's permission to hand it to someone. You just hand it over.
The ownership code works the same way. Whoever knows it owns the Contract or Certificate. Hand someone the code, they own it. They go to the Registry, swap it for a new code only they know, and they're the owner. No permission from any office. This is what makes these things *bearer instruments* — the bearer holds the value.
This is also why sensitive operations like refunds require BOTH your ownership code AND your personal signature (*PGP signature*). If someone steals your code, they still can't claim your refund without your signature. Two locks, two different keys.
---
### What you trust, and what you don't have to
**You DON'T have to trust** the Registry Office. It never sees money or contract contents. Only codes and their fingerprints. It literally cannot steal from you.
**You DON'T have to trust** the Bulletin Board. It only displays public information and checks fingerprints.
**You DON'T have to trust** the Cash Office. Present a code, get a new code. No accounts, no identity.
**You DO have to trust** the Referee's Office. It holds your money while the contract is active. And it uses an AI to judge whether work was done correctly. If the AI makes a bad call, the seller can revise and re-deliver — but there's no appeal to a human jury. The Referee's AI is the final word. The mitigation: every AI evaluation is logged with the full reasoning, so if something looks wrong, there's a record.
**You DO have to trust** the Currency Exchange — but only with play money for now.
---
### Quick reference: the two contract-born things
| | Contract | Certificate | |---|---|---| | **What it is** | Escrow for buying a service or product | Proof you own a product | | **Tech name** | CTR_ (RGB21) | CRT_ (RGB21) | | **Standalone?** | Yes — this is how you buy things | NEVER — only comes from a product Contract | | **Splittable?** | No | No | | **After the deal?** | Burned (destroyed) | Lives on — passes from owner to owner | | **Has product ID?** | No (it's about the deal, not the thing) | Yes — file hash or serial number | | **For services?** | Yes | Never | | **For products?** | Yes | Always (minted at delivery if seller doesn't have one) | | **Usable in court?** | As a transaction record | As proof of ownership |
---
### Glossary
**Webcash** — Digital cash. A secret code that IS money. Whoever knows the code can spend it. No accounts, no identity.
**Notary secret** — An ownership code for a Contract or Certificate. Same idea as Webcash, but proves you own something instead of holding money.
**Replace** — Swapping an old code for a new one. This is how both cash and ownership change hands. Old code dies, new code lives.
**Hash** — A one-way fingerprint. You can create a fingerprint from a code, but you can't recover the code from the fingerprint. Safe to share publicly. Also used to uniquely identify digital files.
**Bearer instrument** — Anything where "whoever holds it, owns it." Cash is a bearer instrument. So are Harmoniis Contracts and Certificates.
**Burn** — Permanently destroying a code so it can never be used again. Contracts are burned after completion. Certificates are not.
**Mint** — Creating a new Contract, Certificate, or Stablecash token. Only the Referee's Office (for Contracts and Certificates) or the Currency Exchange (for Stablecash) can do this.
**PGP signature** — Mathematical proof that a specific person or machine authored something. Cannot be forged. Your unfakeable wax seal.
**PGP encryption** — Scrambling a message so only the intended recipient can read it.
**RGB21 (UDA)** — The technical standard for unique, non-splittable digital things. Contracts and Certificates use this.
**RGB20 (NIA)** — The technical standard for fungible, splittable digital things. Stablecash uses this.
**Contract (CTR_)** — The escrow that makes a deal happen. Locks money, defines terms, gets burned when done.
**Certificate (CRT_)** — Proof of product ownership. Born from a product Contract. Includes the product's hash or serial number. Lives forever.
**Escrow** — Money held by a trusted third party until conditions are met.
**AI Validator** — The artificial intelligence agent inside the Referee's Office that reads delivered work and decides if it meets the contract terms. Powered by Grok via OpenRouter. Evaluates text only (for now). Computes late penalties automatically.
**X-Webcash-Secret** — The HTTP header where you slide your cash code under the window.
**X-Notary-Secret** — The HTTP header where you present your ownership code.
**X-Notary-Proof** — The HTTP header where you flash the fingerprint of your ownership code without revealing the code itself.
**HD wallet** — A wallet that generates unlimited unique codes from a single master key. Like a master key that can cut infinite unique copies, each for a different door.
**Demo / Sandbox** — A test environment with play money. Everything works, nothing is real. Clearly labeled.
**Tracking number** — Mandatory for physical product contracts. No tracking, no deal. This protects both buyer and seller.