Staking on QRL 2.0

What is available today

These tools use the private QRL 2.0 test network (Testnet v3). Validators are active and can be followed on ZondScan. Testnet Quanta has no monetary value.

QuantaPool status, 21 October 2026: the public site displays a Development environment and reports that no native pool deployment is configured. Wallet connection and deposits are disabled. Public pooled deposits are unavailable through that site today.

The QuantaPool README describes an implemented native staking system with local validator-lifecycle tests. Public launch still has review gates. The earlier token-based testnet was retired; the current design records non-transferable positions in the pool.

How QRL 2.0 staking works

QRL 2.0 uses proof of stake. Validators lock stake, propose blocks when selected and attest to the chain they see. Timely, correct duties earn rewards. Missed duties reduce earnings and can incur penalties.

The execution client, gqrl, processes transactions and smart contracts. The consensus client, Qrysm, tracks the beacon chain. A validator client holds the validator's signing keys and performs its assigned duties using ML-DSA-87 signatures.

A slot is an opportunity to propose a block. Epochs group slots and organize validator duties and lifecycle changes. Attestations help checkpoints become justified and finalized. Follow that progress on the validators dashboard and epoch list.

Simply holding Quanta in a wallet does not activate a validator. Staking requires a validator deposit and an operating validator, or an available pool that does that work.

What running a validator needs

• 40,000 Quanta per active validator. This is the activation stake and effective-balance cap documented by the current protocol references. Keep additional Quanta for transaction fees.
• A machine that stays online. It needs a reliable internet connection, accurate system time and enough CPU, memory and storage for the supported execution and consensus clients.
• All three client components. Run an execution node, beacon node and validator client with compatible releases and the intended network's configuration.
• Validator keys and a withdrawal address. Secure the signing material and recovery backups. Check the full Q-prefixed withdrawal address before funding.
• Ongoing operation. Monitor synchronization, peer connectivity, duties, balances and finality. Keep software updated and maintain a recovery plan.

Hardware needs and network configuration change as the testnet develops. Check the client release requirements before choosing a machine. A normal faucet claim supplies practice funds; it should not be treated as an allocation for a full validator.

Plan a validator setup

1. Confirm the network and supported releases. Obtain the matching execution genesis, beacon genesis, chain configuration and deposit-contract details for the network you intend to join. Check the network identity before sending a deposit.
2. Synchronize both nodes. Start gqrl and the Qrysm beacon node with matching configuration. Check that both are following the network and that the beacon node can communicate with the execution client.
3. Prepare the validator keys. Use the supported validator tooling for that release. Back up its recovery material securely and verify the intended withdrawal recipient.
4. Prepare and submit the validator deposit. Check the validator public key, withdrawal address, deposit contract and amount. Fund the required 40,000 Quanta through the network's supported deposit process.
5. Run the validator client. Connect it to the synchronized beacon node and load the intended keys. Follow the deposit through activation eligibility and the activation queue.
6. Monitor the active validator. Find it on ZondScan and check its status, effective balance and lifecycle epochs. Use the client logs and metrics to investigate missed duties.

This is the setup sequence; exact commands depend on the network release. The QRL Foundation's testnet documentation currently labels its instructions Testnet V2, while ZondScan labels its network Testnet v3. Confirm compatible configuration before following an installation guide.

Keep one active signer per validator key. Running the same key in two places can produce conflicting signatures and lead to slashing. Stop the old signer before moving it and preserve the client's slashing-protection data.

Rewards, penalties and leaving staking

Consensus rewards accumulate in the validator's beacon-chain balance. Protocol withdrawal sweeps send eligible excess balance to its registered withdrawal address. The effective stake is capped at 40,000 Quanta, so rewards above that cap do not automatically increase the validator's weight.

Returns vary with the active stake on the network, participation, uptime and assigned duties. A validator can also receive execution tips. Offline duties can incur penalties. Conflicting proposals or attestations can cause slashing, loss of stake and a forced exit.

