Tokenized Assets and the Emergence of Programmable Portfolios

Abstract

Tokenization can place transferable asset records and operating rules in a programmable environment. A programmable portfolio, however, requires more than tokenized holdings. It also needs legally meaningful ownership, settlement money, interoperable custody, valuation, asset servicing, bounded automation, and failure governance. This narrative evidence review combines academic literature on tokenization and on-chain finance with 2026 BIS and central-bank infrastructure work. It examines tokenized funds, deposits, government securities, settlement, and collateral. The evidence supports potential reductions in reconciliation and atomic settlement risk, while remaining inconclusive about broad production cost savings and liquidity. Tokenization changes the possible portfolio operating model; it does not remove issuer, legal, market, or infrastructure risk.

Keywords: tokenized assets; programmable portfolios; tokenized deposits; tokenized Treasuries; atomic settlement; collateral mobility

Research question

How can tokenization change portfolio construction, settlement, collateral mobility, and financial automation?

Introduction

A portfolio cannot be programmed merely because its positions have token addresses. Software also needs reliable knowledge of what each token represents, who may hold it, how it settles, how income and redemptions work, and what happens when infrastructure fails.

Tokenization is best understood as a change in recordkeeping and operating architecture. It can connect ownership and execution more closely. It can also create wrappers, bridges, and administrators that separate the token from the underlying right.

Review approach

This paper uses a narrative evidence review and comparative institutional analysis. Local sources provide frameworks for on-chain assets, stablecoins, digital-asset circulation, and portfolio allocation. Current BIS and central-bank publications provide evidence about 2026 infrastructure experiments. Industry estimates are not used as independent proof of benefits.

Forms of tokenized assets

A tokenized fund may issue shares on a ledger while a manager and custodian hold the underlying portfolio. A tokenized deposit represents a bank liability. A tokenized government-security product may be a direct security, beneficial interest, or fund share. Private-credit and real-estate tokens often represent interests in legal vehicles rather than direct title.

These forms are economically distinct. The portfolio system must read legal and operational metadata, not infer rights from a token standard.

Schär’s DeFi framework distinguishes settlement, asset, protocol, application, and aggregation layers. This is useful because a token at the asset layer inherits security and governance from the layers below and depends on protocols and interfaces above.

Portfolio construction

Tokenization can make fractional positions and automated subscriptions easier, potentially widening the feasible set of holdings. It can also enable continuous constraint checking and coordinated rebalancing across compatible assets.

Portfolio theory does not disappear. Expected returns, covariance, liabilities, liquidity, and preferences still determine allocation. Ang, Morris, and Savi show how crypto allocations can be extremely sensitive to distributional assumptions and positive-skew preferences. The lesson for programmable portfolios is caution: automation can execute a model precisely while the chosen model remains unstable.

Construction should therefore expose sensitivity, concentration, and liquidity rather than treating token availability as an allocation rationale.

Settlement

Traditional settlement uses sequential messages and reconciliations across institutions. A shared ledger can coordinate ownership transfer and payment, supporting delivery-versus-payment and atomic execution.

BIS Project Agorá reported in May 2026 that a prototype using tokenized central-bank reserves and commercial-bank deposits could address some cross-border payment frictions. It will advance toward real-value testing. The evidence is promising but not proof of production scalability or lower total cost.

Settlement money is decisive. A portfolio cannot realize atomic settlement if the asset and cash legs operate under incompatible finality, hours, and legal rules.

Collateral mobility

Tokenized collateral may be identified, locked, transferred, and released more quickly. Smart contracts can connect margin conditions to settlement and reduce some manual reconciliation.

Legal priority, valuation, and default procedures remain. A fast ledger transfer does not answer whether a secured party has an enforceable interest or whether an asset remains eligible after a market or issuer event.

Collateral reuse also creates interconnectedness. Programmable movement can accelerate liquidity management and the propagation of errors. Limits and visibility across claims are necessary.

Interoperability

Technical compatibility includes token and messaging standards. Institutional compatibility includes identity, ownership, settlement finality, compliance, and governance.

Bridges often create wrapped assets and additional custody or smart-contract risk. They do not provide legal interoperability by themselves. A shared ledger can reduce fragmentation but concentrate governance. Multiple connected ledgers can provide specialization and resilience while preserving reconciliation.

The architecture should reveal which party can freeze, upgrade, reverse, or correct records and which other systems recognize that action.

Asset servicing and automation

Portfolios require dividends, interest, redemptions, voting, corporate actions, and tax records. Code can automate distributions, but it needs accurate records and funded obligations. Corrections and exceptional legal events need accountable processes.

