DTC Tokenization Service

One position, one economic right

DTS provides a concrete example of the control principle developed in One Economic Right, Multiple Records. The same position can have a conventional participant-account record, a Digital Omnibus Account record, an onchain representation, a registered-wallet record, and a LedgerScan record. The service's conversion sequence is designed to keep those records associated with one controlled entitlement rather than create an additive claim.

A participant's conventional book-entry entitlement is the source position. When DTC accepts a tokenization instruction, it debits the specified quantity from the participant's account and credits the corresponding quantity to the Digital Omnibus Account on DTC's centralized ledger. DTC then mints and delivers a token representing the participant's entitlement to the registered wallet.

The relevant relationship is therefore not a second issuance by the corporate issuer. It is a controlled change of representation inside DTC's stated entitlement model. The no-action letter describes the underlying securities represented by tokenized entitlements as remaining registered in the name of Cede & Co. The issuer-level recordholder does not change because a participant tokenizes an entitlement.

A useful operational comparison is:

active tokenized entitlements = related quantity in the Digital Omnibus Account

The service also separates the tokenized quantity from the participant's conventional available balance. Under the no-action-letter facts, securities credited to the Digital Omnibus Account cannot be transferred from that account through the conventional DTC ledger until the corresponding token is burned. This limits incompatible use of the same represented quantity across the two forms.

The conversion workflow

The process begins with participant eligibility, an eligible position, and an approved registered wallet. A participant submits a tokenization instruction for the stated entitlement and quantity. DTC applies the service workflow, debits the participant account, credits the related quantity to the Digital Omnibus Account, and mints the tokenized entitlement to the participant's registered wallet.

The wallet is a controlled service endpoint. DTC's request described registered wallets on approved blockchains for holding tokens corresponding to tokenized entitlements. Participant-to-participant token movement occurs between registered wallets in the stated service design. A wallet address provides the technical destination for a token. It does not replace the participant's relationship with DTC or independently establish an issuer-level registered-holder relationship.

De-tokenization reverses the controlled representation. The participant requests a return to book-entry form. DTC's described process burns the token in the registered wallet, debits the related quantity from the Digital Omnibus Account, and re-credits the participant's account. The position returns to DTC's conventional book-entry form through the service procedure rather than existing as freely available in both forms.

Registered wallets and network boundaries

Registered-wallet controls are central to the DTS model. They associate an approved blockchain address with the relevant DTC Participant and limit the service's tokenized-entitlement movement to the permitted environment. The SEC letter describes DTC as setting technology standards intended to support transfer only to registered wallets and to address specified conditions requiring reversal, including erroneous entries, lost tokens, or malfeasance.

DTCC's October 2026 launch release stated that DTS was integrated at launch with the Canton Network and DTCC's private Besu network, with additional networks anticipated later. Network availability, service eligibility, and technical standards are implementation facts rather than general qualities of tokenized securities. An institution considering the service should consult the current DTC documentation and contractual requirements.

The registered-wallet model provides an institutional control boundary. It links a token movement to a participant-approved address and supports DTC's ability to monitor the tokenized-entitlement environment. It does not make blockchain control equivalent to general legal ownership, nor does it eliminate the participant's own compliance, operations, custody, and downstream-servicing duties.

Digital Omnibus Account and Cede & Co.

The Digital Omnibus Account is a central component of the stated DTS architecture. It is maintained on DTC's centralized ledger and reflects the sum of securities represented by tokenized entitlements held in registered wallets. It is not a wallet and does not replace the issuer's master securityholder file. It supplies the controlled account-level connection between the conventional depository environment and the tokenized form.

Cede & Co. remains the issuer-level registered owner of the underlying securities in the described model. DTC's participant-level accounts and the Digital Omnibus Account sit within the indirect holding chain. The participant's tokenized entitlement is therefore different from direct registration of the participant, or of any downstream customer, on the issuer's books.

This distinction is important for corporate actions and customer servicing. The service provides a tokenized representation of the DTC-held entitlement. The participant remains responsible for the way positions are reflected in its own customer accounts and for the relevant pass-through processing under its own agreements and applicable obligations. Articles Tokenized Security Entitlement and Beneficial vs Direct Ownership provide the broader vocabulary for that relationship.

LedgerScan and the official entitlement record

DTC described LedgerScan in its no-action request as an offchain software system that scans the relevant blockchain activity, tracks token movements and registered-wallet holdings, and makes a record of tokenization entitlements. Under the facts stated in the letter, LedgerScan's record constitutes DTC's official books and records for tokenization entitlements.

This arrangement is a useful example of hybrid recordkeeping. The network records token state and transfers under its protocol. LedgerScan observes the relevant network activity and integrates it into DTC's service record. The token event and the DTC record have different roles, defined by the service architecture. The service does not rely on a general assumption that every blockchain event automatically determines every legal or operational fact.

The arrangement also supports reconciliation. DTC can compare the Digital Omnibus Account quantity, registered-wallet holdings, and LedgerScan record within the service. A participant can then connect its participant-level entitlement state with its own custody, account, and downstream operational records. This is the type of multi-record evidence path examined in Onchain vs Offchain Records.

Rights, servicing, and downstream responsibilities

DTCC's public DTS materials state that DTC-issued tokens carry the same legal rights, economic interests, and protections as the underlying securities. In the DTS context, that statement should be read through the DTC entitlement architecture. It does not convert a participant or wallet controller into the issuer-level registered owner.

DTC's service process operates at the participant level. Corporate-action payments, notices, elections, tax processing, and customer reporting may require additional steps through the participant's systems and account relationships. An institution should identify the record date, entitlement record, participant allocation, and downstream customer record that govern each event. A wallet balance alone does not establish the complete servicing path.

The same point applies to transfers. A token can move between registered wallets under the DTS service process. It does not by itself explain every bilateral trade, cash leg, margin obligation, customer allocation, or settlement treatment that a participant may manage around that movement. These functions follow the relevant agreements, service rules, and operating arrangements.

Controls, reversals, and service boundaries

The no-action letter describes conditions intended to support controlled tokenization, including registered-wallet transfer restrictions, standards for eligible networks and tokenization protocols, and the ability to address stated reversal conditions. It also describes DTC's monitoring and resilience expectations for its supporting systems. These safeguards are part of the particular DTC service model and should not be generalized to every tokenization project.

A tokenized-entitlement design needs exception procedures because technology and operations can fail. A wallet can be compromised, a token can be lost, an entry can be erroneous, a network can experience disruption, or a court or legal process can require action. DTC's stated ability to address specified reversal conditions demonstrates why finality in institutional markets is governed alongside correction authority. Article 17, Reversal Controls for Tokenized Securities, will examine that mechanism in detail.

DTS is valuable as a hybrid-market reference model because it retains established roles while adding controlled token mobility. It does not define all tokenized securities, replace issuer-sponsored models, or collapse the roles of issuer, transfer agent, depository, custodian, broker, participant, and technology provider into one system.

Devancore can map DTC-style tokenized entitlements alongside conventional depository positions, custody books, native tokenized securities, wallets, and lifecycle records. It can support cross-rail lineage, participant or account mapping, parity checks, event evidence, and exception routing across connected providers.

Devancore does not operate DTC systems, participate in DTS on behalf of clients, mint or burn DTC tokenized entitlements, act as a DTC Participant, custody assets, establish DTC's official record, or replace the responsibilities of DTC and eligible participants. Those functions remain with the service operator and the responsible firms.