LedgerScan & Tokenized Securities

LedgerScan in DTC's stated design

DTC's December 2025 no-action letter describes a participant-level tokenized-entitlement model. A DTC Participant may register one or more blockchain addresses as Registered Wallets. After a DTC Tokenization Instruction is accepted, DTC would debit the subject securities from the participant's account, credit the Digital Omnibus Account, and use its Factory system to mint and deliver a token representing the participant's tokenized entitlement to a Registered Wallet.

Under that design, a participant can transfer the tokenized entitlement directly to another participant's Registered Wallet. DTC stated that LedgerScan would scan the relevant blockchains to track those token movements and the wallets in which tokens are held. It would record Tokenized Entitlements according to the tokens held in each participant's Registered Wallet.

LedgerScan and the Digital Omnibus Account have separate responsibilities. LedgerScan monitors token movements and holdings and supports DTC's stated tokenized-entitlement record. The Digital Omnibus Account is an account on DTC's centralized ledger that reflects the aggregate quantity of Tokenized Entitlements held across Registered Wallets. The two records work together with the participant's account and wallet-registration framework to maintain a controlled representation of the relevant entitlement.

In the stated model, represented securities remain registered in the name of Cede & Co., DTC's nominee. LedgerScan's role does not establish a different issuer-level registered owner. It records the tokenized-entitlement relationship specified by the DTC service.

Why monitoring needs reconciliation

Monitoring becomes operationally meaningful when the observed event is compared with expected records. A token transfer should correspond to a supported contract, an eligible instrument, an active Registered Wallet, a valid participant relationship, and a permitted lifecycle state. The system should also compare the active supply and wallet holdings with the applicable control or omnibus quantity.

A difference can be expected for a limited time during a controlled workflow. A token event may be available before another provider's account update completes. A wallet rotation may be pending while a replacement address is being approved. A burn may be visible while de-tokenization waits for an account credit. These differences need a known status, documented timing tolerance, owner, and next action.

An unexplained difference needs an exception workflow. The service may need to assess an unsupported token contract, an unregistered destination, a stale authority map, a restricted wallet, an incomplete reversal, or delayed data ingestion. The relevant operations team needs enough evidence to decide whether the event is valid, pending, blocked, or requires remediation under the service rules.

Record hierarchy and authoritative scope

Institutions should define which system controls each fact. The blockchain can be the authoritative source for an event under its protocol. A wallet registry can control whether an address is approved for a programme. An account system can control a participant allocation. A depository, custodian, transfer agent, or issuer register can control other aspects of ownership, entitlement, or servicing.

The hierarchy prevents an observed event from being given a meaning it does not carry. A token balance may show the quantity associated with an address on a network. It does not necessarily prove the legal owner, the beneficial owner, the party authorised to instruct a corporate action, or whether the position remains eligible for transfer. Those questions are answered by the governing financial and legal records for the specific arrangement.

DTC's stated treatment of LedgerScan is especially instructive because it assigns the system a defined recordkeeping role for Tokenized Entitlements. That does not make LedgerScan a universal legal-title system or replace DTC's other records. It shows that an institutional service can designate an offchain monitoring and interpretation layer as authoritative for a tightly defined operational fact.

Resilience and controlled interfaces

DTC described LedgerScan as an offchain system residing in a public cloud. In the submitted service design, DTC stated that LedgerScan and Factory would receive a Tier 2 or better internal rating. The description included operation from primary and secondary locations, a maximum four-hour recovery-time objective, no more than two minutes of data loss from an outage, and annual out-of-region disaster-recovery and resumption testing.

Those are DTC's described internal specifications for the stated service, not universal requirements or guarantees for every tokenization programme. They illustrate the operational questions an institution should address: data continuity, recovery, integrity, monitoring coverage, alerting, exception ownership, and the ability to explain a position after an outage.

DTC also described limited write interactions between the new tokenization systems and its existing centralized systems. In the stated model, those interactions were limited to delivery of subject securities to or from the Digital Omnibus Account and cash payments from corporate-action events; other touch points were read-only. The separation helps constrain how an observed or processed token event can affect established account systems.

Monitoring is not a substitute for control design

A monitoring layer can identify an event, reconcile positions, and raise an exception. It does not replace wallet approval, account authority, custody, instrument eligibility, contractual restrictions, sanctions controls, transfer-agent functions, corporate-action processing, or legal review. Each control needs a responsible provider and a documented record source.

It also does not remove the need for data governance. Institutions need to define the source of each field, the timing and quality expectations, the treatment of corrections, the retention of historical mappings, and access controls for sensitive participant data. Token activity can be visible at the network level while the associated account, identity, and entitlement data must remain governed under separate permissions.

Articles Onchain Records vs Offchain Records, Authoritative Record for Tokenized Securities, and One Economic Right, Multiple Records provide the wider recordkeeping framework. DTC Digital Omnibus Account and Registered Wallet for Tokenized Securities explain the linked DTC concepts.

Devancore can connect authorised provider data, account positions, custody relationships, instrument records, token and wallet events, restrictions, and settlement evidence into one operating view. It can compare expected and observed states, surface discrepancies, and route cross-rail exceptions to the responsible operations teams.

Devancore does not operate LedgerScan, determine DTC's official books and records, replace an issuer or transfer-agent register, run blockchain nodes for DTC, or establish legal ownership from a token event. Those functions remain with the responsible service operators and governing records.