Rule-based rebalancing can enforce concentration and liquidity limits. It should be revocable and distinguish a recommendation from execution authority. Oracles provide prices and external facts, introducing freshness and manipulation risk.

A programmable portfolio therefore contains at least four policies: eligibility, allocation, execution, and exception handling.

Risks

Issuer risk remains when the token is a promise. Custodial and insolvency risk remain when underlying assets are held off-chain. Smart-contract and upgrade risk arise in transfer logic. Oracle risk affects valuation and eligibility. Liquidity risk remains when few participants trade or redeem.

Legal-ownership risk is fundamental. SEC material notes that a tokenized security holder’s rights can differ from those of a holder of the underlying security. Portfolio systems must not collapse those claims into one label.

Privacy is another constraint. Public positions and transfers may expose strategy, counterparties, or wealth. Permissioning and privacy-enhancing proofs can reduce disclosure while introducing standards and governance dependencies.

Design implications

Maintain machine-readable provenance for issuer, claim, custodian, settlement network, redemption, and restrictions. Treat wrappers as new claims. Apply issuer and infrastructure concentration limits. Make automation policies revocable and monitorable.

Test the whole lifecycle: issuance, transfer, income, redemption, freeze, default, network outage, and correction. Faster issuance is not evidence of a better portfolio system if servicing and exit remain manual or uncertain.

Representation, ownership, and enforceability

Tokenization can record a claim in several ways. A native on-chain asset exists within the ledger's own rules. A registered security token may be the authoritative ownership record under an issuer's legal framework. A certificate or receipt token may instead point to an asset held elsewhere. Other arrangements represent a contractual entitlement against an issuer or special-purpose vehicle. These models are not economically interchangeable.

The token's code can constrain transfers, but code does not by itself establish who owns the underlying Treasury, fund unit, loan, or deposit. The legal terms must identify the issuer, holder rights, governing records, custody chain, redemption process, insolvency treatment, and conflict-resolution mechanism. If the on-chain balance and off-chain register diverge, the system must state which one prevails and how reconciliation occurs.

This distinction also limits composability. A protocol can accept a token as collateral while misunderstanding its transfer restrictions, redemption window, or seniority. Technical compatibility is not legal or economic equivalence. Portfolio systems need instrument-level data about the claim, not merely a contract address and price.

Comparative tokenization models

Tokenized deposits are claims on a commercial bank and ordinarily remain tied to that bank's balance sheet and regulatory perimeter. They may support programmable settlement while preserving a familiar issuer relationship, but interoperability across banks and access outside approved networks are open questions.

Stablecoins can provide a broadly transferable cash-like token, yet their quality depends on reserve assets, segregation, redemption access, issuer governance, and applicable law. A stable price in routine trading does not guarantee redemption during stress. Using a stablecoin as the cash leg of a portfolio imports issuer concentration and depegging risk.

Tokenized government securities represent claims on instruments whose underlying credit and market-risk characteristics are relatively familiar. The token may improve transfer or collateral workflows, but investors still depend on the issuer, registrar, custodian, distribution rules, and redemption mechanism. A token trading continuously does not make the underlying market or official register continuously available.

Tokenized funds add a portfolio and management layer. The token may represent a fund share, a record maintained by a transfer agent, or a contractual receipt. Subscription, valuation, fees, dealing cut-offs, and redemption remain fund-specific. Private-credit tokens add borrower performance, servicing, valuation, and limited transferability. Their illiquidity does not disappear when a digital representation can move between addresses.

Transfer restrictions and permissioning

Financial instruments often restrict who may hold or receive them. Rules may depend on investor category, jurisdiction, sanctions status, offering exemptions, holding periods, or concentration limits. Token contracts can enforce some allowlists and transfer checks, but the underlying credentials and policy interpretation remain external dependencies.

Permissioning can occur at the network, wallet, token, or transaction layer. Network permissioning limits participants but may fragment liquidity. Token permissioning travels with the instrument but can concentrate control in an issuer or administrator. Wallet credentials can support selective eligibility but require issuer trust, expiry, and revocation. Portfolio automation must know which layer rejected a transaction and whether an alternative execution route remains lawful.

An administrator key may freeze, seize, upgrade, or reassign tokens. Those powers can support compliance and error correction while weakening assumptions of immutable ownership. Investors need disclosure of the powers, approval process, audit trail, and recourse if they are used incorrectly.

Settlement finality and delivery versus payment

Fast token transfer is not the same as final settlement. Finality depends on the ledger's consensus, legal recognition, and any right to reverse or correct the record. A probabilistic chain may require confirmations; a permissioned ledger may provide protocol finality while leaving legal challenge available. Cross-ledger settlement adds uncertainty about whether both legs reach an equivalent final state.

