ChecklistTokenisation
Tokenisation feasibility assessment: a scored checklist to use before you build
Before paying for legal opinions or smart contracts, test whether the asset is a sensible candidate at all. This checklist scores seven areas, from legal transferability and the register of record to liquidity and running costs, each with green, amber and red criteria and a rule for when to stop. It works for any asset class; the asset-specific detail lives on the digital, real-world and phygital asset pages.
On this page
Decide before you build, not after the pilot
Pilots are good at proving that a token can be minted and moved. They are poor at proving that an asset should be tokenised, because the hard questions sit in legal documents, operating models and market structure that a sandbox never touches. A desk-based assessment answers those questions first, with far less effort than a build.
This checklist assumes a shared ledger is already a reasonable fit; if that is still open, the distributed ledger hub covers when a ledger is worth it. Score each of the seven sections green, amber or red against the criteria in the table, gather the evidence listed after it, then apply the stop rules.
Seven sections, each scored green, amber or red
| Section | Green | Amber | Red (stop) |
|---|---|---|---|
| A. Rights and records | Ownership is legally transferable and a named party keeps the register of record | Transferable, but whether the register can recognise digital transfers is untested | Transfer is prohibited, or nobody can say who keeps the authoritative record |
| B. Problem fit | A specific pain, such as slow settlement or manual reconciliation, is measured today | The pain is described but not evidenced | The main reason is to have a token |
| C. Participants | Holders and intermediaries can use wallets or accept a custodian | Some participants need custodial or embedded wallets | Holders cannot or will not manage keys, and no custody route exists |
| D. Regulation | The likely classification is clear and its licences are held or obtainable | Classification differs by jurisdiction or needs counsel's opinion | The likely category needs licences no party in the structure can obtain |
| E. Liquidity realism | The case stands without secondary trading | The case needs some trading and a permitted venue is plausible | The case depends on a market that does not exist |
| F. Operations | Lifecycle events, support and key recovery have named owners | Owners exist for issuance but not for servicing events | Nobody will run reconciliation, support or recovery after launch |
| G. Economics | Build and run cost is below the incumbent process over the asset's life | Costs roughly match and the benefits are qualitative | Running cost exceeds the incumbent with no offsetting benefit |
Score the asset as it would actually be held and transferred, not an idealised version of it. The section letters are used in the stop rules.
Evidence that settles each score
Each item names the document or data behind a score. Where the evidence is missing, the section scores amber at best.
Stop rules and what each pattern of scores means
- If
Any red in section A or D.
ThenStop. Fix the legal position or choose a different asset before doing anything else.
Without transferable rights or a lawful route to issue, the token records nothing holders can rely on.
- If
A red in section B.
ThenStop and restate the problem; if no current pain survives scrutiny, do not proceed.
Programmes without a measured pain lose their sponsor at the first cost overrun.
- If
Amber in section E, and the business case depends on trading.
ThenRebuild the case around operational benefits, or treat trading as upside, and score again.
A token does not bring buyers or a permitted venue with it.
- If
Three or more ambers spread across different sections.
ThenRun a limited proof with test units and real participants before committing to issuance.
Several moderate unknowns compound, and a proof resolves them more cheaply than a launch.
- If
All green, or ambers only in sections C, F or G with owners assigned.
ThenProceed to legal structuring and a scoped build, tracking each amber as a condition.
These are execution risks that planning can resolve.
Worked example: a mid-size fund considering tokenised units
Questions and answers
What inputs does a tokenisation feasibility assessment need?
The asset's governing documents, a description of the current register and who keeps it, a map of today's process and its costs, the likely holders and intermediaries, and access to someone who can speak for legal and compliance. With those, the seven sections can be scored on evidence. Without them the assessment becomes a workshop of opinions, which is a weak basis for a funding decision.
Which assets usually fail the checklist?
Assets whose ownership cannot legally move without a paper process the token cannot replace, assets whose only argument is future liquidity, and entitlements whose holders cannot manage keys and have no custodian. Assets with very few holders and rare transfers also struggle on economics, because the ledger's costs are largely fixed while reconciliation savings grow with activity.
Can we test tokenisation without real assets?
Yes, and it is usually wise to before issuance. A proof can use test units on a test network, with real participants playing their roles: issuer, administrator, custodian and a few holders. It checks the operating model, the wallet experience and reconciliation without creating legal claims. Put the boundary in writing so nobody mistakes a test unit for an entitlement.
Who should own the assessment inside our organisation?
The business owner of the asset, not an innovation team on its own. Legal, operations, finance and technology each score their sections, but one accountable person signs off the result and any stop decision. That person will carry the programme if it proceeds, so they should be the one persuaded by the evidence.