Tokenized Treasury Bonds Settlement

Model B: Direct Tokenization (DTCC Digital Asset Pilot)

Model B structures the token as a direct on-chain representation of a DTC-custodied Treasury instrument. The underlying Treasury remains in DTC custody throughout; what changes is that a parallel on-chain record of ownership is maintained on the distributed ledger, and legal finality for ownership transfers is confirmed by DTC's LedgerScan — a record update in the DTC system — rather than by a fund transfer agent. The DTCC partnership with Digital Asset Holdings on the Canton Network, announced December 17, 2025 under an SEC no-action letter issued December 11, 2025, is the most significant infrastructure-level implementation of this model to date.

The structural difference from Model A is material for regulated workflows. In Model B, the token represents a DTC-custodied claim on an actual Treasury instrument. Legal finality is a DTC record update — the same system that provides finality for traditional Treasury settlement. This makes the Model B token structurally compatible with repo master agreements, margin requirements, and collateral eligibility definitions that specify Treasury securities settled at DTC as the eligible category. Model A tokens, whose legal finality is a fund transfer agent register update, may not satisfy those definitions without explicit contractual agreement.

The DTCC pilot covers eligible assets including U.S. Treasury bills, bonds, and notes, operates under three-year SEC no-action relief, and is targeted at DTC Participants — broker-dealers and clearing firms already in the settlement ecosystem. It is designed for integration into existing operations workflows rather than as a standalone DeFi product. A minimum viable product is targeted for H1 2026.

Settlement Mechanics: Model A — The Mint and Redeem Cycle

Model A settlement operates across three distinct transaction types, each with different operational constraints.

Subscription (primary issuance): An investor submits a subscription — typically with a fiat or USDC payment — through the fund's onboarding process. The investor's wallet must already be whitelisted: KYC/AML verification completed, eligibility confirmed by the transfer agent. The fund administrator processes the subscription at the next NAV calculation, the fund acquires the equivalent Treasury exposure in the secondary market, and the transfer agent mints tokens to the investor's wallet upon confirmation of funds received. This process is not 24/7. It requires fund administrator processing (business hours), a Treasury market execution (U.S. market hours), and cash settlement (Fedwire or USDC). Subscription processing windows range from same-day for institutional investors with USDC settlement to T+2 for fiat settlement through traditional banking.