Delivery versus payment links asset delivery to the cash leg so that one does not complete without the other. Atomic execution on one ledger can reduce principal risk, but many transactions involve separate ledgers, custodians, or payment systems. Hash locks, coordinators, or shared infrastructures can connect the legs, each introducing timing, availability, and governance dependencies.

Project Agorá is relevant because it investigates a multi-part institutional architecture rather than claiming that issuance alone solves settlement. Prototype results and movement toward real-value testing are evidence of institutional experimentation, not proof of production-scale benefit or legal uniformity.

Collateral mobility and liquidity fragmentation

Tokenized collateral may be identified, pledged, released, and transferred with fewer manual reconciliations. This can reduce operational delay and make intraday collateral use more feasible. The benefit depends on common valuation, haircuts, legal control, settlement access, and acceptance by counterparties. A token that one venue accepts may be unusable elsewhere.

Mobility can also accelerate risk transmission. Automated margin calls can move collateral during stress, while common liquidation rules may concentrate sales. If valuation or eligibility data are stale, a programmable process can apply the wrong haircut consistently and at scale.

Fragmented token standards and ledgers can split an instrument into pools with different settlement assets, wrappers, bridges, and compliance rules. Quoted liquidity in one pool may not be reachable by a regulated holder in another. Wrapping improves technical reach but adds custody and smart-contract risk. Aggregate portfolio monitoring must avoid double-counting an underlying asset and its wrapped claims.

Valuation, oracles, and redemption

Portfolio logic requires prices, accrued income, corporate actions, and instrument status. Public-market tokens may use exchange or benchmark prices; private credit and real estate may rely on periodic models or appraisals. Placing a stale value on-chain does not make it current. The system should record source, timestamp, methodology, and confidence or staleness threshold.

Oracles can fail through outage, manipulation, thin-market observations, or a mismatch between the reported asset and the actual legal claim. Multiple sources reduce some single-provider risk but do not cure a shared bad market. Execution should pause or reduce scope when valuation quality falls below the policy's threshold.

Redemption anchors many token values. Portfolio models need to know who can redeem, minimum size, fees, dealing window, expected delay, and what happens during suspension. A token may trade around the clock while redemption is available only on business days. The “24/7 liquidity” claim therefore confuses technical transferability with continuous depth, valuation, cash settlement, and issuer operations.

Programmable portfolio operations

Automated allocation can combine owner constraints with instrument metadata: target weights, concentration limits, permitted issuers, liquidity buffers, jurisdiction, collateral needs, and maximum execution cost. Rebalancing should act on meaningful drift rather than every price movement. It must account for restricted assets, redemption delay, taxes where known, and the availability of an eligible cash leg.

Compliance-aware execution can check a recipient credential or transfer rule before submitting. A failed check should not silently route through a less protected wrapper. The portfolio record should distinguish an economic recommendation from an executable order and retain the reason a proposed trade was rejected.

Monitoring must aggregate exposures across representations. An investor may hold a fund token backed by Treasuries, a stablecoin backed partly by similar assets, and a lending position collateralized by the same token. Looking only at contract addresses understates common issuer, custodian, duration, or oracle dependencies.

Institutional infrastructure and failure modes

Institutional use requires identity, permissions, transfer agency, custody, cash settlement, books and records, corporate actions, reporting, and dispute handling. A shared ledger may reduce reconciliation among participants, but governance determines admission, upgrades, error correction, privacy, and liability. A faster database without agreed legal and operational rules does not create a market.

Failure modes include issuer insolvency, reserve shortfall, custodian loss, administrator compromise, bridge exploitation, oracle error, settlement asset failure, redemption suspension, and inconsistent legal records. An interoperability layer can propagate rather than isolate a faulty state. Portfolio policies need limits by issuer and infrastructure dependency, not only by asset label.

Future research should measure end-to-end settlement time, reconciliation breaks, collateral reuse, liquidity across permissioned venues, redemption performance under stress, and operational loss. Studies should compare the tokenized process with the incumbent process after including governance and compliance costs. Claims of efficiency should be tested in real transactions, not inferred from ledger speed.

Comparative portfolio architecture

A portfolio can use tokens only as settlement objects while keeping allocation and compliance in conventional systems. It can place allocation logic off-chain and submit bounded orders to token networks. Or it can encode more policy on-chain, allowing transparent constraints and composable execution. Greater on-chain scope improves shared verifiability but increases exposure to public metadata, contract defects, oracle dependence, and difficult upgrades.

Institutional architectures are likely to remain hybrid because liabilities, identity evidence, accounting, and legal records span systems. The relevant question is not whether every component uses one ledger, but whether ownership, cash, permissions, valuation, and finality can be reconciled without ambiguous states. Interoperability should preserve restrictions and provenance rather than merely transport token bytes.

