Use case
Tokenised-asset register
A register of a defined claim, with a rule for who may hold it and who may transfer it. The token does not create the asset.
A firm wants a programmable record of ownership or of a unit that stands for a claim. Buyers, a transfer agent, and a regulator may all need a different view of the same event.
When shared machinery earns a place
Programmable transfer restrictions, shared verification by parties who do not share your database, or a public commitment to the register can justify a hybrid design.
When it does not
If one company is the registrar and nobody outside needs to verify the log, a conventional register is the system of record. A new chain does not create title.
Conventional-first
Register database, role-based access, signed audit log, document vault.
Outsiders trust you. You do not inherit a public chain's operational burden.
Hybrid
Off-chain register, eligibility credential, periodic hash anchor, indexer for your own UI.
Two systems to reconcile. The hash does not prove the legal title.
On-chain-native
Restricted token pattern, wallet policy, event indexer, pause and role separation.
Key loss, admin keys, and a security review become the product.
Patterns
- Conventional system of record
- Anchored registry
- Controlled transfer
- Verifiable credential
- Indexer read model
Components
- OpenZeppelin ContractsGreen — compatible use if you keep the notices
- FoundryGreen — compatible use if you keep the notices
- viemGreen — compatible use if you keep the notices
- PonderGreen — compatible use if you keep the notices
- Spruce SSIGreen — compatible use if you keep the notices
- Scaffold-ETH 2Green — compatible use if you keep the notices
Read before you build
Questions a person still has to answer
- What is the legal instrument, and is the token it?
- Who may freeze or correct a holding?
- Where do the documents live?
- Which custodian, if any, can move the asset?