Two Ways to Stake QCH
There are two ways to participate in QuanChain's Proof of Coherence consensus: run a validator node yourself or delegate your QCH to an existing validator. Both earn staking rewards. The difference is in hardware requirements, operational complexity, and how much control you have over your validator's performance score.
Running a validator gives you direct control over the 50% performance component of Proof of Coherence. Your uptime, block proposal latency, and signature accuracy all feed into your score. A high-performance validator earns more per QCH staked than a low-performance one, which means hardware investment has a direct return. Delegation is simpler: you choose a validator, lock your tokens, and earn a proportional share of that validator's rewards minus their commission.
This guide covers both paths in detail.
Minimum Stake Requirements
The minimum stake to operate a validator is 50,000 QCH. This must be locked in the staking contract before the validator node generates its first block. There is no maximum stake per validator, but the Proof of Coherence weight formula caps the stake component's contribution so that no single validator can dominate the network through stake alone.
Delegators have a minimum delegation amount of 100 QCH. There is no maximum. Delegated tokens count toward the validator's stake weight in the Proof of Coherence score calculation, benefiting both the delegator and the validator.
Both validators and delegators face the same 14-day unbonding period when withdrawing stake. During unbonding, tokens do not earn rewards and cannot be transferred. Plan liquidity requirements around this window.
Hardware Requirements for Validators
The performance component of Proof of Coherence makes hardware a direct factor in rewards. A validator that drops below 99% uptime or misses block proposals due to CPU/network bottlenecks will score lower on the performance dimension, which reduces their rewards proportionally. Running adequate hardware is not optional if you want competitive APY.
Minimum recommended specs for a production validator:
- CPU: 16 physical cores at 3.0 GHz or faster (AMD EPYC or Intel Xeon recommended; ML-DSA-87 signature generation is CPU-intensive)
- RAM: 64 GB ECC RAM minimum, 128 GB recommended for comfortable operation at peak Channel 1 and Channel 2 load
- Storage: 2 TB NVMe SSD for the full node database, with RAID-1 redundancy recommended for uptime guarantees
- Network: 1 Gbps dedicated uplink with less than 10 ms latency to at least 3 geographically distributed peers; network latency directly affects block proposal latency scoring
- OS: Ubuntu 22.04 LTS or later, Debian 12 or later
Running a validator on consumer hardware (a desktop PC or home internet connection) will result in a performance score significantly below the top quartile and correspondingly lower rewards. Dedicated cloud instances (AWS c6a.8xlarge, GCP c2-standard-16, or equivalent) are the most common production setup.
Setting Up a Validator Node
The following is a high-level walkthrough of the setup process. Full documentation with exact commands is available in the QuanChain node documentation. If you want to test your setup before committing real stake, use the live testnet first.
Step 1: Install the node software. Download the latest QuanChain node binary from the official GitHub release page. Verify the binary's SHA-256 checksum against the published value before running it. The node binary includes the full validator stack: block production, mempool management, and Channel 1/2/3 processing.
Step 2: Initialize the node and sync the chain. Run quanchain-node init --network mainnet to initialize the data directory. Use fast sync mode for initial chain download: quanchain-node sync --mode fast. Full archive sync takes 12-18 hours on the minimum hardware spec. Fast sync completes in 2-4 hours.
Step 3: Generate validator keys. Generate your validator signing keypair using ML-DSA-87: quanchain-node keygen --scheme ML-DSA-87 --output ./validator-keys. This produces a validator public key and an encrypted private key file. Store the private key file offline in at least two locations. The public key is what you register on-chain. Your validator signing key is separate from your staking deposit key: the signing key must be hot (on the server), but the deposit key can remain cold (on a hardware wallet).
Step 4: Deposit stake. Using your deposit key (cold wallet), submit a validator_registration transaction with your validator public key and a minimum of 50,000 QCH. This transaction locks your stake and registers your validator as a candidate for selection. The validator is in "pending" status until the next epoch boundary (every 1,024 blocks).
Step 5: Configure monitoring. The Proof of Coherence performance score updates every epoch. Set up monitoring for uptime (use a process supervisor like systemd plus an external uptime monitor), block proposal success rate (track via the node's built-in metrics endpoint at localhost:9090/metrics), and peer count (a healthy validator maintains 25+ peers). Set alerts for uptime below 99.5% and peer count below 10.
How Delegation Works
Delegation lets QCH holders earn staking rewards without operating a node. You choose a validator from the active validator set, delegate your QCH, and earn rewards proportionally minus the validator's commission rate. Commission rates are set by individual validators and are visible on-chain; typical rates range from 5% to 15% of earnings.
To delegate, submit a delegate transaction from any QCH wallet. Specify the validator's address and the amount to delegate. Your tokens lock immediately and begin earning rewards at the next epoch boundary. You retain custody of your tokens: the delegation is recorded on-chain but your tokens are held in the staking contract, not transferred to the validator. The validator cannot spend your stake.
When choosing a validator, look at three numbers: their current performance score (higher is better, max is 1.0), their commission rate (lower means more of the reward comes to you), and their total delegated stake (very large validators may produce marginally lower per-token returns if their stake weight exceeds their performance score). All three are available through the QuanChain explorer.
Reward Distribution Timing
Rewards accumulate per epoch (every 1,024 blocks, roughly every 5 minutes at current block times). At each epoch boundary, the protocol calculates each validator's Proof of Coherence score, distributes the epoch's reward pool proportionally across validators (weighted by score), and credits each validator's reward account. Validators then distribute delegator rewards according to each delegator's proportional share, minus commission.
Rewards do not auto-compound by default. To compound, you must submit a restake transaction claiming your accumulated rewards and re-delegating them. Some validator interfaces offer automated compounding as a service. If you compound manually, the optimal frequency depends on your QCH balance: more frequent compounding increases gas costs relative to the compounding benefit for small balances.
Slashing Conditions
QuanChain slashes stake for two categories of behavior: safety faults and liveness faults.
Safety faults are actions that could cause the network to finalize conflicting states. Double-signing (signing two different blocks at the same height) is the primary safety fault. The slash penalty is 10% of total stake (validator plus delegated), and the validator is permanently banned from the active set. There is no appeal process for double-signing. Double-signing is typically caused by running two validator instances with the same signing key: never run duplicate validators.
Liveness faults are failures to participate. If a validator misses more than 50% of its expected block proposals in a 7-day window, it receives a 0.5% slash and a 7-day suspension. Repeated liveness faults escalate: a second offense within 30 days incurs a 2% slash and 30-day suspension. A third offense incurs a 5% slash and permanent removal from the active set.
Delegators share in all slashing events proportionally to their stake. If a validator is slashed 10% for double-signing, delegators lose 10% of their delegated stake too. Choose validators carefully. A high commission rate from a stable, high-uptime operator is better economics than a low commission rate from an operator with poor liveness history.
How to Unstake
Both validators and delegators initiate unstaking via an undelegate or unstake transaction. This begins the 14-day unbonding period. During unbonding, your tokens do not earn rewards. At the end of the 14-day period, they are automatically returned to your wallet balance.
You cannot cancel an unbonding request once submitted. If you change your mind, you must wait for the unbonding to complete and then re-stake. Plan stake movements around this window: if you are moving delegation from one validator to another, submit the undelegate and wait the full 14 days before the new delegation earns rewards.
Monitoring Your Validator's Performance Score
Your Proof of Coherence performance score is the most actionable number to track as a validator. It is available at the end of each epoch via the /validator/score/{pubkey} API endpoint. The score breaks down into three sub-components: uptime (weight 40%), block proposal success rate (weight 35%), and signature verification accuracy (weight 25%).
Uptime above 99.9% scores full marks on that component. Block proposal success rate above 99% scores full marks. Signature accuracy is essentially binary: valid ML-DSA-87 signatures score 1.0, malformed signatures score 0. For validators using the standard node software, malformed signatures are rare and typically indicate hardware or configuration issues rather than intentional misbehavior.
If your score drops below 0.90, diagnose before the next epoch. Common causes are network latency spikes (check peer count and latency), storage I/O bottlenecks (check NVMe read/write latency under load), and memory pressure (check swap usage). The QuanChain developer documentation includes a validator troubleshooting section with specific diagnostic commands.
