# Cross-Chain Yield Composability with pCC

> This is the section that explains *why hstXDC on Canton specifically*. A holder with both locked Canton-side institutional positions and staked XDC can now operate both through a single Canton-side surface, without the value-bearing assets ever crossing a bridge committee. The thesis is composability between two yield sources whose trust assumptions are individually mappable to regulated counterparty frameworks.

`[D2 diagram -- framed next session]`

### The composability problem this solves

Institutional holders of two distinct asset classes have historically had to manage them through two distinct operational surfaces:

| Asset class                                                                                                                                  | Where it lives | What the holder can do with it                                                                                                                          |
| -------------------------------------------------------------------------------------------------------------------------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Locked Canton Coin (pCC)** -- principal Canton Coin positions held by validators, foundations, and large stakers under lock-up commitments | Canton Network | Earn governance rewards. Participate in Canton consensus. **But: cannot finance operations against the locked position without breaking the lock.**     |
| **Staked XDC** -- institutional XDC positions delegated to masternodes for native staking yield                                              | XDC Network    | Earn \~10% nominal staking yield. Participate in validator selection. **But: cannot finance operations against the staked position without unstaking.** |

Both positions share the same structural property: **the holder is committed to a long-duration position they cannot easily collateralize without breaking the underlying yield-bearing arrangement.** In traditional finance this is exactly the problem repo markets solve -- lend the position out short-term against cash, retain the underlying economic exposure. In DLT-native institutional finance, the equivalent infrastructure has been missing, especially across chains.

hstXDC, combined with the existing Canton-side pCC custody and repo infrastructure that Helix operates, closes this gap.

### The mechanical thesis

Once a holder's XDC is in the hstXDC vault, the resulting `hstXDC` token lives on Canton as a CIP-56 compliant asset. From the perspective of the Canton-side institutional infrastructure, `hstXDC` is just another CIP-56 collateral type, indistinguishable in operational shape from cBTC, USDCx, or pCC itself.

This means a holder of both locked Canton Coin and staked XDC can, on the Canton-side surface alone:

1. Hold `hstXDC` in the same Canton wallet that holds pCC, USDCx, and any other CIP-56 assets
2. Use `hstXDC` as collateral in the same lending and repo workflows that already accept pCC
3. Settle `hstXDC` against pCC, USDCx, or other CIP-56 assets through Canton's native atomic Delivery-versus-Payment workflows
4. Maintain the underlying XDC native staking yield throughout, without breaking the staking position
5. Maintain the underlying Canton governance commitments on the locked pCC, without breaking the lock

**The holder sees one operational surface (Canton), runs two yield-bearing positions through it (XDC native staking via hstXDC, plus locked pCC), and accesses institutional credit against either or both without touching the underlying yield commitments.**

### Why the trust model matches the institutional reader's mental model

The reason this composability is interesting to a regulated institutional reader -- and the reason it has not existed at this layer before -- is that both yield sources have trust assumptions that are individually mappable to known counterparty frameworks:

| Yield source                                         | Trust root                                                                                                  | Counterparty framework analog                                                                    |
| ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ |
| **XDC native staking yield** (via hstXDC)            | 108 KYC-verified XDC validator masternodes; native BFT consensus                                            | Identifiable counterparty list, similar to a known validator panel in a regulated PoS deployment |
| **Locked Canton Coin governance position** (via pCC) | Canton Network synchronizer Super Validators; institutional operators of the Global Synchronizer Foundation | Identifiable institutional consortium, similar to a permissioned interbank settlement network    |
| **Bridge layer between the two**                     | Threshold-signature attestor network (no single key holder), with no value-bearing assets crossing          | Threshold-cryptography custody analog, similar to MPC custody with distributed key shares        |
| **Canton-side custody of all CIP-56 assets**         | BitGo Bank & Trust (federally chartered US entity, $250M insurance, qualified custody)                      | Standard regulated US qualified custodian arrangement                                            |
| **XDC-side custody of underlying XDC**               | BitGo Bank & Trust (same regulated entity, supports XDC mainnet)                                            | Same regulated US qualified custodian arrangement                                                |

**Every layer in the stack has a trust model that maps to something a regulated counterparty already understands.** None of the layers requires the institutional reader to accept "trust the anonymous PoS validator pool," "trust the unaudited bridge committee," or "trust the offshore custodian." The dual-end BitGo qualified custody coverage (live since March 25 2026 for the Canton CIP-56 side, since February 1 2026 for the XDC side) is the load-bearing detail that makes the entire composability story operationally accessible to a regulated US institutional reader today.

### What the value-bearing flow looks like

The key property that makes the bridge layer institutionally acceptable is that **the value-bearing assets never cross the bridge.** Only attestations cross. The flow is:

1. The XDC stays on XDC mainnet, in the hstXDC vault contract, accruing native staking yield.
2. The locked pCC stays on Canton, in the holder's Canton wallet, accruing governance position value.
3. The hstXDC token on Canton is *backed* by the XDC vault contract -- but the token itself is a Canton-native Daml asset, not a wrapped XDC.
4. Operations against the hstXDC token (collateralization, transfer, DvP, repo) happen entirely on Canton, against Canton-native counterparties, with Canton-native settlement guarantees.
5. The only events that cross the bridge layer are: deposit-event attestations (XDC -> Canton, "this XDC was deposited, mint hstXDC"), exchange-rate update attestations (XDC -> Canton, "yield accrued"), and unstake-completion attestations (XDC -> Canton, "redemption is final"). None of these events carry a value-bearing asset.

**The institutional custody question collapses:** instead of "who custodies the bridged asset across the bridge," the question becomes "who custodies the XDC on XDC, and who custodies the LST on Canton." Both ends are answered by the same regulated US qualified custodian (BitGo Bank & Trust, federally chartered, $250M insurance). The bridge committee never touches a value-bearing position because the bridge committee is, by construction, an attestation network -- not a custody network.

### The cross-chain yield surface, in one paragraph

A holder with locked Canton Coin positions and staked XDC can, after depositing into hstXDC, operate a unified Canton-side institutional yield surface that pulls from two regulated-counterparty L1s simultaneously, finances against either or both without breaking the underlying yield commitments, settles atomically through Canton's native DvP infrastructure, custodies through a federally chartered US qualified custodian on both ends, and never relies on a notarized-witness multisig committee for any value-bearing flow. **This is the institutional thesis. Everything else in this document is the supporting evidence.**

### What this section deliberately does not describe

* **Specific lending markets, repo desks, or yield venues by name.** The composability pattern is the architecture; the venues that implement it on the Canton side evolve independently. Helix's pCC custody and repo infrastructure is one such venue (see sec10); other Canton-side institutional venues exist or are in development. The hstXDC token does not depend on any specific venue -- it depends on the CIP-56 standard, which all Canton-side institutional venues converge on.
* **Yield numbers, basis spreads, or rate quotes.** Those are partner-specific and time-sensitive. The structural argument in this section holds regardless of the prevailing rate environment; the rate environment is a question for direct partner conversation.
* **Specific institutional counterparties or DD references.** This is a public technical document, not a sales deck. Counterparty references are available to active partners under separate communication.