Skip to main content

Rewards and Monitoring

A light node both earns rewards and needs to stay healthy to keep earning them. This page covers the 3% light-node reward share, how delegated staking and auto-compounding work, and how to monitor the node.

The 3% block-reward share​

QoreChain's fee distribution reserves a fixed 3% share for light nodes that serve network data. This is one of the five destinations in the protocol's reward split — validators (37%), burned (30%), treasury (20%), stakers (10%), and light nodes (3%) — enforced on-chain. See Tokenomics for the full breakdown.

To be eligible for this share, a node needs three things, checked on-chain rather than self-declared: an active lightnode_operator license, a minimum of 1,000 QOR delegated — counted as your total across all the validators you delegate to, not per validator — and a 1 QOR on-chain registration fee. Participation is also capped network-wide at 10,000 light nodes. See Registration and Licensing for how registration and licensing work, including the current status of reward-program enrollment.

Once registered and delegated, staying eligible is a matter of staying live. A node needs at least 80% uptime, and must keep submitting heartbeat liveness proofs on a roughly 1,000-block (~39 minute) interval.

The submission window is narrow on both ends, not just the late side. A heartbeat is only accepted between roughly your last accepted heartbeat + 1,000 blocks and +1,100 blocks (about 4 minutes, once every ~39 minutes) — submit too early and it's rejected the same as submitting too late.

Missing the window costs uptime, not your registration. A node that misses is marked inactive and stops earning the share, but the very next successful heartbeat reactivates it — there's no re-registration to do. Note too that the daemon's own internal counter toward the next heartbeat keeps advancing even if a submission attempt fails, and resets on restart, so a node can end up marked inactive through no fault of the operator; check status rather than assuming an inactive mark means something is configured wrong.

What a heartbeat actually proves

A successful heartbeat proves the operator's key signed on time — it does not prove a node is continuously running the full software. Treat it as a liveness signature, not as "verified as an active node."

last_heartbeat is a block height, not a timestamp

If you query a node's on-chain record directly, last_heartbeat is a block height, and a value of 0 means the node has never yet sent one — the chain reports its registered_at height as a substitute in that case. Reading it as a naive elapsed-time calculation makes a freshly registered node look like it's millions of blocks overdue.

Reward eligibility: hold an active on-chain license and the minimum delegated stake, register, then keep proving liveness via heartbeats to stay above the uptime and heartbeat-interval thresholds that keep the share flowing.

How rewards work​

Beyond the light-node share, the node manages delegated stake and the staking rewards it produces. The behaviour is driven by the [delegation] section of config.toml.

Delegated staking with multi-validator split​

You can delegate across multiple validators rather than concentrating stake on one. The node tracks each delegation and the share of stake assigned to each validator using configurable split weights, so you can spread risk across the set.

Auto-compound rewards​

The node can claim rewards and re-delegate them automatically on a configurable interval. By default auto-compound is enabled on a 1h interval, with a minimum reward threshold (in uqor) that must accumulate before a claim is triggered. Compounding turns earned rewards into additional stake without manual intervention.

Reputation-aware rebalancing​

When rebalancing is enabled, the node can shift delegation toward higher-reputation validators automatically, subject to a configurable minimum reputation score. This keeps stake working with validators that are performing well rather than leaving it with ones that have degraded.

Inspecting rewards and delegations​

The SX edition exposes commands to inspect this state:

lightnode-sx delegation   # current delegations and their split
lightnode-sx rewards      # pending staking rewards (uqor)
lightnode-sx validators   # the bonded validator set

In the UX edition, the Delegation view shows the same delegation and reward information in the browser.

Monitoring​

Keeping the node healthy is what keeps it eligible for rewards. There are three things worth watching.

Telemetry​

Real-time telemetry covers validators, consensus/network, the bridge, and tokenomics, each refreshed on its own interval (configured under [telemetry] in config.toml). From the CLI:

lightnode-sx status    # node and light-client sync status
lightnode-sx network   # recent synced headers and latest height

The UX edition surfaces the same data live across its Overview, Network, Bridge, and Tokenomics views — see UX Edition.

Sync and heartbeat health​

The status command reports the chain ID, latest block height, whether the chain is catching up, and the light client's synced height and syncing state. A node that is registered, synced, and running continues to submit heartbeat liveness proofs and so stays eligible for the reward share. These heartbeats are produced via a PQC-cosigned transaction pipeline (hybrid Dilithium-5 / ML-DSA-87), consistent with the chain's PQC-required default — see Registration and Licensing for how the pipeline works and how to enable on-chain heartbeats. If status shows the node stalled or not syncing, it may be failing to prove liveness — investigate before eligibility is affected.

Self-test health​

If you suspect a problem with the cryptographic stack, run the PQC self-test at any time:

lightnode-sx selftest

It runs keygen → sign → verify → tamper-detection (five checks) and exits non-zero on any failure. This is the fastest way to rule out a problem with the post-quantum signing stack when diagnosing node issues. See SX Edition for the full self-test breakdown.

Where to go next​