# Open Design Questions > Every architecture document has a section it would prefer to leave out. This is that section. The questions below are the design choices that hstXDC is still resolving as of April 2026, where the answer depends on external factors (partner alignment, ecosystem maturity, audit results) rather than on engineering effort alone. Listing them publicly is a credibility choice -- a partner doing DD will identify these gaps anyway, and the only thing worse than a known unknown is a hidden one. ### Bridge layer composition | Question | Why it's open | Resolution gate | | -------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Attestor set composition** -- specifically, which institutional operators run the FROST attestor nodes | Depends on partner alignment. Candidate operators include institutional staking providers, regulated custodians, and partner-aligned validator operators. The selection criterion is geographic and jurisdictional diversification, not the absolute number of nodes. | Final composition committed before any testnet activation of the bridge layer (see sec8 mainnet readiness gates). Public disclosure follows commitment, not negotiation. | | **Signing threshold** -- the exact `t-of-n` for the attestor set | Depends on the final attestor set size. Target ratio is `t ≥ floor(2n/3)+1`. Concrete values follow once `n` is committed. | Same gate as attestor set composition. | | **FROST library selection** | Production-grade FROST implementations exist in Rust. Selection criterion is library maturity, audit history, Schnorr-on-secp256k1 compatibility for the XDC side, and operational tooling for the key generation ceremony. Evaluation in progress. | Locked before bridge attestor software audit begins. | ### Canton-side deployment | Question | Why it's open | Resolution gate | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | **Synchronizer choice** -- whether the Canton-side hstXDC vault deploys on the Global Synchronizer Foundation production synchronizer, or on a dedicated synchronizer operated by hstXDC's institutional partners | Both options are technically viable. The GSF synchronizer minimizes operational overhead and inherits the existing Super Validator security model. A dedicated synchronizer offers execution isolation and partner-operator control, at the cost of running additional infrastructure. Choice depends on institutional partner preferences. | Resolved during partner onboarding for the first institutional deployment. The architecture is forward-compatible with both options. | | **Upgrade authority on the Canton side** | Daml package migration provides a structured upgrade path on Canton, but the authority model for triggering migrations is under design. Options range from "operator multi-sig with timelock" to "immutable v1, all upgrades require migration to a v2 vault with explicit holder consent." | Locked before mainnet deployment. | ### XDC-side deployment | Question | Why it's open | Resolution gate | | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | | **Mainnet vs Subnet for the XDC-side vault** | The v1 default is XDC mainnet for visibility and inheritance of XDC's standard validator selection. A Subnet deployment is documented as an alternate (see sec3) for partners who prefer execution isolation. Both options can coexist for different partner cohorts. | Mainnet is the v1 default. Subnet variant is available on partner request without architectural changes. | | **Upgrade authority on the XDC side** | The v1 intent is an immutable Solidity contract on XDC mainnet. This eliminates the "who can upgrade the vault" risk surface entirely. A v2 vault requires migration via standard contract redeployment and explicit holder consent. The trade-off is operational rigidity in exchange for the strongest possible security posture on the XDC side. | Locked before XDC-side contract audit. | ### Operator and governance | Question | Why it's open | Resolution gate | | -------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- | | **Operator multi-sig key holder geographic distribution** | Target is 3-of-5 across geographically distributed key holders. Specific jurisdictions and institutional roles for each key holder slot are under partner alignment. | Locked before mainnet deployment. | | **Circuit breaker threshold** -- specifically, what triggers an operator pause vs an attestor halt | The current draft has the operator multi-sig as the parameter-update path and the attestor network as the attestation-halt path. The interaction between the two during an incident response is documented in the runbook (see sec8) but the trigger conditions are under refinement based on the incident response posture finalization. | Locked alongside the incident response runbook. | ### Ecosystem dependencies (not under hstXDC's control) These are not hstXDC design questions strictly speaking -- they are questions about the surrounding ecosystem that hstXDC's v1.1 expansion depends on. Listing them here so the institutional reader has a complete picture of where the dependency edges sit. | Question | Owner | Why it matters | | ------------------------------------------------------------------------- | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Canton-side lending venue acceptance of `hstXDC` as collateral** | Canton ecosystem (lending venues, not hstXDC) | The v1.1 recursive staking loop requires a Canton-side lending venue that accepts CIP-56 collateral, including `hstXDC`. Multiple venues are in development; specific timelines are venue-side decisions. v1 ships independently. | | **USDT live status on XDC** | XDC Foundation / Tether | Bridged USDT on XDC was announced in late 2024 as a follow-on to USDC. As of this document's date, no primary source confirms USDT live on XDC mainnet. Not a hstXDC dependency, but an open question for partners whose strategy depends on stablecoin diversity. | | **Additional qualified custodians for Canton CIP-56 assets beyond BitGo** | Custodian ecosystem | BitGo is the only US qualified custodian currently supporting both XDC and Canton CIP-56 assets. Additional custodians (DFNS for Canton, others) may extend coverage over time. Not a v1 gate. | ### What this section deliberately does not include | Topic | Why we are not publishing it | | ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | | **Specific candidate names for the attestor set** | Naming candidates publicly before commitment misrepresents the relationship. Following the cBTC convention of public disclosure after commitment. | | **Specific candidate names for the operator multi-sig key holders** | Same reason. | | **Specific audit vendors under consideration** | Vendor selection is in progress; pre-announcement of relationships not yet contracted is not appropriate. | | **Specific institutional partners under DD** | Partner relationships are confidential until both parties agree to public disclosure. | The pattern across all four exclusions is the same: **public disclosure follows commitment, not negotiation.** A partner doing DD on hstXDC is welcome to ask about any of these in direct conversation, where the appropriate confidentiality framework can apply. *** **sec9 ready for your read.** Two flags: 1. **Length check** -- this came in heavier than the \~800-token target (\~1300 actual). The bridge layer composition and Canton-side deployment subsections are the densest because they are also the most important architectural questions. If you want it shorter, the cleanest cut is the "Ecosystem dependencies" subsection -- it is the least hstXDC-specific and could collapse into a single sentence cross-referencing sec7. My instinct: keep it as-is, because an institutional reader doing DD wants to see *all* the dependency edges, including the ones that aren't ours. 2. **The closing "public disclosure follows commitment, not negotiation" line** is the strongest single sentence in sec9. It is also a real commitment -- it means you have to actually follow that pattern in any public statement about partners going forward, including when the temptation to pre-announce is high. Confirm you are willing to be held to it; otherwise we soften. sec10 (Helix Canton Track Status -- the credibility anchors) is the last section. It is the lift from the tech doc Appendix A, lightly de-framed for public audience -- shows the institutional reader that hstXDC is not Helix's first piece of Canton infrastructure, that the team has live production code on Canton today, and that the relationships (Wayne, IEU, Splice contributions, BitGo CIP-56 path) exist. This is the section that closes the "but is this team real?" question for any first-time DD reader.