What is hstXDC

Section 1 (sec1)

• 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

Layer	What happens
Deposit	Institutional holder deposits XDC into the Helix Vault contract on XDC mainnet. XDC enters the masternode delegation flow and accrues native staking yield.
Mint	Bridge 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.
Hold	The 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.
Redeem	Holder 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.