Policy implications and future research

Disclosure should identify the tokenization model, authoritative ownership record, redemption route, administrator powers, custody chain, settlement asset, and transfer restrictions. Regulators and operators should distinguish technical trading hours from reliable liquidity. Portfolio managers need dependency-level concentration measures covering issuers, custodians, oracles, bridges, and settlement networks.

Future pilots should publish comparable measures: failed transfers, reconciliation breaks, settlement time, collateral release, operational cost, redemption latency, and performance during stress. Evidence should include transactions that required exception handling. Without those observations, tokenization remains a credible infrastructure hypothesis rather than a demonstrated universal improvement.

Automated portfolios also need governance research. Who may change an oracle, instrument allowlist, haircut, or compliance rule? How quickly can holders exit after a change? What happens when two networks recognize conflicting states? Answering these questions is necessary before programmability can be treated as a durable portfolio capability.

Portfolio-level risk controls

Programmability allows controls to be checked before an order, but the control model must reflect economic relationships. Limits can apply by instrument, issuer, custodian, chain, oracle, settlement asset, and ultimate collateral. Without look-through data, several different tokens may pass individual limits while concentrating the portfolio in one reserve manager or infrastructure provider.

Pre-trade checks should use current eligibility, valuation quality, liquidity, and available cash. Post-trade controls should confirm final settlement, received quantity, updated exposure, and continued redemption access. A transaction that succeeded on-chain may still breach a portfolio rule because another account changed or because an off-chain position was not synchronized.

Automated rebalancing needs bounded discretion. The owner or manager can define target ranges, maximum turnover, approved venues, execution windows, price limits, and assets that require manual approval. When data are stale or markets are thin, the correct automated action may be to wait and escalate. A system that must always trade converts uncertainty into forced execution.

Stress controls should model simultaneous failures. A stablecoin depeg may reduce the cash leg while increasing collateral calls. A congested chain can raise transaction cost while delaying liquidation. An issuer freeze can make a token non-transferable even when its oracle still reports a price. Scenario analysis should therefore operate on dependencies and capabilities, not only historical return correlations.

Legal and operational barriers

Cross-border portfolios face differences in securities classification, custody, settlement finality, investor eligibility, data rules, and insolvency treatment. An interoperable technical message cannot reconcile those rules by itself. Participants need agreements governing authoritative records, liability, corrections, and disputes.

Legacy integration remains material. Accounting, risk, tax, and regulatory reporting systems may not consume token events directly. Institutions may run parallel books during transition, which can increase rather than reduce reconciliation work. Benefits should be evaluated after including exception handling, cybersecurity, key management, and staff capability.

Standard fragmentation is another barrier. Competing token interfaces may encode restrictions and corporate actions differently. Adapters can normalize data but become privileged translation layers. Open standards, conformance tests, and clear versioning reduce this risk, while governance must still decide how incompatible upgrades are handled.

Limitations

Institutional tokenization remains a mixture of prototypes and bounded deployments. This review does not estimate cost savings or compare all ledger models. Legal treatment varies. Crypto-allocation evidence is not evidence for tokenized real-world-asset performance.

Conclusion

Tokenization can make ownership records and financial rules more directly addressable by software. Its deeper value lies in coordinated settlement, servicing, collateral, and controls—not in representing an isolated asset with a token.

A programmable portfolio emerges only when the token’s legal claim, cash leg, valuation, permissions, and failure process are interoperable. Until then, tokenization expands technical possibility without guaranteeing operational or investor benefit.

References

1. Bank for International Settlements. “Project Agorá.” Updated 2026-05-27. https://www.bis.org/about/bisih/topics/fmis/agora.htm
2. Bank for International Settlements. 2026. Annual Economic Report 2026, Chapter III. https://www.bis.org/publ/arpdf/ar2026e3.htm
3. Schär, Fabian. 2021. “Decentralized Finance: On Blockchain- and Smart Contract-Based Financial Markets.” https://doi.org/10.20955/r.103.153-74
4. Ang, Andrew, Tom Morris, and Raffaele Savi. 2023. “Asset Allocation with Crypto: Application of Preferences for Positive Skewness.” Journal of Alternative Investments 25(4): 7–28. https://doi.org/10.3905/jai.2023.1.185
5. U.S. Securities and Exchange Commission. “Crypto Assets and the Federal Securities Laws.” Updated 2026-05-15.

Conflict disclosure

PraxiHub is associated with Praxifi. The author may hold roles or ownership interests in Praxifi, whose broader research interests include tokenization and portfolio automation. This paper does not evaluate a Praxifi product.

Publication history

Draft version 0.1, prepared 2026-07-30. Not peer reviewed.