Hub Decentralization

Overview

xchain-hub has evolved from a centralized config oracle into a fully decentralized validator network across nine implementation phases. Phases 0–5 shipped v1.0.0 → v2.0.0; Phase 6 (capability model + external attestation framework, 2026-05), Phase 7 (federation key rotation + quorum hardening, 2026-06), and Phase 8 (full-node verified tier: full_node capability, FullNodeChallengeRound, NODEPROOF verdicts, 2026-06) are all complete.

Motivation

Single point of failure

A centralized hub means the entire platform degrades when the hub process crashes or its database becomes unavailable. Services that cannot reach the hub fall back to stale local config or fail their startup checks. Cross-chain swaps stall until the hub recovers.

Single point of trust

A centralized hub operator controls configuration for all services. In a self-hosted deployment this is acceptable, but it creates a trust assumption that is difficult to remove as the platform grows. A malicious or misconfigured hub could redirect services to wrong endpoints or manipulate pricing data.

Scalability ceiling

A single-instance hub has limited horizontal scaling options. Under high coordination load (many concurrent cross-chain swaps), the hub becomes a bottleneck.

Capability Model

The validator network uses a capability model rather than fixed tiers. A validator stakes XCHAIN against an Ed25519 signing pubkey; that pubkey’s aggregate active stake auto-qualifies it for each of five independent capabilities whose min_stake it meets:

A single pubkey can hold any combination of capabilities, there is no overlap restriction. min_stake[capability] is governance-configurable; defaults are set by hub config. The historical model where the cross-chain tier required 5× the oracle stake is preserved by appropriate min_stake defaults but the protocol does not enforce a hierarchy.

price: Price Oracles

Validators with the price capability independently fetch cryptocurrency prices from multiple external sources (CoinGecko and Kraken are both keyless and always active; CoinMarketCap is optional when an API key is configured), submit them to the network, and reach consensus using a trimmed median algorithm (discard top/bottom 15%). This replaces centralized pricing with a manipulation-resistant oracle feed. Price rounds run on a configurable interval (default 10 minutes). Each round goes through: fetch → submit → collect → aggregate → PBFT finalize.

cross_chain: Cross-Chain Validators

Validators with the cross_chain capability attest to cross-chain swap actions. Rather than running full decoder and indexer stacks for every chain, they use xchain-sync to replicate indexer + decoder databases, keeping them lightweight. Consensus is calculated per chain-pair; only validators supporting both chains in a swap participate in attestation, using a PBFT-derived consensus requiring max(2f+1, ceil((N+1)/2)) agreement (simple-majority floor; see Quorum below).

oracle_publish: PRICE v0 Broadcasters

After a price round PBFT-finalizes, a validator with oracle_publish broadcasts the signed round on-chain (typically to DOGE for low tx fees). Leader rotation among oracle_publish-capable validators is deterministic via SHA256(round_number || pubkey) ordering with cascading failover at each subsequent block.

attestation: External Attestation Framework

Validators with attestation serve ATTEST v0 (request) actions emitted by VM contracts via xchain.attestation.request(...). Responsible-set selection is deterministic via SHA256(request_id || pubkey) ordering; the top redundancy validators fetch from the named provider (http_get or llm) and reach PBFT consensus on the response. Two consensus strategies are supported: byte_equality (all responses must be identical, used by http_get) and judge_model (an LLM judges semantic equivalence, used by llm). The signed bundle is submitted on-chain as ATTEST v1 (response), which fires the requesting contract’s callback EXECUTE.

Block-boundary snapshots

Every PBFT engine (config, oracle, attestation, cross-chain) locks its quorum at a specific block_index via CapabilitySnapshot.getSnapshot(capability, block_index). This queries the indexer’s getcapabilityvalidators RPC (60s cache) so every hub in the federation sees the same qualified set even as stake drifts mid-round. Self-tests are local to each hub; a failed self-test means the validator skips the round but is still counted in N (laggards get slashed for non-participation).

Staking and Governance

All staking operations (STAKE, UNSTAKE, DELEGATE, COLLECT) are standard XChain actions on the BTC chain, processed by the indexer. STAKE comes in two semantic versions (VERSION=1 new stake, VERSION=2 top-up of an existing pubkey); both wire to VERSION|AMOUNT|SIGNING_PUBKEY. Active stake for a pubkey is SUM(amount) across rows where activation_block ≤ now < COALESCE(deactivation_block, +∞).

Note: Capability staking above is BTC-only, so the activation/deactivation delays are stated in BTC blocks (~1 hour). Contract-targeted staking (STAKE v3 / UNSTAKE v1 / DELEGATE v1/v3) runs on every chain and calibrates this delay per chain for equivalent ~60-min reorg protection (6 blocks on BTC, 24 on LTC, 60 on DOGE) since a flat 6 blocks would give DOGE only ~6 minutes. See protocol/Contract_Staking.md. | Cooldown | 1000 BTC blocks before staked XCHAIN returns to source (configurable via STAKING.COOLDOWN_BLOCKS) | | Delegation | Token holders can delegate stake to existing validators | | Rewards | Proportional to stake and participation per capability. A pubkey holding both price and oracle_publish earns both per-round (consensus + broadcast). |

Decentralized Roles

Transport auth follows on-chain key rotation

A validator’s P2P signing key is authorized by the union of the hub’s local validator registry and the on-chain effective signer set (polled from getactivevalidators at the BTC tip every 30 s, never fail-open). So when a validator rotates its signing key on-chain via DELEGATE, every peer’s transport auth follows automatically within one poll interval. No hand-edited registry on each hub. The operator procedure is in Operations → Validator Key Rotation.

Implementation Phases

Architecture Summary

flowchart TD
    EXT["External APIs<br>(CoinGecko, Kraken, CMC)"]
    A["Validator A<br>PriceFetcher → OracleRound<br>PeerManager ↔ Consensus<br>CrossChainEngine<br>ReorgHandler<br>Governance<br>RewardTracker<br>SlashDetector"]
    B["Validator B<br>(same stack)"]
    C["Validator C<br>(same stack)"]

    EXT --> A
    A -->|gossip| B
    B -->|gossip| C

Each validator runs the full hub stack. Communication happens via WebSocket-based P2P gossip with Ed25519-signed messages. All consensus decisions require max(2f+1, ceil((N+1)/2)) agreement; the simple-majority floor prevents a single validator from finalizing alone at small federation sizes (N=3 requires 2 votes; N=2 requires both).

Quorum

max(2f+1, ceil((N+1)/2)) where f = floor((N-1)/3), tolerates f Byzantine validators out of N total. The simple-majority floor matters for small federations: bare 2f+1 degenerates to a quorum of 1 at N=3 (f=0), which would let a single validator finalize alone. With the floor, N=3 requires 2 votes and N=2 requires both.

Related

• Hub: hub architecture and API reference
• Architecture: internal subsystem design
• Cross-Chain Concepts: how cross-chain swaps work at the protocol level
• Gas Token: the XCHAIN token used for staking and fees

Copyright © 2025–2026 Dankest, LLC

Based on XChain Platform by Dankest, LLC – https://dankest.llc

Licensed under the GNU Affero General Public License v3.0 (AGPL-3.0-or-later) with a commercial license available for proprietary use.

You may use, modify, and distribute this material under the terms of the License. See LICENSE and NOTICE for full terms. See the licensing overview.