Tokenization Instruction

Authority and destination validation

The party submitting an instruction must have authority over the source account or entitlement. That authority may arise from an account mandate, custody agreement, institutional signatory arrangement, or service-specific participant role. It is separate from control of a destination wallet. A firm can authorise one person to submit conversion instructions and another provider to control the wallet where a resulting tokenized entitlement is held.

The destination requires its own validation. The programme may require an approved wallet address, a mapped legal entity or account, an accepted network, a supported token contract, and an active restriction or eligibility status. A destination that is technically valid on a network can still be unsuitable for the relevant security or entitlement arrangement.

Restriction checks should be explicit. They can include the source position's availability, contractual transfer limits, holding periods, account status, jurisdiction, sanctions and screening status, investor qualifications where applicable, and the service's own supported-asset rules. A failed check should result in a recorded rejection or review state, not an ambiguous partial conversion.

Instruction lifecycle

A mature process distinguishes request states. A draft has not yet affected the source position. A request under validation may have no hold or a controlled temporary hold, depending on the provider's policy. Once accepted, the source quantity is reserved or debited so it cannot be used in an incompatible workflow. Delivery remains pending until the applicable allocation, token, and record updates are confirmed.

These states reduce operational ambiguity. A position marked reserved should not appear as freely available for conventional settlement. A delivery-pending state should not be counted as a completed tokenized entitlement. A rejected request should release any temporary hold under the governing process. Every transition needs a timestamp, owner, evidence reference, and defined next action.

What the instruction does not determine

An instruction activates a defined operational process. It does not independently set the security's terms, cure a defective source position, or decide every legal question associated with the holder. The issuer and its governing documents determine the security's rights. The transfer agent, depository, custodian, or intermediary maintains the records assigned to its role. The instruction should be evaluated against those arrangements rather than treated as a substitute for them.

The same restraint applies to compliance controls. A successful automated check can confirm that the available data satisfied a defined policy at the time of processing. It cannot guarantee that data is complete, that external facts will not change, or that every later transfer will remain permitted. Institutions need processes for changed eligibility, wallet rotation, sanctions updates, corporate actions, disputes, and legal notices after an instruction has completed.

This boundary is useful in system design. It keeps the conversion workflow focused on its real task: preserving a controlled link among the source position, approved authority, destination representation, and resulting records. Other systems may contribute evidence and controls, but their roles should remain explicit.

DTC's tokenization instruction model

DTC's December 2025 no-action letter provides a specific institutional example. It describes a DTC Participant that holds eligible book-entry entitlements in its DTC account and instructs DTC to tokenize a stated quantity. The participant must use one or more DTC-registered wallets on an approved blockchain for holding the resulting tokenized entitlements.

Upon acceptance of the instruction, DTC debits the subject securities from the participant's account and credits them to the Digital Omnibus Account. DTC then uses its Factory system to mint and deliver a token representing the participant's tokenized entitlement to the registered wallet. The underlying securities remain registered in Cede & Co.'s name. LedgerScan records the tokenization entitlements for DTC's stated books-and-records purpose.

This example shows why the instruction is a lifecycle control rather than simply a mint command. It identifies a DTC source entitlement, causes the source debit and omnibus allocation, directs a controlled token delivery, and establishes the chain of evidence needed to avoid duplicate availability. The facts are specific to DTC's service and should not be treated as a universal tokenization protocol.

De-tokenization and controlled return

A de-tokenization instruction begins the return path. It identifies the tokenized entitlement to be surrendered and the conventional account that will receive the restored book-entry entitlement. Under DTC's described process, the token is burned, the related omnibus quantity is debited, and the participant's conventional account is re-credited.

The same control questions apply in reverse: who can submit the instruction, whether the token is available and valid for return, whether the account remains eligible, and whether all related records update in the designated sequence. A burn event alone does not provide all of the evidence needed to treat the conventional position as available. The responsible service must complete and record the return workflow.

Conversion evidence and reconciliation

A complete instruction record should preserve the request identifier, source account, instrument and quantity, submitting authority, restriction result, destination mapping, acceptance or rejection decision, source debit or reserve, allocation reference, token and network reference, provider confirmation, and reconciliation outcome. This lets operations trace a position from conventional form into tokenized form and back again.

Reconciliation compares the expected lifecycle state with each relevant record. For an entitlement conversion, the team may compare the source debit, controlled allocation, token supply, wallet holding, and designated entitlement record. A difference can be expected while a request is pending, but it requires a status, owner, and aging rule. Unexplained differences need containment and an authorised correction path.

The instruction also provides the audit boundary for downstream workflows. Corporate actions, transfers, servicing, restrictions, and customer allocations should be able to identify whether a position was tokenized, when conversion occurred, what quantity was affected, and which record governs its current state. This supports the broader One Economic Right, Multiple Records discipline.

Devancore can coordinate the workflow around a tokenization instruction by connecting source accounts, instrument data, restriction evidence, destination approval, conversion state, provider confirmations, and reconciliation records across rails. It can make pending, rejected, active, and exception states visible to the responsible operations teams.

Devancore does not accept DTC tokenization instructions, approve DTC eligibility, debit DTC accounts, mint DTC tokens, custody assets, or establish DTC's official service record. Those functions remain with the service operator and authorised participants.