Tokenised Asset Security Architecture

Key Control Areas

• Custody Architecture and Cryptographic Key Management (SC-12, SC-13, SC-28, PE-03, CP-09, AC-06): The custody architecture is the most critical security decision for any tokenised asset platform. Private keys control asset ownership, and unlike traditional custody where regulators can freeze and recover assets, a compromised blockchain private key results in irreversible loss. SC-12 (Cryptographic Key Establishment and Management) is the anchor control: the entire key lifecycle -- generation, distribution, storage, usage, rotation, backup, and destruction -- must follow FIPS-compliant processes adapted for blockchain signing operations. Three custody approaches exist, each with distinct security properties. HSM-based custody (FIPS 140-2/3 Level 3+) provides tamper-resistant hardware where keys never leave the device, but creates a single point of failure and requires physical access procedures (PE-03). MPC-based custody distributes key shares across multiple parties and environments (e.g., AWS Nitro Enclave + Azure Confidential Computing + client-controlled share) so that no single party ever possesses the complete key -- joint computation produces valid signatures without key reconstruction. Threshold signature schemes (TSS), a subset of MPC, require t-of-n share holders to cooperate for signing, providing both security (compromise of t-1 shares reveals nothing) and availability (n-t shares can be unavailable). On-chain multi-signature schemes (e.g., Safe{Wallet}) require multiple independent signers but produce on-chain signature verification, adding gas costs and on-chain visibility. SC-13 (Cryptographic Protection) mandates FIPS-validated algorithms: ECDSA secp256k1 for Ethereum/Bitcoin signing, EdDSA Ed25519 for Solana/Cardano, with post-quantum readiness planning per FIPS 203-205 for long-lived assets. SC-28 (Protection of Information at Rest) applies to key-encrypting keys, backup shares, and recovery material. CP-09 (System Backup) governs key backup: MPC share backup across geographically distributed facilities, HSM backup via secure key ceremony, and recovery procedures tested quarterly. AC-06 (Least Privilege) ensures that hot wallet signing keys have transaction-level limits (maximum value, destination whitelist, rate limiting), warm wallet keys require dual authorisation with time-of-day restrictions, and cold wallet keys require multi-person key ceremony with quorum approval. The institutional standard is a tiered architecture: 5-10% of assets in hot wallets for operational liquidity, 5-15% in warm wallets for treasury operations, and 75-90% in air-gapped cold storage. Every tier must have independent monitoring, and movement between tiers requires approval workflows with segregation of duties.
• Smart Contract Security Lifecycle (SA-11, CM-03, SI-10, CA-08, RA-03): Smart contracts are immutable once deployed -- a vulnerability in production cannot be patched in the traditional sense. This makes the pre-deployment security lifecycle critical. SA-11 (Developer Security Testing) must include blockchain-specific testing methodologies beyond traditional SAST/DAST: formal verification (proving mathematical correctness of critical invariants using tools like Certora, Halmos, or Echidna property-based testing), symbolic execution (exploring all possible execution paths to find reachable vulnerabilities), fuzzing (automated input generation targeting edge cases in arithmetic, access control, and state transitions), and manual expert audit by specialist firms with demonstrated smart contract security expertise. The OWASP Smart Contract Top 10 (2026) identifies the primary vulnerability classes: access control flaws (SC01, $953M in 2024 losses), business logic errors (SC02), oracle manipulation (SC03), flash loan exploitation (SC04), input validation failures (SC05), unchecked external calls (SC06), arithmetic errors (SC07), reentrancy (SC08, $325M in 2025), integer overflow (SC09), and proxy/upgradeability vulnerabilities (SC10, new for 2026). SI-10 (Information Input Validation) addresses SC05 directly: every external function must validate parameters, check caller authorisation, verify state preconditions, and handle edge cases in arithmetic (rounding, precision loss, division by zero). CM-03 (Configuration Change Control) governs smart contract upgrades, which for tokenised assets carrying billions in value require exceptional governance rigour. Upgradeable contracts (proxy patterns: transparent proxy, UUPS, diamond/EIP-2535) must enforce: multi-signature approval for upgrade transactions (minimum 3-of-5 for production), mandatory timelock delays (48-72 hours minimum) allowing stakeholders to review proposed changes and exit if they disagree, independent security audit of every upgrade, and a tested rollback or pause mechanism. CA-08 (Penetration Testing) maps to the smart contract audit requirement: every contract handling value must undergo at least two independent audits before mainnet deployment, with re-audit required for any functional change. Bug bounty programmes (Immunefi, HackerOne) provide continuous security testing post-deployment. RA-03 (Risk Assessment) must include blockchain-specific threat modelling: what is the maximum extractable value if any single function is called with adversarial inputs? What happens if the contract is called in an unexpected sequence? What composability risks exist from other protocols interacting with the contract?
• Oracle and Price Feed Security (SI-10, SC-07, CA-07, SC-08): Oracles are the bridge between off-chain data (asset prices, interest rates, FX rates, corporate actions) and on-chain smart contract execution. For tokenised assets, oracle integrity directly determines NAV calculations, collateralisation ratios, margin calls, and settlement values. A manipulated price feed can trigger incorrect liquidations, enable undercollateralised borrowing, or cause NAV miscalculation affecting all token holders. SI-10 (Information Input Validation) requires that smart contracts validate oracle data before use: check data freshness (reject stale prices beyond a configurable staleness threshold), verify the oracle source (confirm the response comes from the expected oracle contract, not a spoofed address), validate price bounds (reject prices that deviate beyond expected ranges from the last known good price), and implement circuit breakers that pause operations when oracle data appears anomalous. SC-07 (Boundary Protection) defines the trust boundary between on-chain and off-chain data: oracle networks (Chainlink, Pyth, Band Protocol) provide decentralised data aggregation where multiple independent node operators submit data and the oracle contract computes a median or weighted average, reducing the impact of any single compromised source. For L2 deployments, contracts must additionally check the L2 sequencer status -- a down sequencer can cause oracle data to appear fresh when it is actually stale, leading to exploitable price discrepancies. CA-07 (Continuous Monitoring) requires real-time monitoring of oracle price feeds: alert on unusual price movements, detect potential manipulation attempts (sudden spikes followed by large protocol interactions), and compare on-chain oracle prices against off-chain reference prices to identify divergence. SC-08 (Transmission Confidentiality and Integrity) addresses the oracle data delivery path: oracle updates should be delivered through authenticated channels, and for high-value operations, multiple independent oracle sources should be required to agree before execution (oracle consensus). Time-Weighted Average Prices (TWAP) calculated over multiple blocks provide manipulation resistance for DEX-derived prices but introduce latency. For institutional tokenised assets where NAV accuracy is regulatory requirement, consider dedicated oracle infrastructure with SLA-backed data providers rather than relying solely on public oracle networks.
• On-Chain/Off-Chain Security Boundary (SC-07, AC-04, AU-02, CM-08): The defining architectural challenge of tokenised assets is the boundary between on-chain token state and off-chain legal reality. A tokenised bond exists as an ERC-20 token on Ethereum and simultaneously as a legal obligation of an SPV incorporated in Luxembourg. The smart contract enforces transfer restrictions and records ownership; the SPV legal structure enforces the economic rights. Neither is sufficient alone, and the security architecture must ensure they remain synchronised. SC-07 (Boundary Protection) defines this as a trust boundary: on-chain state changes (token transfers, minting, burning) must be reflected in off-chain records (transfer agent, registrar, cap table), and off-chain events (corporate actions, coupon payments, regulatory freezes) must be reflected on-chain. AC-04 (Information Flow Enforcement) governs what crosses this boundary: investor identity (via on-chain identity frameworks like ERC-3643/T-REX where compliance is enforced at every transfer through trusted claim issuers and identity registries), transaction data (amount, counterparties, timestamp), and corporate action instructions (dividend distribution, redemption, forced transfer for regulatory compliance per ERC-1644). AU-02 (Event Logging) must capture both sides: on-chain events (Transfer, Approval, ComplianceTransferManager events) provide an immutable audit trail, while off-chain systems must log the corresponding legal and operational events with cross-references to on-chain transaction hashes. CM-08 (System Component Inventory) must catalogue every system that participates in the on-chain/off-chain boundary: the token smart contract, the compliance oracle, the identity registry, the transfer agent system, the NAV calculation engine, the custodian's record-keeping system, and any bridge or relay that connects them. The critical risk is desynchronisation: if the off-chain SPV sells the underlying asset but the on-chain tokens continue trading, token holders lose their claim. Architectural mitigations include: pause functionality (the token issuer can halt all transfers during corporate actions), legal wrapper smart contracts (encoding key legal terms on-chain with references to off-chain legal documentation per ERC-1643), and reconciliation processes that continuously compare on-chain token balances against off-chain records with automated alerting on discrepancy.
• DeFi Protocol Integration and Composability Risk (RA-03, AC-03, AC-06, AU-02, IR-04): Institutional tokenised assets increasingly interact with DeFi protocols -- BlackRock's BUIDL fund now trades on Uniswap, tokenised treasuries serve as collateral in lending protocols, and institutional liquidity pools accept RWA tokens. Each integration creates composability risk: the tokenised asset's security now depends on the security of every protocol it interacts with. RA-03 (Risk Assessment) must evaluate each DeFi integration independently: what is the protocol's audit history, TVL (total value locked), governance structure, upgrade mechanism, and incident track record? Flash loan attacks (OWASP SC04, $33.8M in 2024) can manipulate protocol state within a single atomic transaction -- any integration that depends on instantaneous price or state is potentially vulnerable. AC-03 (Access Enforcement) maps to smart contract access control (OWASP SC01, the highest-loss vulnerability class): token contracts must enforce that only authorised addresses can call privileged functions (minting, burning, pausing, upgrading, modifying compliance rules), and this enforcement must be independent of any external protocol's assumptions. AC-06 (Least Privilege) requires that DeFi integrations receive only the minimum permissions necessary: a lending protocol that accepts the token as collateral needs transfer approval for the collateral amount only, not unlimited approval (which would allow the protocol to drain all tokens if compromised). AU-02 (Event Logging) must capture every DeFi interaction: protocol address, function called, parameters, return values, and gas consumed, creating a forensic trail for incident investigation. IR-04 (Incident Handling) must include DeFi-specific runbooks: if a protocol the token interacts with is exploited, the response must include immediate assessment of exposure (how many tokens are in the compromised protocol?), potential pause of the token contract to prevent further deposits, communication to token holders, and coordination with the protocol's incident response team. MEV (Maximal Extractable Value) is a systemic risk: sandwich attacks constitute 51.6% of total MEV volume ($289.76M as of March 2025), averaging more than one attack per Ethereum block. For institutional transactions, private transaction submission (Flashbots Protect, MEV Blocker) or encrypted mempools (Shutter Network) mitigate front-running risk.
• Cross-Chain Bridge and Interoperability Security (SC-07, IR-04, CA-07, RA-03): Cross-chain bridges are the highest-risk component in the tokenised asset stack. Over $2.8B has been stolen from bridges, representing approximately 40% of all Web3 value hacked. Institutional tokenised assets that operate across multiple chains (BlackRock BUIDL spans 9 networks) depend on bridge security for cross-chain transfers, and a bridge exploit can result in unbacked token creation on the destination chain, effectively counterfeiting the asset. SC-07 (Boundary Protection) applies at the bridge level: each chain connected by a bridge represents a separate security domain, and the bridge is the controlled interface between them. Bridge architectures vary in security properties: lock-and-mint bridges (lock tokens on source chain, mint wrapped tokens on destination) create a single point of failure at the locked asset pool; burn-and-mint bridges (authorised minting on destination with proof of burn on source) reduce locked-asset risk but require trust in the cross-chain proof mechanism; native verification (light client proofs verified on-chain) provides the strongest security but is computationally expensive and chain-pair specific. The Wormhole exploit ($320M, February 2022) exploited a deprecated Solana function that failed to verify the sysvar account, allowing forged signature verification and unauthorised minting. The Ronin exploit ($620M, March 2022) compromised 5 of 9 validator keys through social engineering. Both demonstrate that bridge security depends on the weakest component: the validation logic and the validator set. IR-04 (Incident Handling) for bridges requires: a kill switch that can halt bridge operations within seconds (not minutes), pre-approved emergency procedures that don't require full governance quorum, automated monitoring that detects anomalous minting or transfer patterns, and a communication plan that can reach all affected chains' communities simultaneously. CA-07 (Continuous Monitoring) must track bridge TVL, validator uptime, message latency, and proof verification success rates, with alerts on any deviation from baseline. For institutional deployments, Chainlink's CCIP (Cross-Chain Interoperability Protocol, live on 60+ networks) provides defence-in-depth with timelocked upgrades, independent node operators, and veto mechanisms. Coinbase adopted CCIP as its sole bridge for $7B in wrapped tokens. RA-03 (Risk Assessment) must evaluate bridge trust assumptions: how many validators must collude? What is the upgrade governance? Is there a timelock? Can the bridge operator unilaterally modify the validator set?
• Regulatory Compliance and Digital Asset Lifecycle (AU-02, AC-03, CM-08, PS-06, AC-04): Tokenised assets operate under securities regulation -- this is the fundamental difference from utility tokens or cryptocurrencies. The compliance architecture must enforce regulatory requirements at the protocol level, not just the application level. AU-02 (Event Logging) must satisfy regulatory record-keeping requirements: MiCA mandates transaction reporting in standardised machine-readable JSON; the FATF travel rule requires sender/recipient identifying data on qualifying transfers (full name, account reference, address or date of birth); SEC custody rules require demonstrable control over digital assets with audit trails of all key usage. The EU Transfer of Funds Regulation (effective December 2024) requires that every crypto transfer regardless of size includes full sender and recipient details. AC-03 (Access Enforcement) must implement investor eligibility at the token level: ERC-3643 (T-REX) enforces compliance at every transfer through on-chain identity verification via trusted claim issuers who provide signed attestations of KYC/AML status, accredited investor status, and jurisdictional eligibility. Transfer restrictions (maximum holder counts, lockup periods, jurisdictional limits) are enforced by the compliance smart contract, not by application-layer checks that can be bypassed by interacting directly with the token contract. CM-08 (System Component Inventory) must catalogue the full regulatory technology stack: identity registry contracts, compliance oracle contracts, trusted claim issuer contracts, transfer agent integrations, and regulatory reporting systems. PS-06 (Access Agreements) maps to governance agreements for multi-signature operations: who are the authorised signers for token minting, burning, pausing, and upgrading? What quorum is required? What happens if a signer is unavailable? These agreements must be documented, tested, and subject to regular review. AC-04 (Information Flow Enforcement) ensures that regulated data flows correctly: investor PII must not be stored on-chain (only identity attestation hashes); transaction data must flow to regulatory reporting systems; and cross-border transfers must trigger travel rule data exchange between the originating and beneficiary VASPs. Basel Committee prudential treatment (effective January 2026) classifies tokenised traditional financial instruments as Group 1a (preferential capital treatment) but requires that the institution demonstrates operational risk controls over the blockchain infrastructure, including key management, smart contract risk, and settlement finality. Group 2 crypto-asset exposures (non-qualifying tokens) face conservative capital treatment with a hard cap at 2% of Tier 1 capital.
• Incident Response and Recovery for Digital Assets (IR-04, IR-06, IR-01, CP-09, CA-07): Digital asset incidents are fundamentally different from traditional IT incidents because blockchain transactions are irreversible. There is no 'restore from backup' for a transferred token, no 'rollback transaction' for an executed smart contract call, and no central authority that can freeze assets across a decentralised network (though centralised stablecoin issuers like Circle can blacklist addresses). IR-04 (Incident Handling) must include digital-asset-specific runbooks covering: private key compromise (immediately rotate all potentially affected keys, transfer assets from compromised wallets to new addresses using pre-staged emergency wallets, revoke all API keys and session tokens, notify affected chains' node operators if a bridge or protocol is involved), smart contract exploit (activate pause mechanism if available, assess the blast radius by identifying all affected token holders and protocol integrations, engage the protocol's security council or emergency multi-sig, coordinate with affected DeFi protocols to pause interactions), and oracle manipulation (compare on-chain prices against off-chain reference prices, identify manipulated feeds, pause protocol operations that depend on affected oracles, assess whether any liquidations or settlements executed at manipulated prices need to be addressed). IR-06 (Incident Reporting) must address multi-jurisdictional notification: MiCA requires CASP incident reporting to national competent authorities, DORA mandates ICT incident classification and reporting for financial entities, and SEC-registered entities must report material cybersecurity incidents. IR-01 (Incident Response Policy) must account for the speed of blockchain exploitation: the Bybit attackers converted 86.29% of stolen ETH to BTC within weeks of the $1.5B theft; the window for asset recovery is hours, not days. Pre-staged response capabilities include: emergency multi-sig wallets funded and ready to receive assets, pre-approved address whitelists for emergency transfers, relationships with chain analytics firms (Chainalysis, TRM Labs, Elliptic) for real-time fund tracing, and legal agreements with exchanges for emergency asset freezing. CP-09 (System Backup) for digital assets means MPC key share backup across geographically distributed secure facilities, cold wallet seed phrase backup with tamper-evident storage, and quarterly recovery testing that verifies the organisation can reconstruct signing capability from backup material within a defined RTO. CA-07 (Continuous Monitoring) provides the detection layer: real-time monitoring of all wallet addresses for unexpected transactions, mempool monitoring for pending transactions targeting the organisation's contracts, and chain analytics integration that flags interactions with known malicious addresses, sanctioned entities, or mixer services.

