Onchain vs Offchain Records

What onchain records contribute

Onchain records can provide a sequenced history of transactions within a network, current contract state, token supply, address balances, cryptographic signatures, and time-related event evidence. Smart contracts can also apply programmed rules to a transfer, such as a requirement that the receiving address appears on an approved list.

These capabilities are useful only within their stated scope. A balance describes the state recognized by a particular contract and network. A signature proves that a credential authorized a transaction under the protocol. A timestamp records a network event. Whether the address belongs to a permitted person, whether that person is authorised for a customer account, and whether the transfer produces a completed securities event depend on linked evidence and the defined workflow.

Network design affects the reliability and accessibility of onchain information. Public and permissioned networks differ in participation, visibility, governance, finality mechanics, resilience, and methods for handling disruption. The phrase “onchain” does not establish a uniform privacy model or a uniform level of finality.

What offchain records contribute

Offchain systems carry much of the information needed to operate a securities relationship. They can connect a wallet to a verified legal entity, account, authorised signer, tax profile, jurisdiction, eligibility record, and servicing preference. They can also preserve custody and depository references, agreement terms, instruction approvals, compliance decisions, cash-leg evidence, general-ledger postings, and exception history.

These records are necessary for routine events as well as exceptions. A distribution may require tax withholding and payment instructions. A proxy or election may require a validated holder and record-date process. A transfer may require a restriction review, sanctions screen, or proof of account authority. A court order, estate event, lost key, or compromised wallet may require the institution to identify the holder and apply a documented remediation process.

The SEC Division of Trading and Markets has described a possible split architecture for a transfer agent: transaction data such as wallet address, asset balance, ownership percentage, purchase date, and transaction identifier can be maintained on a blockchain, while securityholder name, investor ID, address, tax ID, and other non-public information remain in proprietary systems. The staff view is conditional on compliance with applicable requirements and does not prescribe a single technical design.

Four dual-rail patterns

The first pattern uses onchain evidence with an offchain master file. A token movement can initiate or evidence an instruction, while the transfer agent or another responsible party validates the event and posts the resulting change to the controlling offchain record. The ledger event is important, but the operating model identifies the posting as the point at which the relevant record changes.

The second pattern uses linked components of a master file. Transaction and position data can be maintained onchain, while sensitive identity and contact data remains offchain. The components need stable identifiers, record-production capability, and procedures that ensure the combined arrangement remains accurate, current, and accessible to authorised users.

The third pattern is a ledger-primary record. Here, distributed ledger technology serves as the official master securityholder file or a component of it. SEC staff has said a registered transfer agent may use DLT in this way if applicable federal requirements are met. The technology choice does not remove the need for accurate records, supervision, retention, examination access, and the ability to handle corrections and servicing.

The fourth pattern is an intermediated tokenized-entitlement model. An underlying security or entitlement remains within a depository or custody chain while a tokenized representation moves between approved wallets. DTC's Tokenization Service is a current, specific example: its public materials describe tokenized entitlements backed by securities in a Digital Omnibus Account, with LedgerScan recording token movements and locations offchain while scanning the relevant blockchains.

The governed link between records

A durable dual-rail design begins with identifiers. The institution should be able to link the underlying instrument, its class and quantity, the token contract or programme, the wallet, the account, the legal entity, the provider, and each relevant lifecycle event. The mapping must remain valid through transfers, wallet rotation, corporate actions, conversions, restrictions, and instrument changes.

A useful operational relationship is:

underlying eligible or allocated position = outstanding represented quantity

This is a reconciliation objective, not a legal assumption. In an entitlement model, the firm may compare the relevant underlying allocation, intermediary record, and outstanding tokenized entitlement. In a direct-issuance model, the relevant comparison may be among the master file, linked ledger state, control book, and internal records. The appropriate comparison follows the product structure.

Lifecycle states also need translation across rails. An onchain event may be confirmed while the offchain workflow remains pending review. A conversion may be requested but not completed until risk, eligibility, and custody conditions are satisfied. A token may be retired while the conventional position has not yet been re-credited. These are not errors if the status is explicit and controlled; they become risks when systems show incompatible final states without an owner or resolution path.

Privacy, confidentiality, and access

A wallet address can be pseudonymous, but it is not necessarily anonymous in an institutional arrangement. Transaction patterns, address associations, or offchain mapping data can make it sensitive. Institutions need to assess what data is visible to network participants, infrastructure providers, counterparties, or the public, and how that information can be linked to persons, positions, or strategies.

Personal and confidential data also has a lifecycle. Holder identity, tax status, contact information, compliance records, and account authority may need correction, retention, controlled access, production for examination, or deletion where law and policy require. Architecture choices should support those duties rather than attempt to place every item of business data permanently into a shared ledger.

Permissioned access can reduce the population able to participate in or observe a network. It does not eliminate governance work. Institutions still need policies for node operators, access changes, data use, incident response, auditability, and regulatory access. A permissioned network is one control environment among several, not a substitute for the broader recordkeeping and privacy design.

Operational breaks across the boundary

Dual-rail operations need exception procedures because the rails can disagree for legitimate and problematic reasons. A message may fail to ingest. An allowlist may be stale. A token supply may not match the related allocation. A corporate-action snapshot may differ from the source designated by the event terms. A network incident may change how the institution treats a transaction history.

The response starts by identifying the fact in dispute. The team then determines the controlling record and preserves evidence from both rails. Where appropriate, it contains the affected workflow, such as restricting further movement, holding a conversion, or excluding a position from a corporate-action run until the break is resolved. The responsible party applies the correction permitted by the arrangement, updates linked records, and retains the resolution evidence.

DTC's no-action letter demonstrates the importance of explicit administration in a particular model. It describes LedgerScan as an offchain system that scans blockchain activity and serves as DTC's official books and records for tokenization entitlements. It also describes registered-wallet controls, conversion processes, reconciliation with the Digital Omnibus Account, and conditions permitting DTC to address certain erroneous entries, lost tokens, or malfeasance. These are facts of the stated DTC arrangement, not universal features of tokenized securities.

Designing for evidence, not duplication

Institutions do not need to duplicate all data across every system. They need enough linkage to demonstrate the meaning of an event, trace the affected right and account, determine the record that governs, and reconcile positions and lifecycle states. Excess replication can create privacy, security, and inconsistency risks. Insufficient linkage can make a technically valid transaction impossible to service or explain.

The practical design question is therefore selective synchronization: which facts must travel between rails, what proves the relationship, who approves a change, how quickly must each record update, and what happens when they do not. Those decisions turn an onchain representation and offchain operations into one manageable institutional workflow.