Secondary transfer (on-chain): Once tokens are in an investor's wallet, on-chain secondary transfers to other whitelisted wallets can occur at any time. The transfer is ledger-native and does not require fund administrator intervention. The transfer agent's register must reflect the new ownership, either in real time (for high-frequency transfer agent systems such as Securitize's Digital Asset Platform) or in a batch update at the next processing cycle. During any window between on-chain transfer and register update, there is a record divergence between the ledger and the transfer agent system.

Redemption: The investor submits a redemption instruction through the fund portal or by initiating a designated on-chain transaction. The transfer agent processes the redemption at the next NAV, tokens are burned on the ledger, the fund sells the corresponding Treasury exposure, and cash is returned to the investor's account in fiat or USDC. The USDC redemption path is operationally significant: several Model A funds maintain a USDC liquidity buffer — holding a portion of assets as USDC rather than Treasury instruments — specifically to enable immediate redemption settlement outside Fedwire operating hours. Without this buffer, redemptions submitted outside banking hours are queued for the next business day, limiting the 24/7 utility that tokenization nominally provides.

Settlement Mechanics: Model B — DTC-Linked Transfer

Model B settlement integrates with the existing DTC settlement infrastructure rather than replacing it. In the DTCC Digital Asset pilot, a DTC Participant holding tokenized Treasury securities on the Canton Network can transfer the on-chain token representation to another DTC Participant. The transfer triggers a corresponding LedgerScan update in the DTC system, confirming the ownership change in the DTC custody record. The underlying Treasury instrument does not move; the DTC record of beneficial ownership changes.

For settlement purposes, the Model B workflow addresses the gap that Model A cannot: the counterparty receiving Model B tokens receives a DTC-confirmed ownership change, satisfying the finality requirements that traditional Treasury counterparties specify. The cash leg in Model B settlement is expected to follow the existing cash settlement infrastructure — Fedwire or a designated equivalent — consistent with institutional DTC settlement norms. DvP in the DTCC pilot context follows DvP Model 2 mechanics (asynchronous legs), consistent with current DTC practice, rather than DvP Model 1 atomic settlement. FICC (Fixed Income Clearing Corporation) multilateral netting — one of the primary economic benefits of participation in the traditional Treasury settlement ecosystem — does not currently cover tokenized Treasury transfers, a structural gap that applies to both models.

NAV vs Market Price: The Pricing Distinction

NAV pricing in Model A creates a pricing model that differs from traditional Treasury pricing in ways that matter for collateral and risk management. Traditional Treasury securities are priced continuously in the secondary market, with real-time bid-ask quotes from primary dealers. Model A tokens are priced at the fund's last-calculated NAV — typically the previous day's close. Intraday rate movements are not reflected until the next NAV calculation.

This creates three operational tensions. First, for collateral valuation: if a counterparty requires daily mark-to-market of a Treasury collateral position and uses the Model A token's last-stated NAV, the collateral value may be stale by up to one business day of rate movement — a material difference if yields have moved significantly. Second, for secondary market transfers: an on-chain transfer of Model A tokens can execute at any agreed price, which may diverge significantly from NAV. Neither party is necessarily wrong, but the divergence creates a reconciliation challenge if the transfer agent records the transfer at NAV. Third, for margin calls: a collateral agreement that marks Model A tokens to NAV rather than market price may produce a margin shortfall or excess relative to the economically correct value, potentially triggering or missing a margin call.

Funds offering real-time NAV — calculating and publishing NAV continuously based on live market data — reduce but do not eliminate this gap. They introduce a continuous oracle dependency for NAV calculation: the fund administrator or oracle provider must deliver accurate, timely market data for each Treasury holding, and the latency of that data feed determines the precision of the real-time NAV. An oracle failure during a real-time NAV calculation window is operationally equivalent to the floating-rate coupon oracle failure described in the tokenized bond settlement lifecycle.

Collateral Usage: Repo, DeFi, and Stablecoin Backing

The collateral use case is the primary driver of institutional demand for tokenized Treasuries. Three collateral contexts carry distinct operational requirements.

Bilateral and tri-party repo: a counterparty posts tokenized Treasuries as collateral for a cash loan, with an agreement to repurchase. For the counterparty receiving collateral, the key question is finality: does the collateral transfer produce a legally enforceable ownership change sufficient to satisfy the collateral agreement's eligibility criteria? For Model A tokens, the answer depends on whether the master repo agreement explicitly accepts fund shares in regulated tokenized fund structures as eligible collateral — language that most pre-tokenization agreements do not contain. For Model B tokens, the DTC LedgerScan update provides finality aligned with traditional Treasury repo. The FICC netting gap affects both models: tokenized flows bypass the multilateral netting that reduces gross settlement obligations for FICC members, increasing the volume of individual delivery versus payment instructions and the aggregate settlement cost relative to traditional netting-eligible flows.

Permissioned DeFi lending: protocols such as Aave Horizon (accredited investors only) and Euler Finance's institutional pools accept whitelisted Model A tokens as collateral against stablecoin loans. The collateral is overcollateralized — typically at a 75–90% loan-to-value ratio — and a liquidation mechanism executes automatically if the ratio falls below the threshold. The oracle feed for collateral valuation is the critical operational path: a delay in NAV update, an incorrect rate feed, or a sharp rate move that outpaces oracle update frequency can create an undercollateralised position that the protocol's liquidation engine either triggers prematurely or misses entirely.

Stablecoin reserve: tokenized Treasuries serve as the reserve backing for yield-bearing stablecoins, where the issuer holds Treasury exposure and passes yield to token holders. The issuer in this model is structurally identical to a Model A fund manager — it holds Treasuries, manages the subscription and redemption cycle, and provides the on-chain representation. The critical operational difference is that stablecoin users expect 1:1 redeemability at any time, a constraint that requires the issuer to hold a USDC liquidity buffer sufficient to cover demand outside Treasury market hours.

24/7 Access and the Market Hours Boundary

The 24/7 settlement claim for tokenized Treasuries is accurate for on-chain token transfers but incomplete for the operations that give those tokens economic value. The boundary between the 24/7 on-chain layer and the market-hours-constrained off-chain layer generates specific operational failure modes.

Treasury coupon payments originate from the U.S. government's Fedwire-based payment system, which operates on business-day schedules. A tokenized fund whose coupon flows through a fund administrator receives the coupon payment from the government during business hours; the fund then distributes the equivalent amount on-chain. The on-chain distribution can occur at any time, but the cash underlying it is constrained by Fedwire availability. A fund that pre-funds on-chain coupon distributions outside Fedwire hours is extending credit to the fund from its own liquidity buffer.

Treasury auction participation — the process by which new Treasury bills and bonds enter the market — is constrained to business hours and specific auction schedules. A fund experiencing large subscription inflows outside auction hours must hold cash or near-cash instruments until it can deploy into the intended Treasury instruments, creating a tracking error between the fund's stated objective and its actual holdings during the lag period.

The practical implication for operations teams: tokenized Treasury products provide genuine 24/7 transfer capability at the on-chain token layer. The economic events that determine the token's value — interest accrual, coupon receipt, NAV calculation, fund acquisition and redemption — are still constrained by traditional market infrastructure operating hours. Contingency liquidity plans built around tokenized Treasuries must account for both layers.

Liquidity Fragmentation

Tokenized Treasury products are issued across multiple blockchain networks — Ethereum, Stellar, Polygon, Solana, Aptos, Canton Network, Centrifuge — each with separate liquidity pools, transfer agent connections, and secondary market infrastructure. There is no automatic arbitrage mechanism or unified cross-chain secondary market. An investor holding FOBXX tokens on Stellar and needing to exit quickly may find the Stellar secondary market insufficiently deep at that moment; the equivalent product on Ethereum is a different instrument requiring a separate subscription and redemption cycle, not a cross-chain transfer of the existing position.

Cross-chain bridges can theoretically transfer tokens across networks, but tokenized Treasury products issued as restricted securities have whitelist-enforced transfer restrictions encoded in the smart contract. A cross-chain bridge that moves a token from one network to another without the transfer agent's registry reflecting the change creates a legal and operational divergence: the token exists on the new chain but ownership is not recorded in the authoritative register. Most institutional tokenized Treasury products explicitly prohibit cross-chain transfers through bridge protocols; liquidity exits must go through the fund's redemption process, not through bridges.

The fragmentation problem is most acute during market stress: when investors most need liquidity, the tokenized product's secondary market may be thin and the redemption queue may be gated. The liquidity profile of a tokenized Treasury product is the combination of its on-chain secondary market depth (which may be limited), its fund redemption capacity (which is subject to processing windows and gating), and its USDC buffer (which determines the immediate liquidity available outside market hours). Wrapped tokenization models — where the token represents a claim on a CSD-custodied or fund-held instrument — and native issuance models have different liquidity profiles because the wrapped model can theoretically arbitrage against the underlying, while the fund-share model settles entirely within the fund's own redemption process.

CCTP and Cross-Chain Settlement

Circle's Cross-Chain Transfer Protocol (CCTP) is a burn-and-mint mechanism for native USDC across supported chains. In tokenized Treasury settlement, CCTP functions as the inter-chain cash leg: when a redemption generates USDC proceeds on one chain and the investor needs those proceeds on a different chain for reinvestment or collateral posting, CCTP provides the transfer path. USDC on the source chain is burned, Circle's attestation service confirms the burn event, and an equivalent amount of USDC is minted natively on the destination chain — not wrapped, not bridge-custodied, but native on the destination network.

The operational significance: CCTP prevents cash proceeds from becoming stranded in a single-chain pocket. An investor who redeems BUIDL (Ethereum) for USDC and wants to reinvest in a tokenized Treasury product on Avalanche can transit the proceeds via CCTP without requiring a centralised exchange or custodian bridge. The latency is typically one to three minutes, including block confirmation times and attestation processing.

CCTP operates under Circle's centralised attestation service — an operational dependency with a specific failure mode: attestation service outage suspends all in-flight CCTP transfers. Positions mid-transit (burned on the source chain, not yet minted on the destination) are in a suspended state until attestation resumes. For collateral operations with tight margin deadlines, CCTP transit timing must be factored into the settlement timeline, not assumed to be near-instant.

Failure Modes

Five failure categories are operationally specific to tokenized Treasury settlement.

NAV mismatch: the on-chain price at which a Model A token transfer executes diverges from the fund's last-calculated NAV. For collateral systems using stale NAV, this creates a systematic mark-to-market error — potentially material on days of significant rate movement. Counterparties managing margin against Model A tokens should specify the NAV update frequency and accept only tokens whose last NAV is within a defined staleness threshold.

Redemption gating: a Model A fund facing simultaneous large redemptions — particularly during market stress, when investor demand for liquidity peaks at the same moment the fund faces difficulty selling Treasury positions — may invoke gating provisions limiting daily redemption amounts or imposing processing delays. Investors relying on tokenized Treasuries for emergency or intraday liquidity must understand the fund's gate provisions before posting them as collateral or including them in a liquidity contingency plan. A gate invoked at 8pm UTC when Fedwire is closed is not relieved until the next business day.

Custodian concentration: Model A products concentrate Treasury custody in one or two qualified custodians. A custodian operational failure, regulatory action, or insolvency impairs all associated fund products simultaneously, creating a concentration risk with no direct parallel in traditional Treasury custody, where holdings are distributed across many custodial relationships.

Chain fragmentation liquidity trap: an investor holding a tokenized Treasury on a chain where secondary market liquidity is thin or absent cannot exit without going through the fund redemption process, which is subject to processing windows and gating. If the investor needs immediate liquidity and the fund has gated redemptions, the investor has no secondary market exit on that chain, cannot bridge to a more liquid chain without violating transfer restrictions, and must wait for the gate to lift or the processing window to open.

Collateral eligibility mismatch: counterparties with collateral eligibility definitions written before tokenization became material typically specify Treasury securities settled at DTC as the eligible category — a definition that Model A tokens do not satisfy (their finality is a fund transfer agent register update, not a DTC settlement) and that Model B tokens are designed to satisfy. An operations team assuming that any tokenized Treasury product satisfies a traditional Treasury collateral eligibility clause without reviewing the specific finality source is exposed to a collateral rejection at the moment the collateral is needed.