Primitive
The receipt token started as a solution to a specific problem in crypto fundraising. But the underlying model is general.
Within crypto, the receipt token enables:
On-chain cap tables — the token holder list is the cap table. No spreadsheet, no database, no intermediary. Any wallet with access to Base can read it.
Pre-TGE governance — receipt token holders can participate in project governance proportionally before the project token exists. Any governance protocol that reads ERC-20 balances — Snapshot, Tally, and others — can use receipt tokens natively without any integration work.
Revenue and fee distribution — founders can distribute funds proportionally to receipt token holders using any ERC-20 distribution mechanism. A holder with 5 receipt tokens receives 5% of any distribution. This enables pre-TGE revenue sharing or milestone-based payouts without additional infrastructure.
Composability — any DeFi protocol that reads ERC-20 balances can interact with receipt tokens. The fixed supply and deterministic allocation model make them predictable and composable.
Beyond crypto, the model generalizes
The receipt token is not specific to fundraising. It is a primitive for representing any proportional claim tied to a verified document. Fixed supply. On-chain. Transferable. Terms hashed and bound at creation.
Anywhere a percentage of something needs to be divided, verified, and held — the model applies. The terms document defines what is being divided. The hash proves those terms have not changed. The token proves the claim.
Capset starts with crypto presales because that is where the problem is immediate, the users are already on-chain, and the path is clearest. The primitive is designed to go further.
Receipt Token vs Traditional Cap Table
| Receipt Token | Traditional Cap Table | |
|---|---|---|
| Location | On-chain, in contributor wallets | Database or spreadsheet |
| Control | Nobody — ERC-20 standard | Platform or founder |
| Verifiable | Yes — Basescan | No |
| Transferable | Yes — standard ERC-20 transfer | Requires platform action |
| Terms tied | Yes — SHA-256 hash on-chain | No |
| Permissionless | Yes | No |
| Composable | Yes — works with any ERC-20 protocol | No |
| Over-allocation possible | No — fixed supply enforced by contract | Yes — human error risk |