Tokenization is frequently described as a transformation. Assets are “brought onchain.” Finance is “moved to the blockchain.” The language suggests a wholesale migration, as if the entire product relocates from one system to another.
That is not what happens. In many tokenized financial products, the token is a representation of something that continues to exist offchain. The underlying asset, the legal structure, the counterparty obligations, the custody arrangement, and much of the operational infrastructure remain where they were. What moves onchain is the record of ownership, and in some cases, the mechanics of transfer and settlement.
This piece is written for issuers, allocators, and operators who want a clear picture of what tokenization actually changes about a financial product and what it leaves untouched. The distinction is not academic. It determines where the real advantages are, where the new risks come from, and what a tokenized product actually requires to function.
What actually moves onchain
In a typical tokenized fund or credit product, the blockchain holds the ownership record, the transfer logic, and in some cases a price or NAV feed via an oracle. The token itself is a pointer. It says: this address holds X units of this product.
The underlying asset does not move. A tokenized treasury fund still holds treasuries in a traditional custodian. A tokenized private credit product still originates and services loans through conventional channels. A tokenized real estate product still depends on a property, a manager, and a legal entity. The blockchain does not hold the asset. It holds a claim on it.
Some products move more onchain than others. A DeFi lending protocol where loans are originated, collateralized, and settled entirely onchain is structurally different from a tokenized fund share that wraps an offchain portfolio. Both are called “tokenized,” but the amount of the product that actually lives onchain is different, and so is the risk profile.
Understanding what is onchain and what is not is the first step in evaluating any tokenized product. It determines which risks are governed by code and which are governed by contracts, courts, and counterparties.
What tokenization changes
Settlement
Traditional financial products settle through intermediaries. A fund redemption may take days or weeks to process through transfer agents, custodians, and banks. Token transfers settle onchain in seconds or minutes, depending on the network.
This is a real improvement, but it applies to the token layer, not necessarily to the underlying asset. A tokenized fund share can transfer instantly between wallets. The actual redemption of that share for the underlying asset still follows the fund’s redemption schedule. Faster token settlement does not mean faster access to the money.
Access and distribution
Tokens can be distributed through channels that traditional financial products cannot easily reach. A tokenized product on a public blockchain is accessible to any wallet that meets the product’s compliance requirements. This can reduce distribution costs and open access to investors who are underserved by traditional custody and brokerage infrastructure.
The constraint is compliance. Many tokenized financial products restrict who can hold them through allowlists, KYC gates, or transfer restrictions embedded in the smart contract. The blockchain is permissionless, but the product usually is not. Distribution is broader than traditional channels, but it is not open.
Composability
This is the most significant and least understood change. A tokenized product on a public blockchain can be integrated into other protocols. It can be used as collateral in a lending protocol, included in a liquidity pool, wrapped into a structured product, or bridged to another chain.
Composability creates distribution advantages and risk surface expansion at the same time. When a tokenized credit product is posted as collateral on a lending protocol, the issuer gains distribution (more demand for the token) but also inherits the risk dynamics of the lending protocol: liquidation mechanics, oracle dependencies, and leverage that may not have been part of the product’s original design.
Transparency and auditability
Onchain records are public and verifiable. Token balances, transfer history, and smart contract logic can be inspected by anyone. This is a meaningful improvement over traditional fund structures where ownership records, transfer activity, and fund mechanics are opaque to outside observers.
The limitation is that onchain transparency applies only to what is onchain. If the underlying portfolio, the NAV calculation, or the custody arrangement is offchain, the blockchain does not make those things more transparent. A token with a verifiable onchain transfer history and an opaque offchain portfolio is only partially transparent.
What tokenization does not change
Credit risk
If the underlying asset is a loan portfolio, the credit risk of that portfolio is unchanged by tokenization. Default rates, recovery rates, and borrower quality are properties of the underlying asset, not the wrapper. A poorly underwritten loan portfolio does not become safer because the ownership record is on a blockchain.
Legal structure and counterparty obligations
The legal relationship between the holder and the issuer is governed by the product’s legal documentation, not by the smart contract. Token rights, redemption terms, fee structures, and the holder’s claim in a liquidation scenario are defined in offering documents, subscription agreements, and fund formation materials. The smart contract may enforce some of these terms, but it does not replace them.
In a dispute, the governing law and jurisdiction specified in the legal documents determine the outcome, not the state of the blockchain. A token holder’s rights are legal rights, and they depend on the quality and enforceability of the underlying legal structure.
Operational dependencies
A tokenized product still requires fund administration, custody, valuation, compliance monitoring, and reporting. These functions are performed by service providers under contractual agreements. If the fund administrator makes an error, the custodian experiences a breach, or the valuation agent delivers a stale NAV, the impact on the product is the same whether or not the ownership record is on a blockchain.
Tokenization adds operational dependencies rather than removing them. The product now also depends on smart contract integrity, oracle reliability, bridge security (if multi-chain), and the issuance platform’s infrastructure. The operational surface area grows.
Regulatory requirements
Securities laws, fund regulations, and investor protection requirements apply to the product based on what it is, not how it is represented. A tokenized fund share is still a fund share. A tokenized note is still a note. The compliance obligations attached to issuing, distributing, and managing these products do not change because the record of ownership is on a blockchain.
The interface problem
The most consequential risks in tokenized products tend to appear at the boundary between what is onchain and what is offchain.
An oracle feeds offchain pricing data to onchain protocols. If the oracle updates weekly but the lending protocol liquidates in real time, there is a gap between the price the protocol sees and the price the asset is actually worth. That gap is not a property of the asset or of the protocol individually. It is a property of the interface between them.
A redemption mechanism connects onchain token burns to offchain fund distributions. If the token can be burned instantly but the fund processes redemptions quarterly, the holder who needs to exit between windows has only the secondary market, which may not have the depth to absorb the position at a fair price.
A compliance wrapper on a smart contract restricts who can hold the token. But if the token is used as collateral in a lending protocol, the liquidation process may need to transfer the token to a liquidator who is not on the allowlist. The compliance logic and the protocol logic may conflict.
These interface problems are specific to tokenized products. They do not exist in purely traditional products (where everything is offchain) or in purely onchain products (where everything is governed by code). They arise precisely because tokenization creates a product that spans both systems.
What is still migrating
The boundary between onchain and offchain is not fixed. NAV calculations are moving toward real-time onchain oracles. Compliance logic is being embedded in transfer restrictions at the contract level. Some products are originating loans entirely onchain, removing the offchain credit pipeline. Settlement infrastructure is being rebuilt natively on blockchains rather than bridged from traditional rails.
As more of the stack moves onchain, some of today’s interface problems will resolve. But new ones will emerge. Real-time onchain pricing removes oracle lag but introduces new attack surfaces. Fully onchain lending removes the offchain counterparty but creates smart contract risk at every layer. The question is not whether the product will be fully onchain eventually, but which parts benefit from being onchain and which parts still need offchain infrastructure, legal enforceability, or human judgment.
What this means
Tokenization offers real, specific advantages: faster settlement at the token layer, broader distribution through onchain channels, composability with other protocols, and greater transparency for the parts of the product that live onchain.
It does not eliminate credit risk, replace legal structures, reduce operational complexity, or exempt the product from regulatory requirements. In many cases, it adds a new layer of infrastructure and a new set of dependencies on top of the existing ones.
The products that are best positioned are the ones that are honest about this. They use tokenization where it creates genuine advantages and build the offchain infrastructure to support what the blockchain cannot do on its own. They do not conflate token transferability with investor liquidity, onchain settlement with underlying asset settlement, or composability with risk-free distribution.
For issuers, the practical question is: what does tokenization actually improve about this specific product, and what new requirements does it create? For allocators, the question is: which of this product’s claimed advantages are properties of the token layer, and which depend on offchain infrastructure that needs to be evaluated separately?
The distinction between what tokenization changes and what it does not is where clear thinking about these products begins.