When to Use

Financial institutions building tokenised bond, equity, or fund platforms for institutional investors. Asset managers launching tokenised money market funds or structured products (following BlackRock BUIDL, Franklin Templeton BENJI precedent). Custodian banks adding digital asset custody services following SEC SAB 122 and OCC guidance. Exchanges or trading venues listing tokenised securities or RWA tokens. Fintech firms building tokenisation-as-a-service platforms for issuers. Organisations subject to MiCA, FCA, or SEC regulation that process tokenised financial instruments. Any institution where compromise of private keys could result in loss of client assets exceeding the organisation's risk appetite.

When NOT to Use

Organisations using blockchain solely for internal record-keeping or provenance tracking where no financial assets are at risk -- the custody and key management controls are disproportionate. Pure utility token projects without securities regulation applicability. Organisations with no plans to interact with public blockchain networks (purely internal permissioned ledger deployments may need a subset of controls but not the full DeFi integration, bridge security, or MEV mitigation sections). Retail cryptocurrency exchanges focused on spot trading of Bitcoin/Ethereum where the primary concern is traditional exchange security (see SP-019 Key Management) rather than smart contract and composability risk.

Typical Challenges

The most fundamental challenge is key management at institutional scale. Unlike traditional PKI where certificate authorities provide key lifecycle management, blockchain private keys have no recovery mechanism -- if a key is lost, the assets it controls are permanently inaccessible, and if a key is compromised, the assets can be irreversibly stolen. MPC and threshold signature schemes mitigate single-key risk but introduce operational complexity: key ceremony procedures, share rotation, and recovery testing require specialist expertise that most financial institutions lack internally. Smart contract immutability creates a deployment paradox: contracts must be thoroughly audited before deployment because post-deployment fixes require complex upgrade mechanisms (proxy patterns) that themselves introduce new vulnerability classes (OWASP SC10). The cost of comprehensive smart contract auditing is significant ($50K-$500K per audit from specialist firms), and the pool of qualified auditors is small relative to demand, creating bottlenecks. Regulatory fragmentation across jurisdictions creates compliance complexity: the same tokenised bond may be subject to MiCA in the EU, FCA rules in the UK, and SEC custody requirements in the US, each with different record-keeping, reporting, and capital treatment obligations. The Basel Committee's Group 1a/Group 2 classification directly affects the economic viability of holding tokenised assets on a bank's balance sheet. DeFi composability risk is poorly understood by traditional risk frameworks: when a tokenised treasury fund is used as collateral in a lending protocol that sources prices from an oracle that aggregates data from DEXs that are subject to MEV extraction, the risk chain extends far beyond the organisation's direct control. Cross-chain interoperability remains architecturally immature: bridge security is the weakest link in multi-chain deployments, and the $2.8B in bridge losses demonstrates that no current bridge architecture provides the level of assurance that institutional assets require. State-sponsored threat actors (DPRK/Lazarus Group: $2.02B stolen in 2025) specifically target cryptocurrency infrastructure with sophisticated supply chain attacks, as demonstrated by the Bybit incident where the Safe{Wallet} UI was compromised to display correct transaction details to signers while submitting different transactions to the blockchain.

