Node Ecosystem: Incentives, Staking, and Network Security

The Xythum Node Ecosystem is the decentralized backbone that powers and secures the entire Xythum protocol. independent node operators who stake Xythum (THUM) tokens to participate in critical network functions, including transaction validation, FROST (Flexible Round-Optimized Schnorr Threshold) consensus for asset and context transfers, maintenance of the SyncNet distributed ledger, and execution of XythumVM/DSL logic and MPCaaS tasks. This document details the architecture of the node ecosystem, the economic incentives driving participation, the rigorous staking and slashing mechanisms ensuring integrity, the epoch-based management system for dynamic network composition, and the security measures safeguarding against potential attack vectors. Our design prioritizes robust security, high liveness, fair compensation, and true decentralization.

Core Principles of the Xythum Node Ecosystem:

• Decentralization: No single entity controls the network; power is distributed amongst many independent node operators.
• Security through Economic Staking: Significant THUM token stakes act as a financial guarantee against malicious behavior.
• Incentive Alignment: Rewards are structured to align the interests of node operators with the long-term health and security of the Xythum network.
• Transparency & Verifiability: Node operations, staking, rewards, and slashing events are, where feasible, publicly verifiable ( via SyncNet or on-chain registries).
• Resilience & Fault Tolerance: The system is designed to withstand individual node failures and coordinate responses to network-level threats.

Becoming a Xythum Node Operator:

• Eligibility & Requirements:
  • Hardware & Network Specifications: Minimum hardware (CPU, RAM, storage) and network bandwidth requirements will be published to ensure optimal performance.
    • Prefer high bandwidth
    • 5TB in storage
    • 4 - 8 GB in ram

    • 3 Ghz clock speed cpu (optional)

  • THUM Token Staking: The primary requirement is to stake a minimum amount of THUM tokens.
• 3.2. The Staking Mechanism:
  • Stake Token: Only Xythum (THUM) tokens can be used for staking.
  • Minimum Stake Amount: This will be a dynamic value, initially set by the Xythum Foundation/DAO and subsequently adjustable by THUM token governance. The goal is to make the stake substantial enough to deter casual malicious actors while remaining accessible to serious participants. It will be influenced by the THUM token's market price and overall network security needs (e.g., aiming for a certain total USD value staked).
  • Node Registry Contract: Staking will occur via a smart contract . This contract will manage stake deposits, withdrawals, and track node status.
  • Bonding Period: Upon staking, there might be a short bonding period before a node becomes fully active and eligible for rewards.
  • Unbonding Period: When a node operator wishes to unstake and withdraw their THUM, an unbonding period (e.g., multiple epochs, typically 1-2 weeks) will be enforced. This period allows for:
    • Graceful network exit and shard rebalancing.
    • Final checks for any attributable malicious behavior before the stake is released.

Epoch Lifecycle & Functions:

• Node Onboarding/Offboarding: New nodes completing their stake bonding become active at the beginning of a new epoch. Nodes initiating unbonding will complete their service until the end of the current or next epoch.
• Distributed Key Generation (DKG) & Key Rotation:
  • At the beginning of each epoch, or at predefined intervals (e.g., every N epochs), a Fresh Random Oracle-based Secure Threshold Distributed Key Generation (FROST DKG) ceremony is performed by the active node set (or subsets for sharding).
  • This generates new shared cryptographic keys (group public key and individual secret shares for FROST signatures) for the upcoming epoch.
  • Regular key rotation is a critical security measure, limiting the impact of potential long-term key compromises and ensuring forward secrecy.
  • The DKG process itself involves multiple rounds of communication between nodes, with cryptographic commitments and verifications to ensure correctness and prevent manipulation.
• Shard Formation & Rebalancing (for XythumVM/DSL & MPCaaS): If Xythum utilizes sharding for its advanced computational services, epochs provide the cadence for forming new shards, assigning nodes to shards, and retiring old shards based on network load and node availability/reputation.
• Reward Calculation & Distribution: Rewards earned by node operators during an epoch are calculated at its conclusion and made available for claiming.
• Parameter Updates: Governance-approved changes to network parameters (e.g., fee structures, stake minimums) typically take effect at the start of a new epoch.

---

Sources of Rewards:

• Staking Rewards (Inflationary/Block Rewards): A portion of new THUM token emissions (if the model includes inflation) or a dedicated reward pool from the initial token supply will be distributed to active stakers proportional to their stake and uptime. This provides a baseline APY.
• Share of Protocol Transaction Fees: Active nodes participating in the validation and signing of asset/context transfers will receive a share of the protocol fees generated by these transactions (as outlined in the Business Model document).
• Fees from XythumVM/DSL Execution & MPCaaS Tasks: Nodes participating in executing multichain logic or performing MPC tasks will earn fees (paid in THUM) specifically for these computational services.
• Potential for "Uptime Bonuses": Exceptional uptime and performance could be rewarded with slightly higher reward shares.

Reward Distribution:

• Calculated at the end of each epoch.
• Distributed proportionally to the amount of THUM staked and potentially weighted by performance metrics (e.g., uptime, successful participation in DKG and signing rounds).
• Node operators will be able to claim their accumulated rewards through the Node Registry contract or a dedicated rewards dashboard.

Slashing Mechanisms: Enforcing Honesty and Reliability

• Detection of Misbehavior:
  • On-Chain Evidence: Some misbehaviors (e.g., double signing on a host chain) can be proven cryptographically on-chain.
  • Protocol-Level Monitoring (SyncNet): The Xythum network itself, via SyncNet and inter-node communication, will monitor for inconsistencies, liveness failures, and protocol deviations. The Signature Aggregator (SA) plays a role in initial detection during signing rounds.
  • Challenge-Response Mechanisms: Potentially allow honest nodes to challenge and provide proof of another node's misbehavior.
• Types of Slashing & Triggers:
  • Partial Slashing ( 1-10% of stake, decided by governance):
    • Submission of Improper/Malformed Commitments during DKG: Attempting to disrupt or compromise the generation of new cryptographic keys. This is usually detectable through cryptographic verification steps in the DKG protocol.
    • Minor Liveness Failures / Extended Downtime: Consistently failing to participate in consensus rounds or respond to network requests beyond a tolerated threshold, impacting network performance.
    • Refusal to Sign Valid Transactions: If a node, or a minority of nodes, refuses to sign a transaction that has been validated by a clear majority and is protocol-compliant. This is identified through the FROST signing process.
    • Slashed Amount: May be burned or redistributed to the protocol treasury or to compliant nodes.
  • Full Slashing (100% of stake):
    • Provable Malicious Signature Submission / Double Signing: Generating or submitting signatures that attempt to authorize fraudulent transactions (e.g., minting unbacked assets, stealing user funds). This is the most severe offense.
    • Active Participation in Confirmed Network Attacks: If a node is identified as part of a coordinated attack (e.g., a 51% attack on a shard, or a Sybil attack to compromise DKG). This is detected by the SA and cross-verified by other nodes.
    • Severe DKG Sabotage: Deliberately and provably disrupting the DKG process in a way that prevents key generation for an epoch.
    • Data Withholding/Censorship (if provable): Systematically refusing to propagate valid messages or transactions within a shard or the broader network.
    • Slashed Amount: Typically burned to reduce total supply or significantly redistributed to the treasury for make-whole programs or to greatly reward honest network participants.

Slashing Process:

1. Detection of potential misbehavior.
2. Evidence gathering and verification (can be automated or involve a challenge period).
3. Execution of slashing via the Node Registry smart contract.
4. The offending node is typically removed from the active set and may be subject to a ban period before being allowed to re-stake (if ever).