Skip to Content

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 TokenTraditional Cap Table
LocationOn-chain, in contributor walletsDatabase or spreadsheet
ControlNobody — ERC-20 standardPlatform or founder
VerifiableYes — BasescanNo
TransferableYes — standard ERC-20 transferRequires platform action
Terms tiedYes — SHA-256 hash on-chainNo
PermissionlessYesNo
ComposableYes — works with any ERC-20 protocolNo
Over-allocation possibleNo — fixed supply enforced by contractYes — human error risk
Last updated on