# What is hstXDC * > **One-line:** A liquid staking primitive that lets institutional XDC holders deposit XDC into a regulated, transparent vault that mints `hstXDC` on Canton Network — preserving XDC native staking yield, governance rights, and validator selection while unlocking the position for institutional credit and yield strategies on Canton. ### The Thesis hstXDC sits at the convergence of two regulated-counterparty L1s: * **XDC Network** — 108 KYC-verified validator masternodes, BFT deterministic finality (\~6 seconds), full EVM compatibility since the v2.6.8 Cancun upgrade (mainnet block 98,800,200, January 2026), Subnet capability for permissioned execution environments. * **Canton Network** — Privacy-preserving institutional settlement layer with native sub-transaction privacy, the CIP-56 token standard for interoperable institutional assets, and a production track record carrying real-world financial settlement at institutional scale. The opportunity these two chains create together is structurally unusual: **two L1s where the validator set is identifiable, the settlement guarantees are deterministic, and the user can map the trust assumptions onto regulated counterparty frameworks.** Most cross-chain liquid staking products bridge a permissionless L1 to a permissionless DeFi venue. hstXDC bridges a KYC'd L1 to an institutional settlement network. The trust assumptions on both sides match the user's existing mental models.
### What hstXDC does, mechanically
LayerWhat happens
DepositInstitutional holder deposits XDC into the Helix Vault contract on XDC mainnet. XDC enters the masternode delegation flow and accrues native staking yield.
MintBridge layer signals the deposit to the Canton-side vault contract, which mints hstXDC 1:1 to the holder's Canton party. hstXDC is a CIP-56 compliant token.
HoldThe holder retains: XDC native staking yield (the LST appreciates against XDC over time), XDC governance rights via the validator selection layer, and full programmability of hstXDC on Canton — DvP, repo, lending, qualified custody.
RedeemHolder burns hstXDC on Canton; bridge layer signals the burn to XDC mainnet; XDC is unstaked through the standard XDC validator unbonding flow and returned to the holder.
### What hstXDC is not * **Not a wrapped token.** `hstXDC` is not a 1:1 wrapper of XDC on a different chain. It is a liquid staking token: it represents a *staked* XDC position, and its exchange rate against XDC drifts upward over time as native yield accrues to the underlying. * **Not a cross-chain asset.** XDC stays on XDC. `hstXDC` lives on Canton. There is no XDC token crossing the bridge layer — only attestations of stake state. This is the load-bearing security choice (see sec5). * **Not custodial.** Helix does not hold customer XDC in a Helix-controlled wallet. The vault contract holds delegations on-chain with constrained admin keys, and the bridge layer is protected by a threshold-signature attestor design pattern (see sec5, sec8). * **Not yet live.** hstXDC is in the architecture and scoping phase as of April 2026. Helix's Canton-side infrastructure is already in production (see sec10); the hstXDC vault is in design. Honest status disclosure is in sec2 — no claims of shipped functionality before there is shipped functionality. ### Why this matters for institutional users The full institutional thesis lives in sec6 and sec7. The three-sentence version: 1. A holder of locked institutional Canton-side positions and a holder of staked XDC can now operate both positions through a single Canton-side surface, without the value-bearing assets ever crossing a bridge committee. 2. The bridge layer carries authorization signals only — not the assets themselves — which collapses the institutional custody question to *"who custodies the XDC on XDC, and who custodies the LST on Canton."* 3. BitGo qualified custody covers both ends as of March 25 2026. The custody question is already answered. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.helixlabs.org/getting-started-on-helix/what-is-hstxdc.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.