Dynamic TPS

Scheduled activation

The on-chain dynamic gas-limit mechanism described below (also referred to as "Gas v2") is scheduled to activate at a future block height (GasV2StartBlock). Before that block, a fixed legacy gas limit applies; from that block onward the gas limit is computed dynamically each block. The feature is not yet active on mainnet.

TPS refers to the number of transactions per second that can be performed on the blockchain. For example, in layman terms, increase in TPS means that the number of payments that can be made using the platform in each second increases as well. There are various tradeoffs involved here.

A higher TPS means that more powerful hardware and higher network bandwidth is required to run the blockchain. This means that fewer people can afford to run nodes that form the blockchain network which in turn means more centralization. Solana is one such example; though Solana supports higher TPS, it has expensive hardware and bandwidth requirements.

On the other hand, a lower TPS means that the hardware and network bandwidth requirements are lower. This means that more people can run nodes that form the blockchain network, leading to better decentralization. Blockchains like Bitcoin, Ethereum fall into this category (excluding the proof-of-work mining hardware requirements). The tradeoff is that transaction fees for such networks are high because there are a limited number of transactions that can be performed on the blockchain.

Sharding is one potential solution to increase the TPS without requiring significantly higher hardware and bandwidth requirements. However sharding might not scale well for span-out transactions, such as smart contracts transactions, in which majority of transactions have to go through multiple shards. Sharding in blockchains is also an area that is actively under research from various entities.

Quantum Coin will take a dynamic inference approach to blockchain scalability, by making various parameters such as block size, block time, finality time votable by the network enablers (such as validators). Once voted, the blockchain will switch to the newer TPS model dynamically after a period of N days. This switchover time is in order of days to give all blockchain nodes enough time to adjust their hardware or network configuration. Under certain circumstances, the blockchain will also perform load shedding. The underlying mechanism will be detailed in a follow-up whitepaper.

Whitepaper on the Dynamic TPS technology is upcoming.

Dynamic Gas Limit (on-chain mechanism)

The first concrete step of the Dynamic TPS model is a dynamic block gas-limit control law implemented directly in the consensus engine. Because the block gas limit bounds the computation and bandwidth required to produce, propagate, and verify each block, it is the natural control variable for TPS. The mechanism continuously adjusts the gas limit based on observed consensus health, lowering throughput when the network is under stress and relaxing it back up as conditions recover. The calculation is fully deterministic and integer-only, so every node derives the same gas limit for a given block.

This mechanism is scheduled to activate at a future block height (GasV2StartBlock). Below that height the engine returns the legacy fixed gas limit; at and above it the engine returns the dynamically computed value. The authoritative implementation is consensus/proofofstake/gaslimit.go in the Quantum Coin Go node.

Why liveness is prioritized over throughput

A Byzantine-Fault-Tolerant (BFT) consensus protocol has two fundamental correctness properties: safety (no two conflicting blocks are finalized) and liveness (the chain keeps making progress). Safety is non-negotiable and is preserved by the protocol regardless of the gas limit. Throughput, by contrast, is not a correctness property — it is a performance parameter. A chain that loses liveness processes zero transactions, whereas a chain that temporarily lowers its throughput stays fully available and keeps finalizing blocks. The mechanism therefore conservatively trades throughput to preserve liveness margin. Two properties of this network sharpen that asymmetry: (i) post-quantum cryptographic (PQC) signatures are substantially larger than classical signatures, raising per-block size, propagation latency, and verification cost; and (ii) the 3+1 round BFT protocol incurs additional communication rounds, widening the window in which network degradation can prevent timely consensus.

Health signals: nil blocks

The control law observes the most recent 32 blocks (a round-robin status array stored on-chain in the consensus-context system contract). Each block is classified as ok, a round-1 nil, or a round-2 nil:

Round-2 nil block — network-stress indicator. A round-2 nil is produced only when validators fail to reach consensus in the first round, which correlates with network-level stress (latency, partition, bandwidth saturation) rather than a single faulty node. The nearest round-2 nil applies a hard, distance-banded cap that collapses the gas limit toward the floor and relaxes it only gradually (1× → 2× → 3× → … → 8× the floor) as the event ages out of the 32-block window.
Round-1 nil block — proposer-availability indicator. A round-1 nil occurs when the selected proposer is offline or unresponsive. Isolated occurrences are benign, so round-1 nils are ignored until at least 5 accumulate within the window — this prevents a single offline validator from moving the gas limit on its own, while a cluster of 5+ is itself a meaningful signal of a broader problem worth throttling for.

How the limit is computed

Two effects combine, and the smaller one wins (the flat penalty can only push the gas limit lower than the round-2 cap):

Pass 1 — Round-2 cap. The nearest round-2 nil sets an upper cap by its distance band of width 4: distance 1–4 → 1×minGas, 5–8 → 2×, 9–12 → 3×, … 29–32 → 8×. With no round-2 nil in the window the cap is maxGas.
Pass 2 — Flat count-based penalty. Penalty = r1Pen + r2Pen, where r2Pen = (r2Count - 1) × 20 × 21000 gas (the single nearest round-2 is dropped because Pass 1 already accounts for it) and r1Pen = r1Count × 10 × 21000 gas, applied only when r1Count ≥ 5. Then penaltyGas = maxGas - penalty (saturating at the floor).

The final result is clamp(min(penaltyGas, cap), minGas, maxGas), where minGas is the minimum dynamic gas limit and maxGas is the configured per-block maximum.

Parameter	Value	Meaning
`GAS_LIMIT_WINDOW`	32	Recent blocks whose nil-status influences the limit; also the round-robin array size.
`GAS_TIER_BAND_WIDTH`	4	Width (blocks) of each round-2 cap band → 8 bands over the window.
`GAS_PENALTY_UNIT`	21000	Base gas unit (standard basic-transaction gas); keeps the math integer-only.
`GAS_PENALTY_R1_UNITS`	10	Flat penalty units per round-1 nil (× 21000 gas).
`GAS_PENALTY_R2_UNITS`	20	Flat penalty units per extra round-2 nil (× 21000 gas); weighted heavier than round-1.
`GAS_PENALTY_MIN_R1_COUNT`	5	Round-1 nils are ignored below this count within the window.

Stake weight is deliberately excluded from the formula. Block-proposer selection is already weighted by staked coins, so a validator's expected contribution to the nil-block statistics is proportional to its stake; low-stake validators are selected rarely and have negligible aggregate influence, while any coalition large enough to move the limit would necessarily control significant stake. Excluding stake weight keeps the control law simple, deterministic, and proposer-agnostic — a conscious, documented tradeoff. The blockchain may also perform load shedding under certain circumstances; the broader Dynamic TPS model (votable block size, block time, and finality parameters) will be detailed in a follow-up whitepaper.