How it works underneath, and an honest roadmap of what is built and what is not.
Each has its own page: a picture of how it works, then the questions a first-time reader asks, answered honestly.
| Level | Product | Money runs on | Today |
|---|---|---|---|
| 1 | Cinemark: unused Movie Club credits become tickets | Stripe, or stablecoins for AI agents | 🔵 Built, two testnet orders with a stand-in |
| 2 | Gift cards: in store, online, and account credit | Stripe: a hold on the shopper's card | 🔵 In store and online built, never used for real. 🟡 Account credit designed, no code |
| 3 | Cash advance: your card pays for someone's purchase, and you get cash | A stablecoin escrow, designed only | 🔵 Built as code, cannot run yet |
| 4 | Loyalty: sign up once, get the best redemptions | No money moves | 🟡 Designed, no code |
Where the money goes maps every product's money in one picture: how it comes in, where it waits, who is paid, and which steps touch Stripe.
This documentation distinguishes three states. The distinction is the point:
| Designed | Reasoned through and written down. No code. |
| Built | Implemented with green tests. Has never run against reality. |
| Proven | Has run against a real merchant, a real card, or real money. |
Very little is proven. A great deal is built. This project has mixed the two up more than once. A safeguard that passes its tests but never actually runs is worse than having none, because you can see a missing safeguard and you cannot see a dead one.
Two real examples:
ChipotleVault, the Lit vault backend, existed but was only mentioned in comments. Every code path used the custodial vault instead, and the custody guard rightly refuses a third party's card there. So even if that backend had worked, no seller could have listed a card under their own name.A static check (pnpm lint:dead) now fails the build when an exported function is reachable only from tests. That is what stops this recurring.