## Annexes 3.1–3.3: Price Discovery, Tokenization Risk Framework, and Operational Risks ## Source details **Canonical URL:** [Annexes 3.1–3.3: Price Discovery, Tokenization Risk Framework, and Operational Risks](https://www.imf.org/-/media/files/publications/gfsr/2026/october/english/ch3annex.pdf) ## Other formats - [Markdown version](/-/media/files/publications/gfsr/2026/october/english/ch3annex.pdf.md) - [Structured JSON version](/-/media/files/publications/gfsr/2026/october/english/ch3annex.pdf.json) --- ### Price Discovery in Tokenized Equities (Annex 3.1) - Data construction and sample - Firm-day observations for "5 traditional equities and their tokenized equivalents". - Data sources: 5-min windows from Bloomberg for traditional stocks and Allium for tokenized stocks, filtering for centralized exchanges. - For each tokenized–traditional equity pair i and trading day d, construct log prices: - p_{i,d,c-1}^E = log(traditional equity close on day d−1) - p_{i,d,c-1}^T = log(tokenized equity close on day d−1) - p_{i,d,−1}^T = log(tokenized equity price immediately before the open on day d) - p_{i,d,h}^E = log(traditional equity price h minutes after the open on day d), where h ∈ {0,5} - Pre-open tokenized signal: - S_{i,d}^T = p_{i,d,−1}^T − p_{i,d,c-1}^T - Traditional equity cumulative opening return: - R_{i,d}^E(h) = p_{i,d,h}^E − p_{i,d,c-1}^E - Core prediction: - R_{i,d}^E(h) should increase with S_{i,d}^T. - Main regression and hypotheses - Panel regression for each horizon h: - R_{i,d}^E(h) = α_i + τ_d + β_h S_{i,d}^T + ε_{i,d,h} - α_i are pair fixed effects; τ_d are date fixed effects. - Coefficient of interest: β_h. - Hypotheses: - H0: β_h = 0 - HA: β_h > 0 - Stronger one-for-one incorporation hypothesis: - H0: β_5 = 1 - Interpretation example: - A result such as β_5 = 0.80 implies that 80 percent of the overnight tokenized signal is reflected in the traditional equity price within five minutes of the regular market open. ### A Framework for Assessing Financial Stability Risks from Tokenization (Annex 3.2) - Framework organization - Two dimensions: - Structural features and design choices across five broad layers: core technological features; issuance; trading; settlement and clearing; cross-cycle financial functions such as collateral management. - Financial stability risk categories: (i) traditional financial vulnerabilities (liquidity stress and fire sales; contagion and interconnectedness; leverage and procyclical deleveraging) and (ii) operational, governance, market-structure, and infrastructure risks. - The framework maps features to primary (direct) risk channels (solid circles), secondary (amplification) channels (hollow circles), and mitigating mechanisms (triangles). - Assignments relied on staff judgment informed by literature review, outreach, analysis of use cases, and generative artificial intelligence tools as research support; final classifications determined by staff. - High-level risk categories (Annex Table 3.2.1 descriptions preserved) - Liquidity — "Liquidity, Runs, and Fire Sales Risk": - Risk that investors rapidly redeem, withdraw, or sell assets, triggering liquidity strains, forced asset sales, price dislocations, and adverse feedback loops. - Includes stablecoin runs, redemption pressures, liquidity mismatches, fire sales of reserve assets, liquidity spirals, and liquidity risk from fragmented structures. - Interconnectedness — "Interconnectedness & Contagion Risk": - Risk that shocks propagate across institutions, markets, infrastructures, or networks. - Includes TradFi–ToFi linkages, cross-market spillovers, collateral linkages, counterparty exposures, interconnected protocols, and contagion through composability and common asset holdings. - Leverage — "Leverage & Procyclical Deleveraging Risk": - Risk that leverage amplifies shocks and leads to forced deleveraging. - Includes collateral reuse, rehypothecation, margin calls, liquidations, collateral valuation shocks, collateral velocity, and leverage embedded in protocol interactions. - Operational — "Operational, Technology & Governance Risk": - Risk arising from failures of technology, operational processes, or governance arrangements. - Includes smart-contract vulnerabilities, coding errors, cyber incidents, oracle failures, operational outages, governance failures, fraud, and human or process failures. - Infrastructure — "Infrastructure & Market Risk": - Risk arising from the organization and functioning of tokenized markets and infrastructures. - Includes network fragmentation, interoperability failures, concentration in validators, custodians, cloud providers, oracle providers or tokenization platforms, settlement bottlenecks, and dependencies on critical market infrastructures. - Feature-to-risk mapping highlights (Annex Table 3.2.2 excerpts and rationale) - Core features - C1 DLT-based recordkeeping and transfer: ○ ▲ ● - DLT record-keeping produces high dependence on a shared market infrastructure and validator/network architecture (amplifies operational risk); can reduce operational risk by providing a shared and synchronized record of ownership and transactions. - C2 Programmability: ○ ○ ● ▲ - Automated code execution can create coding, governance, or execution failures (operational risk) and can amplify contagion and deleveraging; well-designed smart contracts can reduce operational risk by reducing processing errors and legal ambiguity. - C3 Composability: ● ○ ○ ▲ - Protocol linkages create direct contagion channels and can amplify leverage and collateral reuse; can reduce operational risk by lowering coordination frictions. - C4 Atomicity: ○ ▲ ● - Coordinated execution creates technology and settlement-execution dependencies (operational risk) and can amplify liquidity pressures; near-instant settlement can reduce contagion risk by lowering counterparty exposures. - Issuance design attributes - I1 Nature of claim: - direct claim on underlying asset (● ○ ▲) — direct exposure can trigger redemption runs and fire sales; reduces contagion by removing intermediary channels. - claim on issuer-intermediary (○ ●) — intermediated claims create dependency on the intermediary and can trigger redemption runs. - I2 On/Off-chain dependence: - "Relies on off-chain assets or processes" (● ○ ▲) and "Fully on-chain" (○ ▲ ●) — off-chain links can transmit shocks between tokenized and traditional markets; fully on-chain concentrates dependencies on DLT network resilience but can reduce reconciliation needs. - I3 Access model: - Permissionless (● ○ ▲) vs Permissioned (○ ▲ ●) — permissionless increases cyber, governance, and operational vulnerabilities; permissioned concentrates control and can fragment liquidity. - I4 Governance structure: - Decentralized governance (● ○) vs Centralized governance (○ ▲ ●) — decentralized complicates coordination and accountability; centralized creates concentration risk but can enable rapid incident response. - I5 Oracle dependence: - Yes (○ ●) — external data-feed failures or manipulation can create operational risk and transmit shocks. - Trading structure attributes - T1 Trading venue concentration: - Single dominant venue (▲ ○ ●) vs Multiple venues (○ ● ▲) — concentration creates single points of failure but may support market depth; multiple venues increase operational complexity and fragmentation risk. - T2 Interoperability: - Interoperable networks (▲ ● ○) vs Siloed network (○ ▲ ●) — interoperability creates contagion channels but can reduce liquidity frictions; silos fragment liquidity and can amplify strains. - T3 Trading hours: - Continuous (24/7) (○ ▲ ○) — continuous trading can accelerate runs, margin calls, and liquidations; continuous access can reduce liquidity risk by allowing rebalancing as shocks occur. - T4 Investor access: - Institutional only (no direct risk channel) vs Retail accessible (○ ○) — retail access can amplify liquidity and contagion risks through synchronized behavior. - Settlement and clearing attributes - S1 Settlement finality: - On-chain finality (○ ○ ▲) vs Reliance on legal or off-chain finality (▲ ●) — on-chain finality can increase interconnectedness and operational reliance on DLT; legal/off-chain finality creates operational and legal uncertainty but may benefit from established default-management frameworks. - S2 Clearing structure: - Bilateral clearing/settlement (○ ● ▲) vs Central clearing (○ ▲ ●) — bilateral exposures increase counterparty risk; central clearing concentrates functions and may generate liquidity demands but can reduce gross funding needs via netting. - Financial functions (cross-cycle) - F1 Collateral mobility and reuse: ▲ ○ ● - Tokenization increases collateral portability and reuse (supports leverage and complex collateral chains) and can transmit shocks across platforms; higher mobility can reduce liquidity risk in normal times. - F2 Programmable collateral and margining: ○ ▲ ● - Programmable rules can automate margin calls and liquidations (procyclical deleveraging risk) but can also improve collateral allocation and reduce funding needs. - Methodological and presentation notes - The matrix separates where risks originate from how they spread (primary vs secondary channels). - Mitigating mechanisms are linked to a single primary mitigation channel per feature to preserve interpretability. - Framework reorganized into three dimensions for presentation: risk creation, risk amplification, and risk mitigation; streamlined version reported in the chapter (Table 3.1). ### Examples of Specific Operational and Infrastructure Risks (Annex 3.3) - Operational and cyber risk category definitions (Annex Table 3.3.1) - Smart-Contract Failure — "Coding Bugs, logic failures, exploits, upgrade errors (many smart contracts can be modified through governance processes), admin-key misuse." - Example: a tokenized real estate contract allows investors to trade tokens after a property sale, resulting in confusion over who is entitled to sale proceeds. - Coding bugs can freeze or destroy assets instantly. ### Oracle Manipulation (Section 2) - Definition and channels - The risk that the external data feeding a smart contract is deliberately altered, corrupted, or spoofed, causing the smart contract to execute incorrect actions. - It can entail: i) price feed manipulation; ii) data source corruption; iii) oracle operator attack; iv) timing manipulation. - Oracle manipulation risk is essentially valuation manipulation risk translated into code. - Because smart contracts automatically act on oracle data, an incorrect or manipulated valuation can immediately affect trading, lending, collateral management, and investor payouts across the entire tokenized ecosystem. ### Infrastructure Risks (Section 2) - Bridge / Interoperability Failure - Risk that the infrastructure connecting different blockchains, tokenization platforms, or settlement systems fails, causing assets, cash, or information to become stuck, lost, duplicated, or transactions unable to settle. - Example: asset lock-up risk when assets become inaccessible during transfer. - If the bridge incorrectly records ownership, the same asset now appears to exist twice and can lead to disputes, overstatement of collateral, etc. - Recordkeeping Fragmentation - On-chain vs off-chain ledgers diverge, and ownership, transaction, and asset information becomes scattered across multiple blockchains, tokenization platforms, custodians, registrars, and traditional databases, making it difficult to establish a single, authoritative record of ownership and activity. ### Cryptographic Risks (Section 2) - Cryptographic risk related to keys, wallets - Owners lose access to, or unauthorized parties gain control over, the cryptographic credentials that establish ownership of tokenized assets. - Unlike traditional securities, where ownership can often be restored through a broker or registrar, loss or theft of cryptographic keys may result in immediate and potentially irreversible loss of control over the asset. - Assets continue to exist, but the investor may be unable to prove or exercise ownership rights. - Cryptographic risk related to quantum computing - Risk that advances in computing, particularly quantum computing, could break the cryptographic algorithms that protect tokenized assets, wallets, digital signatures, and blockchain networks (see Wu 2005). *Source: International Monetary Fund, Global Financial Stability Report, Chapter 3 Annexes 3.1–3.3, October 2026.* ### Section 1 ### Annexes 3.1–3.3: Price Discovery, Tokenization Risk Framework, and Operational Risks ### Price Discovery in Tokenized Equities (Annex 3.1) - Data construction and sample - Firm-day observations for "5 traditional equities and their tokenized equivalents". - Data sources: 5-min windows from Bloomberg for traditional stocks and Allium for tokenized stocks, filtering for centralized exchanges. - For each tokenized–traditional equity pair i and trading day d, construct log prices: - p_{i,d,c-1}^E = log(traditional equity close on day d−1) - p_{i,d,c-1}^T = log(tokenized equity close on day d−1) - p_{i,d,−1}^T = log(tokenized equity price immediately before the open on day d) - p_{i,d,h}^E = log(traditional equity price h minutes after the open on day d), where h ∈ {0,5} - Pre-open tokenized signal: - S_{i,d}^T = p_{i,d,−1}^T − p_{i,d,c-1}^T - Traditional equity cumulative opening return: - R_{i,d}^E(h) = p_{i,d,h}^E − p_{i,d,c-1}^E - Core prediction: R_{i,d}^E(h) should increase with S_{i,d}^T. - Main regression and hypotheses - Panel regression for each horizon h: - R_{i,d}^E(h) = α_i + τ_d + β_h S_{i,d}^T + ε_{i,d,h} - α_i are pair fixed effects; τ_d are date fixed effects. - Coefficient of interest: β_h. - Hypotheses: - H0: β_h = 0 - HA: β_h > 0 - Stronger one-for-one incorporation hypothesis: - H0: β_5 = 1 - Interpretation example: - A result such as β_5 = 0.80 implies that 80 percent of the overnight tokenized signal is reflected in the traditional equity price within five minutes of the regular market open. ### A Framework for Assessing Financial Stability Risks from Tokenization (Annex 3.2) - Framework organization - Two dimensions: - Structural features and design choices across five broad layers (core technological features; issuance; trading; settlement and clearing; cross-cycle financial functions such as collateral management). - Financial stability risk categories: (i) traditional financial vulnerabilities (liquidity stress and fire sales; contagion and interconnectedness; leverage and procyclical deleveraging) and (ii) operational, governance, market-structure, and infrastructure risks. - The framework maps features to primary (direct) risk channels (solid circles), secondary (amplification) channels (hollow circles), and mitigating mechanisms (triangles). - Assignments relied on staff judgment informed by literature review, outreach, analysis of use cases, and generative artificial intelligence tools as research support; final classifications determined by staff. - High-level risk categories (Annex Table 3.2.1 descriptions preserved) - Liquidity — "Liquidity, Runs, and Fire Sales Risk": Risk that investors rapidly redeem, withdraw, or sell assets, triggering liquidity strains, forced asset sales, price dislocations, and adverse feedback loops. Includes stablecoin runs, redemption pressures, liquidity mismatches, fire sales of reserve assets, and liquidity spirals. It also includes liquidity risk from fragmented structures. - Interconnectedness — "Interconnectedness & Contagion Risk": Risk that shocks propagate across institutions, markets, infrastructures, or networks. Includes TradFi–ToFi linkages, cross-market spillovers, collateral linkages, counterparty exposures, interconnected protocols, and contagion through composability and common asset holdings. - Leverage — "Leverage & Procyclical Deleveraging Risk": Risk that leverage amplifies shocks and leads to forced deleveraging. Includes collateral reuse, rehypothecation, margin calls, liquidations, collateral valuation shocks, collateral velocity, and leverage embedded in protocol interactions. - Operational — "Operational, Technology & Governance Risk": Risk arising from failures of technology, operational processes, or governance arrangements. Includes smart-contract vulnerabilities, coding errors, cyber incidents, oracle failures, operational outages, governance failures, fraud, and human or process failures. - Infrastructure — "Infrastructure & Market Risk": Risk arising from the organization and functioning of tokenized markets and infrastructures. Includes network fragmentation, interoperability failures, concentration in validators, custodians, cloud providers, oracle providers or tokenization platforms, settlement bottlenecks, and dependencies on critical market infrastructures. - Feature-to-risk mapping highlights (Annex Table 3.2.2 excerpts and rationale) - Core features - C1 DLT-based recordkeeping and transfer: ○ ▲ ● — DLT record-keeping produces high dependence on a shared market infrastructure and validator/network architecture (amplifies operational risk); can reduce operational risk by providing a shared and synchronized record of ownership and transactions. - C2 Programmability: ○ ○ ● ▲ — Automated code execution can create coding, governance, or execution failures (operational risk) and can amplify contagion and deleveraging; well-designed smart contracts can reduce operational risk by reducing processing errors and legal ambiguity. - C3 Composability: ● ○ ○ ▲ — Protocol linkages create direct contagion channels and can amplify leverage and collateral reuse; can reduce operational risk by lowering coordination frictions. - C4 Atomicity: ○ ▲ ● — Coordinated execution creates technology and settlement-execution dependencies (operational risk) and can amplify liquidity pressures; near-instant settlement can reduce contagion risk by lowering counterparty exposures. - Issuance design attributes - I1 Nature of claim: direct claim on underlying asset (● ○ ▲) — direct exposure can trigger redemption runs and fire sales; reduces contagion by removing intermediary channels. Claim on issuer-intermediary (○ ●) — intermediated claims create dependency on the intermediary and can trigger redemption runs. - I2 On/Off-chain dependence: "Relies on off-chain assets or processes" (● ○ ▲) and "Fully on-chain" (○ ▲ ●) — off-chain links can transmit shocks between tokenized and traditional markets; fully on-chain concentrates dependencies on DLT network resilience but can reduce reconciliation needs. - I3 Access model: Permissionless (● ○ ▲) vs Permissioned (○ ▲ ●) — permissionless increases cyber, governance, and operational vulnerabilities; permissioned concentrates control and can fragment liquidity. - I4 Governance structure: Decentralized governance (● ○) vs Centralized governance (○ ▲ ●) — decentralized complicates coordination and accountability; centralized creates concentration risk but can enable rapid incident response. - I5 Oracle dependence: Yes (○ ●) — external data-feed failures or manipulation can create operational risk and transmit shocks. - Trading structure attributes - T1 Trading venue concentration: Single dominant venue (▲ ○ ●) vs Multiple venues (○ ● ▲) — concentration creates single points of failure but may support market depth; multiple venues increase operational complexity and fragmentation risk. - T2 Interoperability: Interoperable networks (▲ ● ○) vs Siloed network (○ ▲ ●) — interoperability creates contagion channels but can reduce liquidity frictions; silos fragment liquidity and can amplify strains. - T3 Trading hours: Continuous (24/7) (○ ▲ ○) — continuous trading can accelerate runs, margin calls, and liquidations; continuous access can reduce liquidity risk by allowing rebalancing as shocks occur. - T4 Investor access: Institutional only (no direct risk channel) vs Retail accessible (○ ○) — retail access can amplify liquidity and contagion risks through synchronized behavior. - Settlement and clearing attributes - S1 Settlement finality: On-chain finality (○ ○ ▲) vs Reliance on legal or off-chain finality (▲ ●) — on-chain finality can increase interconnectedness and operational reliance on DLT; legal/off-chain finality creates operational and legal uncertainty but may benefit from established default-management frameworks. - S2 Clearing structure: Bilateral clearing/settlement (○ ● ▲) vs Central clearing (○ ▲ ●) — bilateral exposures increase counterparty risk; central clearing concentrates functions and may generate liquidity demands but can reduce gross funding needs via netting. - Financial functions (cross-cycle) - F1 Collateral mobility and reuse: ▲ ○ ● — tokenization increases collateral portability and reuse (supports leverage and complex collateral chains) and can transmit shocks across platforms; higher mobility can reduce liquidity risk in normal times. - F2 Programmable collateral and margining: ○ ▲ ● — programmable rules can automate margin calls and liquidations (procyclical deleveraging risk) but can also improve collateral allocation and reduce funding needs. - Methodological and presentation notes - The matrix separates where risks originate from how they spread (primary vs secondary channels). - Mitigating mechanisms are linked to a single primary mitigation channel per feature to preserve interpretability. - Framework reorganized into three dimensions for presentation: risk creation, risk amplification, and risk mitigation; streamlined version reported in the chapter (Table 3.1). ### Examples of Specific Operational and Infrastructure Risks (Annex 3.3) - Operational and cyber risk category definitions (Annex Table 3.3.1) - Smart-Contract Failure — "Coding Bugs, logic failures, exploits, upgrade errors (many smart contracts can be modified through governance processes), admin-key misuse." - Example provided: a tokenized real estate contract allows investors to trade tokens after a property sale, resulting in confusion over who is entitled to sale proceeds. - Coding bugs can freeze or destroy assets instantly. *Source: International Monetary Fund, Global Financial Stability Report, Chapter 3 Annexes 3.1–3.3, October 2026.* ### Section 2 ### ch3annex - Section 2 ### Oracle Manipulation - The risk that the external data feeding a smart contract is deliberately altered, corrupted, or spoofed, causing the smart contract to execute incorrect actions. - It can entail: i) price feed manipulation; ii) data source corruption; iii) oracle operator attack; iv) timing manipulation. - Oracle manipulation risk is essentially valuation manipulation risk translated into code. - Because smart contracts automatically act on oracle data, an incorrect or manipulated valuation can immediately affect trading, lending, collateral management, and investor payouts across the entire tokenized ecosystem. ### Infrastructure Risks - Bridge / Interoperability Failure - The risk that the infrastructure connecting different blockchains, tokenization platforms, or settlement systems fails, causing assets, cash, or information to become stuck, lost, duplicated, or transactions unable to settle. - An example is asset lock-up risk when assets become inaccessible during transfer. - If the bridge incorrectly records ownership—the same asset now appears to exist twice and can lead to disputes, overstatement of collateral, etc. - Recordkeeping Fragmentation - On-chain vs off-chain ledgers diverge, and ownership, transaction, and asset information becomes scattered across multiple blockchains, tokenization platforms, custodians, registrars, and traditional databases, making it difficult to establish a single, authoritative record of ownership and activity. ### Cryptographic Risks - Cryptographic risk related to keys, wallets - Owners lose access to, or unauthorized parties gain control over, the cryptographic credentials that establish ownership of tokenized assets. - Unlike traditional securities, where ownership can often be restored through a broker or registrar, loss or theft of cryptographic keys may result in immediate and potentially irreversible loss of control over the asset. - Assets continue to exist, but the investor may be unable to prove or exercise ownership rights. - Cryptographic risk related to quantum computing - Risk that advances in computing, particularly quantum computing, could break the cryptographic algorithms that protect tokenized assets, wallets, digital signatures, and blockchain networks (see Wu 2005). --- _Source: https://www.imf.org/-/media/files/publications/gfsr/2026/october/english/ch3annex.pdf_