Threat Resistance

This pattern provides defence-in-depth across the tokenised asset threat landscape. Private key compromise -- the highest-impact risk, responsible for 70% of stolen cryptocurrency in 2024 -- is mitigated through MPC/threshold custody architecture (SC-12, SC-13) that eliminates single-key risk and requires multi-party collusion for any signing operation. Smart contract exploitation (OWASP SC01-SC10, $905M in 2025) is addressed through mandatory pre-deployment audits, formal verification of critical invariants, and upgrade governance with timelock and multi-signature controls (SA-11, CM-03, CA-08). Oracle manipulation ($8.8M direct losses but enabling much larger compound attacks) is mitigated through multi-source oracle aggregation, staleness checks, price bound validation, and circuit breakers (SI-10, CA-07). Flash loan attacks are countered by designing contract logic that does not depend on instantaneous state that can be manipulated within a single transaction. Cross-chain bridge exploits ($2.8B total) are addressed through bridge architecture selection (preferring native verification over lock-and-mint), bridge monitoring, kill switch capability, and exposure limits (SC-07, IR-04). Supply chain attacks on wallet infrastructure (Bybit pattern) are mitigated through independent transaction verification: signers must verify transaction details through an independent channel (hardware wallet display, separate verification service) rather than trusting the signing UI alone. MEV/front-running ($289.76M in sandwich attacks) is mitigated through private transaction submission and encrypted mempool services. Regulatory non-compliance is addressed through on-chain compliance enforcement via ERC-3643 identity framework, automated travel rule data exchange, and multi-jurisdictional reporting (AU-02, AC-03). Residual risks include: state-sponsored actors with zero-day capabilities (DPRK teams embedded as insider threats within crypto firms), smart contract logic errors not caught by formal verification or audits, regulatory divergence creating conflicting compliance obligations, and the fundamental irreversibility of blockchain transactions which limits recovery options after successful exploitation.