1. When you want to leave, submit a voluntary exit using the supported validator tooling and the correct signing key.
2. Follow the scheduled exit epoch and keep operating until the validator has completed its duties.
3. Wait for withdrawal eligibility and the protocol sweep. Confirm the remaining balance reaches the registered withdrawal address.

Exits and withdrawals follow protocol queues and eligibility rules. They do not provide an instant withdrawal date. ZondScan's validator detail page shows the activation, exit and withdrawable epochs. See Validators, epochs and staking for more on that lifecycle.

How QuantaPool pooled staking is designed to work

QuantaPool combines deposits to fund native validators. The operator runs the validators, while contracts record each depositor's position. Deposits and payouts use native Quanta. A position stays tied to the wallet that deposited and cannot be transferred to another wallet.

The following sequence describes the implemented design. The public site currently has deposits disabled.

1. Deposit into the pool. A deposit remains pending and refundable until a later authenticated checkpoint admits it. That checkpoint is a verified view of the pool's assets and validator balances.
2. Fund validators. The operator first supplies 2,000 Quanta. Before releasing the pooled 38,000 Quanta top-up, the contracts verify that consensus withdrawals belong to the pool and store a signed validator exit. Together these amounts fund a 40,000 Quanta validator.
3. Account for gains and losses. Verified checkpoints update each position's share of the pool. Principal and unreserved earnings remain exposed to validator losses.
4. Request rewards or a withdrawal. Requests enter one first-in, first-out queue. They wait for a later checkpoint and sufficient available cash. Validator exits may be needed to supply that cash.
5. Claim reserved funds. Once cash is reserved, the owning wallet can claim it. Payout goes to the original beneficiary.

The fixed operator fee is 10% of eligible realized net consensus gains when cash is reserved for payout. Contributed principal and fee-exempt gifts are excluded. The accounting also considers prior losses.

A withdrawal request remains exposed to rewards and losses until cash is reserved. If verification or accounting expires, the design enters permanent recovery. Existing positions then share available and later returned cash, with zero new fees.

Read the pool explanation and architecture for the full accounting and recovery rules.

Understand the pool's limits

The contracts fix the fee and critical roles at deployment and have no upgrade authority. The operator still controls validator performance and execution-tip routing. Pool claims depend on assets the contracts can authenticate and receive.

Proof verification relies on an initial trusted checkpoint, committee assumptions and timely proof submission. Publicly stored exit signatures allow eligible validators to be exited by independent relayers; they also allow unwanted early exits. These policies and proof costs remain part of the public-launch review.

Before using a future deployment, check its published network, contract addresses, status and minimum deposit. Review the fee and withdrawal process. The project's security review records the remaining launch gates.

Use the staking calculator

1. Open the ZondScan staking calculator. Check the network snapshot and whether it shows live data or last known values.
2. Set Validators you run. The calculator shows the total stake needed at 40,000 Quanta per validator.
3. Adjust Network validators, Your uptime and Network participation to compare scenarios.
4. Open Show advanced assumptions to change the priority fee per block, circulating supply or display price. A price of zero hides the fiat estimates.
5. Compare effective APR, real yield and the reward estimates per epoch, day, month and year. Check the protocol parameters used by the model.
6. Use Copy link to share your validator count, network validator count, uptime, participation and priority fees. Supply and display price reload from network data when the link opens, so communicate any custom values separately. Reset to live restores the network snapshot.

Effective APR estimates the increase in your balance. Real yield also accounts for growth in total supply. The calculator models validator rewards; its figures do not include a QuantaPool position's full fee, liquidity and loss history.

These are estimates using the calculator's displayed assumptions. Testnet configuration can change, and its explanatory text may lag the network. Check the model parameters before relying on an estimate. A fiat display gives a hypothetical conversion; testnet Quanta has no monetary value.

Use the explorer guide to follow validator status, epochs and withdrawal addresses.