Mapping a right to a token: stages and deadlines
Mapping a right to a token means matching an existing right — a claim, a licence, a share in a reserve — to the identifier that will represent it on a ledger. There is no single statutory clock for this process. Before committing resources, it helps to see Ordering a report in practice, since the report you commission often sets the pace for the stages below. Sequencing, verification and the point beyond which the mapping cannot be undone are set by the parties, the registrar involved and the platform, not by a fixed deadline.
The short answer: mapping runs through four stages — verification of the underlying right, drafting of the token specification, confirmation by the counterparty or registrar, and execution on the ledger. Depending on complexity, this takes from a few weeks to several months. The binding constraint is document readiness and third-party response, not a court or regulator timetable.
What changes once mapping starts
Before the token is minted, correcting an error in the specification is straightforward. You amend the draft, re-send it for confirmation, and nothing on the ledger has to be undone. Once the token exists, the position is different. A ledger entry is, by design, hard to reverse. Any correction after that point usually means creating a new entry and formally retiring the old one, not editing it.
This is the point of no return referred to throughout this page. It falls at execution, not at drafting. Treat the confirmation stage as the last checkpoint where mistakes are cheap.
Practically, this changes how much time you should spend at each stage. Verification and specification can be slow and iterative without cost. Execution should be fast, deliberate and preceded by a final sign-off from everyone whose rights the token will represent.
What to do
- Instruct the rights holder's counsel to assemble the underlying documentation — the title, the licence, or the reserve agreement — before any token specification is drafted.
- Have the technical team draft a specification that mirrors the scope of the right exactly, neither wider nor narrower.
- Send the specification to the counterparty or registrar and require written confirmation before code is written.
- Ask the platform operator for a written statement of what execution will and will not change on the underlying register.
- Hold the execution step until every party named in the underlying right has confirmed the specification in writing.
- Update the original register promptly after execution so the two records do not drift apart.
Who decides
Three actors typically hold the decision at different stages. The rights holder and counsel decide whether the underlying right is ready to be represented at all. The registrar or counterparty decides whether the specification correctly reflects that right. The platform operator decides the technical timing of execution, once both earlier confirmations are in place.
None of these actors is bound by a fixed statutory deadline for this procedure. Timing is contractual and operational. If a dispute arises about whether the mapping was correct, it is resolved through the forum named in the underlying agreement — typically arbitration or the courts agreed by the parties, not a specialist tribunal set up for tokenised rights.
Where the stages branch
If the underlying right is a straightforward bilateral claim, verification is short and confirmation usually comes back within days. If the right sits inside a reserve managed by someone other than the rights holder, the sequence lengthens: see Reserve assets are held by a third party token for how that decision point is handled and who has to sign off before execution.
If the counterparty is unresponsive at the confirmation stage, do not proceed to execution on the strength of silence. Escalate through the notice mechanism in the underlying agreement first. Executing without confirmation removes the correction option described above, and it removes it for both sides.
If the right itself is disputed — ownership, scope, or existence — mapping should not begin until that dispute is resolved. A token cannot fix an unclear underlying right; it only fixes the representation of whatever right existed at the moment of execution.
| Stage | What happens | Typical actor | Common cause of delay |
|---|---|---|---|
| Verification | The underlying right is checked against its original register or contract | Rights holder's counsel | Missing or outdated title documents |
| Specification | The token's scope, transfer restrictions and metadata are drafted to mirror the right | Technical drafting team | Mismatch between legal scope and technical fields |
| Confirmation | Counterparty or registrar confirms the mapping before any code is deployed | Registrar or counterparty | Slow or absent third-party response |
| Execution | The token is minted or the ledger entry is created | Platform operator | Rarely delayed once confirmed |
| Reconciliation | The original register is updated to reference the token | Registrar | Registers not built to hold token cross-references |
What this page does not cover
This page describes the sequence and the decision points. It does not value the underlying asset, and it does not tell you whether the asset is worth mapping in the first place. Before committing to a portfolio that includes assets destined for tokenisation, Asset report before a portfolio is bought covers what it costs to get that valuation wrong.
It also does not cover what happens if the rights holder or the counterparty is already showing signs of financial distress before mapping begins. That question changes the priority of steps above, and it is addressed separately in Debtor report when insolvency signals appear.
Verified
This page describes a procedural sequence, not a statutory one. It does not cite specific statutory provisions, because no single article or regulation fixes the timing described above; the sequence follows standard registrar and platform practice as observed across mapping exercises. Reviewed for accuracy of the procedural description on 3 March 2025.
Related reading
Once the specification stage is complete, the next document usually needed is the smart contract itself. How smart contract and licence alignment tokenised rights runs covers that stage in the same level of detail as this page covers verification and confirmation.
FAQ
How long does mapping a right to a token take in practice?
Most straightforward cases complete verification and specification within two to four weeks. Confirmation adds further time if the counterparty is slow to respond. Execution itself is usually a matter of hours once confirmation is in hand. Complex reserves or disputed rights extend the whole sequence to several months.
Which documents are needed to start?
You need the instrument evidencing the underlying right — a contract, a licence, or a reserve agreement — plus any prior register entry for that right. Without both, verification cannot begin, and the specification stage has nothing accurate to mirror.
What happens if the other side does not respond?
Do not treat silence as confirmation. Use the notice mechanism set out in the underlying agreement to escalate first. If the agreement is silent on escalation, put the request in writing with a stated deadline before considering any further step, including execution.