Assumptions

The organisation is building or integrating a tokenised asset platform that will issue, manage, or custody tokens representing real-world financial instruments (bonds, equities, fund shares, structured products) on one or more public or permissioned blockchains. The target blockchains support smart contracts (Ethereum, Polygon, Avalanche, Solana, Cardano, or equivalent). The organisation is subject to securities regulation in at least one jurisdiction (EU/MiCA, UK/FCA, US/SEC, Singapore/MAS) and must comply with AML/KYC requirements including the FATF travel rule. A qualified custodian or institutional-grade custody solution (Fireblocks, Copper, Anchorage, or self-operated MPC/HSM infrastructure) is available or being evaluated. The organisation has smart contract development capability or access to specialist blockchain development firms, and budget exists for mandatory pre-deployment security audits by specialist firms. Traditional financial services security controls are already in place (see SP-019 Key Management, SP-026 PCI Full Environment) and this pattern extends the baseline with blockchain-specific controls.

Developing Areas

• Post-quantum readiness for tokenised assets is an urgent concern for long-dated instruments. A 30-year tokenised bond issued today on Ethereum uses ECDSA secp256k1 signatures that will be vulnerable to quantum attack within the bond's lifetime. NIST PQC standards (ML-KEM in FIPS 203, ML-DSA in FIPS 204, SLH-DSA in FIPS 205) are finalised but not yet supported by major blockchain networks. Organisations should implement crypto-agility: abstract signing operations behind interfaces that can migrate to post-quantum algorithms when blockchain network support arrives. Hybrid signature schemes (classical + PQC) are being explored for transition periods. See SP-040 Post-Quantum Cryptography for algorithm-level guidance.
• Institutional DeFi is emerging as a distinct category: protocols with KYC-gated pools, compliant AMMs (Uniswap v4 hooks enabling compliance checks), and permissioned lending protocols that accept only KYC-verified counterparties. Aave Arc, Compound Treasury, and Maple Finance represent early institutional DeFi. Security architecture must address the tension between DeFi composability (open, permissionless) and institutional compliance (closed, permissioned). ERC-3643 compliance enforcement at the token level provides one solution: the token itself refuses non-compliant transfers regardless of which protocol initiates them.
• L2 sequencer decentralisation is critical for institutional adoption. Most L2 networks (Arbitrum, Optimism, Base) currently operate centralised sequencers, creating a single point of failure and trust dependency that institutional risk frameworks struggle to accept. Arbitrum and OP Mainnet achieved Stage 1 classification with permissionless fraud proofs, but full sequencer decentralisation remains on roadmap. Organisations deploying tokenised assets on L2 should evaluate sequencer trust assumptions, forced exit mechanisms (can assets be withdrawn to L1 if the sequencer is down?), and governance upgrade risks (can a small multi-sig modify the rollup contract?).
• Tokenised asset insurance is an emerging market addressing the gap between traditional financial instrument insurance (covered by existing insurance markets) and blockchain-specific risks (smart contract exploit, bridge failure, oracle manipulation, key compromise). Nexus Mutual, InsurAce, and traditional insurers (Aon, Marsh) are developing products. Underwriting criteria typically require: completed smart contract audits, MPC/threshold custody, real-time monitoring, and incident response capability -- the controls in this pattern directly support insurability.
• Central Bank Digital Currencies (CBDCs) and tokenised asset interoperability: MAS Project Guardian, BIS Project Agorá, and the Bank of England's digital pound exploration all contemplate interoperability between CBDCs and tokenised securities for atomic delivery-versus-payment (DvP). The security architecture for CBDC-settled tokenised assets requires additional controls for central bank interface security, CBDC custody (distinct from commercial token custody), and settlement finality guarantees that differ from standard blockchain confirmation models.