# Status > **Where hstXDC is right now (April 2026):** in architecture and scoping. The Canton-side infrastructure that hstXDC depends on is already in production; the hstXDC-specific vault and bridge layer are in design. This section is the honest disclosure -- what exists, what doesn't, what we're building toward, and what user expectations should be calibrated to. ### What's live today | Component | Status | Where to verify | | ---------------------------------------------------------------- | -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | **Helix Canton SV compliance dashboard** | LIVE | [vault.helixlabs.org/sv-locking](https://vault.helixlabs.org/sv-locking) -- public, ungated, CIP-0105 SV compliance observation surface | | **Canton-side observation-first vault architecture** | PRODUCTION (deployed) | Active package `helix-v2g` on the Canton mainnet path; see sec10 for credibility anchors | | **CIP-56 token standard on Canton** | PRODUCTION ecosystem-wide | Used by cBTC and USDCx, the two production Canton↔external bridges; see sec5 for prior-art context | | **Native USDC + Circle CCTP V2 on XDC** | LIVE since September 2025 | xdc.org primary source; see sec7 | | **BitGo qualified custody — XDC mainnet (XDC + USDC)** | LIVE since February 1 2026 | $250M insurance, MPC custody, BitGo Bank & Trust | | **BitGo qualified custody — Canton CIP-56 assets (cBTC, USDCx)** | LIVE since March 25 2026 | The same regulated entity custodies both ends; see sec6 | The institutional plumbing hstXDC depends on is **already there**. We are not waiting on Circle, BitGo, the Canton CIP-56 standard, the XDC EIP-1559 / Cancun upgrade, or qualified-custody coverage. None of those are gates. ### What's in design | Component | Status | Notes | | ----------------------------------------------- | ------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **hstXDC vault contracts (Canton side)** | DESIGN | Daml templates specified; contract authorization model worked through; awaiting implementation. See sec4. | | **XDC-side staking integration** | DESIGN | Masternode delegation flow scoped against XDC's standard validator unbonding lifecycle. | | **Cross-chain bridge layer (attestor network)** | DESIGN | Architecture choice resolved (hybrid issuer-attested + threshold-signature attestor net); attestor set composition and signing thresholds in scoping. See sec5. | | **Recursive staking loop (v1.1)** | DESIGN | Loop closure depends on USDC-denominated lending markets on XDC reaching adequate depth. v1 ships without the loop. See sec4. | ### What is explicitly out of scope (today) * A general-purpose Canton ↔ XDC smart-contract messaging bridge. hstXDC's bridge layer is purpose-built for stake-state attestation, not general state transport. A general bridge is a possible future expansion, not a v1 commitment. * A Helix-issued stablecoin on either chain. We use Circle's native USDC + CCTP V2 throughout. We are not in the stablecoin issuance business. * Custody of customer XDC in a Helix wallet. The vault contract holds the delegation directly on XDC mainnet with constrained admin keys; custody is via BitGo or the holder's preferred qualified custodian, not Helix. * Wrapped XDC on Canton. `hstXDC` is a *liquid staking token*, not a wrapper. There is no `xXDC` or `wXDC` in the architecture. ### Build phases The hstXDC build is structured in phases. Each phase has a hard gate before the next begins. | Phase | Scope | Gate to next phase | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------- | | **Phase 0 — Architecture & scoping** *(current)* | Daml templates specified, bridge layer architecture chosen, security model designed, partner alignment with the XDC Foundation | Architecture document accepted; engineering resources allocated | | **Phase 1 — Vault contracts on Canton** | hstXDC Daml templates implemented, tested in Canton DevNet, exercised through standard mint/burn flows | Internal contract review + external review | | **Phase 2 — XDC-side integration** | Vault contract on XDC mainnet, masternode delegation lifecycle wired through, deposit/withdraw exercised on XDC testnet | XDC testnet deposit-mint-redeem cycle proven end-to-end | | **Phase 3 — Bridge layer activation** | Threshold-signature attestor set deployed, end-to-end mint and burn proven across the bridge layer on testnet | Attestor set composition finalized, security review completed | | **Phase 4 — Mainnet readiness** | Mainnet deployment, qualified custody integration, institutional onboarding flow | Audit completion, mainnet smoke test, first institutional deposit | We do not give public dates for phase transitions in this document. Build pace is communicated to active partners directly. If you are evaluating hstXDC for a specific timeline, contact us — see sec10. ### Honest read for the institutional user 1. **The dependencies are mature.** Every external system hstXDC needs is already in production. We are not betting on a future Circle launch, a future BitGo expansion, a future Canton standard, or a future XDC upgrade. 2. **The Helix Canton track is live and observable.** You can verify our Canton execution capacity at vault.helixlabs.org/sv-locking today. hstXDC is not Helix's first piece of Canton infrastructure. 3. **The hstXDC vault itself is not yet built.** This is a scoping-phase document. If you need a live mainnet hstXDC contract address, that does not exist yet. If you need an architecture you can review, audit, and commit to before contracts are written — that is exactly what these docs are for. 4. **The build sequence has hard gates, not soft milestones.** We do not move to the next phase before the previous phase clears its gate. You can ask us about gate criteria specifically; we will answer specifically.