# Security Model > Security in hstXDC is the combination of three independently verifiable layers: the XDC-side delegation lifecycle (which inherits XDC's BFT consensus security), the bridge attestor network (which inherits threshold-cryptography security from FROST/TSS), and the Canton-side vault contracts (which inherit Canton's multi-party authorization and synchronizer security). This section walks each layer, the failure modes each one is designed against, and the mainnet readiness gates that have to clear before any institutional capital is at risk. ### The trust perimeter The first thing an institutional reader needs to know is **where the security boundaries actually sit** -- which actor can do what, and what happens when each kind of compromise occurs. | Layer | Trust root | What a compromise can do | What a compromise CANNOT do | | --------------------------------------- | -------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **XDC consensus** | 108 KYC validator masternodes, BFT finality | Halt the chain (requires >1/3 adversarial); equivocate (slashable, on-chain forensic evidence) | Mint hstXDC. Move user XDC out of the vault contract. Bypass the unbonding window. | | **XDC-side vault contract** | Solidity contract on XDC mainnet, immutable in v1 | Nothing -- the contract has no owner-controlled mint or transfer function. The contract is parameter-update-only via the operator multi-sig, and the operator multi-sig cannot move user funds. | Mint hstXDC. Move user XDC. Authorize unstakes that the bridge attestor network has not signed. | | **Bridge attestor network** | FROST/TSS threshold signature over a distributed attestor set, target `t-of-n` where `t ≥ floor(2n/3)+1` | Refuse to sign (denial-of-service on mints and redemptions); produce false attestations only if the threshold is reached simultaneously across geographically distributed operators | Mint hstXDC without an underlying XDC deposit (the Canton-side contract verifies the attestation against the XDC-side event). Steal user XDC (the attestor network does not custody assets). | | **Canton-side vault contract** | Daml workflow on a dedicated synchronizer, multi-party authorization | Operator can update vault parameters and pause new mints | Mint hstXDC without bridge attestor co-signature. Move holder hstXDC. Bypass holder-initiated burn. | | **Helix operator multi-sig** | 3-of-5 across geographically distributed key holders (target) | Update vault parameters; pause new deposits; trigger circuit breakers | Mint or move user assets. Substitute for the bridge attestor signature. Accelerate unbonding. | | **BitGo qualified custody (both ends)** | BitGo Bank & Trust, federally chartered US entity, MPC architecture, $250M insurance | Custody the assets per institutional custody arrangements with the holder | Anything outside the holder's custody instructions | | **The holder** | Individual depositor | Deposit XDC, transfer hstXDC, initiate redemption | Mint hstXDC outside the deposit flow. Bypass the unbonding window. | **The two load-bearing rules** (repeated from sec4 because they are the entire security thesis): 1. **No single key can mint hstXDC.** Mint authorization requires the threshold-signed attestor set to produce an attestation. The operator multi-sig is a separate role and cannot substitute for the attestor set. 2. **No admin role can move user assets.** Admin powers are limited to parameter updates and circuit-breaker controls. Moving holder XDC, holder hstXDC, or the underlying delegation requires the standard user-initiated flows. If both rules hold, the worst case for an admin compromise is denial of service (operator can pause mints, attestor network can refuse to sign), not loss of user funds. ### Bridge attestor network -- security properties The bridge layer is the part of the architecture an adversarial reader will probe hardest. The honest specification of its security properties: | Property | Target | | ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Threshold scheme** | FROST (Flexible Round-Optimized Schnorr Threshold Signatures) -- the same scheme used by cBTC on Canton today | | **Threshold ratio** | `t-of-n` where `t ≥ floor(2n/3)+1` (Byzantine fault tolerant against up to `n - t` adversarial attestors) | | **Attestor set composition** | Geographically and jurisdictionally distributed institutional operators. Specific composition under design; partner alignment in progress. | | **Key generation** | Distributed key generation -- no trusted dealer, no single party ever holds the full secret | | **Signature aggregation** | Schnorr aggregation produces a single on-chain signature regardless of `n`, minimizing on-chain verification cost | | **Compromise model** | Requires simultaneous compromise of `n - t + 1` attestors. Geographic and jurisdictional diversification raises the practical cost of this attack significantly above the theoretical threshold. | | **Failure mode under compromise** | An adversary that reaches the threshold can produce false attestations -- mint hstXDC against fake XDC deposits, or authorize unstakes against fake Canton burns. **This is the worst-case failure of the bridge layer.** | | **Mitigation against the worst case** | (a) Threshold set high enough to make compromise economically and operationally infeasible; (b) on-chain attestation verification on both sides ensures attestations are tied to verifiable source-chain events; (c) circuit breaker on the operator side can pause new mints if a compromise is suspected pending forensic investigation | The cBTC precedent on Canton uses exactly this design and has been in production with BitGo qualified custody since March 25 2026. The security properties of hstXDC's bridge attestor network are not novel -- they are the same properties cBTC's institutional reader has already evaluated and accepted. ### XDC-side delegation lifecycle and slashing The hstXDC vault on XDC delegates user XDC to one or more masternodes. XDC's slashing model affects masternode operators, not delegators: | XDC slashing condition | Who is slashed | hstXDC vault impact | | ------------------------------------------------------------- | --------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Masternode equivocation (signing two blocks at the same step) | Masternode operator's stake (up to full burn) | Delegated stake is not slashed. The vault's underlying XDC is not at risk. The masternode is removed from the validator set; the vault's delegation is reassigned through the standard XDC delegation flow. | | Masternode underperformance | Masternode operator excluded from rewards (no token loss) | Vault's XDC continues to earn yield through the remaining active validators; no holder loss | | Network-level fault (>1/3 adversarial) | Chain-wide consensus halt | All hstXDC operations pause until XDC consensus resumes; no holder loss | **The hstXDC architecture inherits XDC's delegator-not-slashable property.** This is a structural protection -- the vault contract does not need to manage slashing exposure because the chain does not slash delegated stake. The only operational risk on the XDC side is masternode selection, which the vault contract manages through the standard delegation lifecycle. ### Canton-side privacy and synchronizer security The Canton-side vault inherits two security properties from the underlying Canton infrastructure: 1. **Sub-transaction privacy** -- holder positions and balances are visible only to authorized parties (the holder, the operator, the bridge attestor party, and any party the holder explicitly grants visibility to via CIP-56 transfer or DvP workflows). The hstXDC vault does not leak position-level data to Canton-wide observers. 2. **Synchronizer security** -- the dedicated synchronizer hosting the hstXDC vault is operated by the Global Synchronizer Foundation's Super Validator set (or a partner-operated synchronizer for institutional deployments; under design). The synchronizer security model is the standard Canton consensus model. The privacy model is what allows hstXDC to coexist on the same Canton operational surface as locked pCC, USDCx, cBTC, and other CIP-56 assets without leaking inter-position data. This is also what makes the bridge attestor network's "authorized observer party" pattern necessary -- see sec5 for the design rule. ### Audit status | Component | Audit status | | --------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **XDC-side vault contract (Solidity)** | Not yet implemented. Audit scheduled before any testnet-to-mainnet promotion. | | **Canton-side vault contracts (Daml)** | Audit scheduled | | **Bridge attestor software** | Not yet implemented. Audit scheduled before any testnet activation. | | **FROST library selection** | Under evaluation. Production-grade FROST implementations exist; the selection criterion is library maturity, audit history, and Schnorr-on-secp256k1 compatibility for the XDC side. | | **Helix Canton track infrastructure (currently in production)** | The CIP-0105 dashboard and observation-first vault on Canton are in production today. Audit posture for that infrastructure is documented separately in the sec10 credibility anchors. | **hstXDC v1 will not deploy to mainnet without independent audit of all three contract layers.** This is a hard gate, not a soft commitment. The audit-vendor selection is in progress; named auditors will be disclosed. ### Mainnet readiness gates The build phases in sec2 specified gates between phases. The mainnet readiness gate is the strictest -- it consolidates every security check that has to pass before institutional capital is accepted: | Gate | Specific criterion | | ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Contract audit clean** | All three contract layers (XDC-side, Canton-side, bridge attestor software) audited by an independent auditor with no unresolved high-severity findings | | **Testnet end-to-end** | Full deposit-mint-yield-redeem-unstake cycle proven on XDC testnet and Canton DevNet, including the bridge attestor flow, with no unresolved bugs | | **Attestor set finalized** | Attestor set composition, signing threshold, key generation ceremony, and operational runbooks complete and exercised in a key generation rehearsal | | **Circuit breaker tested** | Operator multi-sig pause-and-resume exercised on testnet with realistic fault scenarios | | **Custody integration** | BitGo (or alternate qualified custodian) integration tested for both XDC-side and Canton-side asset flows | | **Smoke test on mainnet** | Initial mainnet deployment with capped position size, exercised by a small institutional partner cohort, before opening to general institutional onboarding | | **Incident response runbook** | Documented response procedures for the failure modes in the trust perimeter table, with named on-call contacts and partner notification procedures | **The gate is binary.** Until every row clears, the architecture is not mainnet-ready. ### Incident response posture If a security incident occurs in the live system, the response posture is: 1. **Operator multi-sig pauses new mints immediately** via the circuit breaker. Existing positions are unaffected; redemptions continue to function. 2. **Attestor network is notified** via the operational runbook; attestors halt new attestations pending investigation. 3. **Affected partners are notified** via direct communication on the documented runbook contact path. 4. **Forensic investigation** identifies the compromise vector. Public disclosure follows once the vector is understood and the investigation does not put other counterparties at risk. 5. **Recovery action** depends on the vector. The architecture is designed so that the worst case is denial of service, not silent loss -- the holder's underlying XDC remains in the on-chain vault contract throughout. The full incident response runbook is a partner-specific document, not a public artifact. This section is the high-level posture only. ### What this section deliberately does not claim | Topic | Why we are not claiming it | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Specific audit firm or audit completion date** | Audit vendor selection is in progress. Named auditors will be disclosed when engaged. We will not pre-announce a relationship that is not yet contracted. | | **Specific attestor operator names** | Attestor set composition is under design and depends on partner alignment. Public naming of candidates before commitment risks misrepresenting the set. cBTC's precedent of naming Kiln and Figment publicly happened *after* the operators were committed -- we will follow the same convention. | | **Formal verification of contracts** | Formal verification is under consideration for the highest-risk components (the mint authorization path on Canton, the unstake authorization path on XDC). It is not committed. We will not claim formal verification we have not performed. | | **Insurance coverage of the bridge layer** | BitGo's $250M insurance covers custody on both ends. Insurance for the bridge layer itself (an attestor compromise scenario) is a separate question; coverage options are under discussion. We will not claim insurance coverage we have not verified. | ***