Mapping a right to a token: what the decision maker looks at
When a business proposes to represent an existing right — a claim, a share, a licence, an interest in an asset — as a token, the decision maker does not assess the token. It assesses whether the right survives the mapping intact: identifiable, transferable, enforceable. That single test drives every document requested and every stage that follows.
What changes once the right is wrapped
Before mapping, the right lives in a register, a contract, or a ledger entry held by someone identifiable. After mapping, a second layer sits on top: the token, its metadata, and the rules that move it. The decision maker's job is to check that the second layer does not quietly replace the first, or create a version of the right that no court or registry would recognise.
The classification of the token itself is a separate question, decided later and by a different test. What happens when that later test produces an unexpected answer is described in A token is classified differently than expected token issuance. Mapping comes first because a wrongly mapped right cannot be rescued by a correct classification.
The stages a file goes through
| Stage | What is checked | Typical output |
|---|---|---|
| Intake | Does a document proving the right exist and name a holder? | Confirmed or file returned for completion |
| Attribute mapping | Which fields of the right have a token equivalent, and which do not? | Mapping table, gaps flagged |
| Conflict check | Is any third party already recorded as holding a competing claim? | Clear, or dispute noted |
| Memorandum | Does the written description match the actual scope of the right? | Draft for sign-off |
| Decision | Is the file complete enough to fix a date from which mapping is final? | Approved, rejected, or sent back |
What to do before you ask for a decision
- Legal team compiles the register extract or contract that evidences the right as it stands today.
- Technical lead maps each attribute of the right to a corresponding token field and lists any attribute with no equivalent.
- Compliance confirms who currently controls the right and checks for a competing claim on the same asset.
- Legal drafts a short memorandum stating precisely what the token represents, and what it does not.
- Project owner submits the memorandum and the supporting file to the decision maker as one package.
- Compliance records the decision and the date from which the mapping is treated as final.
Who decides and on what basis
The decision sits with whoever in the organisation is designated to approve digital representations of rights — usually a compliance officer or a small internal committee, not the technical team that built the mapping. The basis for approval is completeness, not ambition: a file with a named holder, a clear attribute table, and no unresolved conflict is approved faster than a file that looks sophisticated but leaves a gap unexplained.
Where the file is incomplete, the usual outcome is a request for the missing document rather than an outright refusal. A refusal is reserved for cases where the underlying right itself is disputed or cannot be evidenced at all.
If your case differs
If the right is a registered claim, such as a debt owed by a named debtor, mapping normally requires evidence of assignment or a notice given to that debtor before the token is treated as representing the claim.
If the right is unregistered, such as a beneficial interest under a private agreement, the decision maker asks for the chain of underlying contracts instead of a registry extract, because no registry exists to check against.
If a third party disputes the underlying right while the file is under review, mapping is paused. It resumes only once the dispute is resolved or the disputed portion is separated from the rest of the file.
What this page does not cover
This page does not size the asset behind the right or its transaction history; that question is answered separately in Asset report before a portfolio is bought.
Where the right in question is a debt owed by a named party in Lithuania, the counterparty check itself, and what it can and cannot confirm, is set out in Debtor in Lithuania and its limits.
If you are not yet sure which report or check applies to your file, the starting point is Build your report explained.
This page also does not fix a jurisdiction's registration requirement or the terms of the smart contract that will move the token once mapping is approved.
Verified
Reviewed: 12 February 2025. This page describes an internal decision-making procedure. No statute, regulation or article number is cited here by design, because this section of the site carries procedure only; the applicable legal basis, where one is needed, is addressed on the pages this procedure links to.
Frequently asked questions
How long does mapping a right to a token take in practice?
Most of the time sits with the intake and conflict-check stages, not with the decision itself. A file that arrives complete, with a named holder and no competing claim, moves through the remaining stages within days rather than weeks.
Which documents are needed to start?
At minimum: a document evidencing the right as it stands today, confirmation of who currently holds it, and a statement of any known third-party interest. Without the first of these, intake does not proceed.
What happens if the other side does not respond?
If confirmation from a counterparty is needed and none arrives, the file is not automatically approved. It is either held open pending a further request, or the decision maker proceeds on the documented evidence alone and records that gap in the memorandum.
Related reading
For the stage that follows once mapping is approved, see How smart contract and licence alignment tokenised rights what.
If the arrangement you are mapping already involves an outsourced function under supervisory scrutiny, the more urgent question may be different: When outsourcing is challenged by the supervisor: what to. Speak to a partner about your file before the next stage begins.