-
Notifications
You must be signed in to change notification settings - Fork 1
DPoS Consensus
How 21 witnesses agree on the truth every 3 seconds.
A blockchain is only as reliable as its method for deciding which transactions are valid and in what order they occurred. This method is called consensus. Pixa uses Delegated Proof-of-Stake (DPoS) — a consensus algorithm where elected delegates (called witnesses) take turns producing blocks in a fixed rotation.
This guide specifies how DPoS works on Pixa: the witness schedule, block production rules, fork resolution, and the guarantees the system provides.
Consensus is the process by which all nodes in a decentralized network agree on a single version of the blockchain's history. Without consensus, different nodes could have different records of who owns what — and the system would be useless.
| Consensus type | Used by | How it decides |
|---|---|---|
| Proof-of-Work (PoW) | Bitcoin | Whoever solves the puzzle first |
| Proof-of-Stake (PoS) | Ethereum | Randomly selected validators, weighted by stake |
| Delegated Proof-of-Stake (DPoS) | Pixa, Steem, Hive, EOS | Elected witnesses in a fixed rotation |
DPoS separates two concerns: who decides (governance) and who produces blocks (execution).
Who decides — PXP holders vote for witnesses. This is the delegation step. The community delegates block production authority to a small, elected set of operators.
Who produces blocks — The top 20 witnesses plus 1 backup witness take turns producing blocks in a deterministic rotation. Each witness gets exactly one slot per round.
Each round consists of 21 block slots:
| Slot | Assigned to |
|---|---|
| Slots 1–20 | The 20 top witnesses (shuffled order) |
| Slot 21 | 1 VST (Virtual Schedule Time) backup witness |
| Parameter | Value |
|---|---|
| Block interval | 3 seconds |
| Blocks per round | 21 |
| Round duration | 63 seconds |
| Rounds per day | ~1,371 |
The order of the 20 top witnesses within each round is shuffled — they do not produce blocks in a fixed sequence. The shuffle is deterministic (derived from the previous block's data), so all nodes agree on the order without communication. This prevents witnesses from predicting and exploiting their exact position.
The 21st slot in each round is reserved for a backup witness — a candidate outside the top 20 who is selected through the Virtual Schedule Time (VST) mechanism.
VST simulates a virtual race among all non-top-20 witness candidates. Each candidate's speed in this race is proportional to the stake-weighted votes they have received. More votes mean faster laps, which means more frequent selection for the backup slot.
Without VST, only the top 20 would ever produce blocks. Smaller witnesses would have no way to demonstrate reliability, test their infrastructure, or earn any compensation. VST gives them a proportional opportunity.
| Witness tier | Block production | Selection method |
|---|---|---|
| Top 20 | Every round (guaranteed) | Highest stake-weighted votes |
| VST backup | Occasional (proportional to votes) | Virtual Schedule Time algorithm |
| Unranked | None | Insufficient votes |
When a witness's slot arrives, their node executes the following sequence:
The node pulls valid, unconfirmed transactions from its local mempool.
Transactions are ordered deterministically. All nodes must agree on the exact sequence.
Each transaction's operations are executed against a copy of the chain state. If any operation fails validation (insufficient balance, invalid signature, etc.), it is excluded.
The block is assembled with:
| Field | Content |
|---|---|
| Block number | Sequential integer |
| Timestamp | Current time (must fall within the 3-second slot) |
| Previous block hash | Cryptographic link to the preceding block |
| Transaction Merkle root | Hash tree of all included transactions |
| Witness signature | Block signed with the witness's block signing key |
The signed block is broadcast to all connected peers. Nodes validate the block independently and apply it to their own state.
If the scheduled witness fails to produce a block within the 3-second window — due to downtime, network issues, or software failure — the slot is skipped. The network waits 3 seconds and moves to the next scheduled witness.
| Impact | Detail |
|---|---|
| Recorded on-chain | Miss count is publicly visible |
| No block reward | The witness earns nothing for that slot |
| Community signal | Frequent misses erode voter confidence |
| Potential vote loss | PXP holders may switch their vote to a more reliable witness |
There is no automatic penalty beyond the lost reward. Enforcement is social — the community decides whether a witness with poor reliability deserves to remain in the top 20.
A fork occurs when two or more versions of the blockchain diverge — usually because of network partitions where different witnesses produce blocks without seeing each other's work.
DPoS naturally resolves short forks through the longest chain rule. When a node sees two competing chains, it follows the one with more blocks. Since the majority of witnesses will be on the same side of any network partition, the majority chain quickly becomes the longest.
| Step | What happens |
|---|---|
| 1. Divergence detected | A node receives a block that conflicts with its current chain |
| 2. Compare chain lengths | The node evaluates which fork has more blocks |
| 3. Switch if necessary | If the competing fork is longer, the node switches to it |
| 4. Reapply transactions | Transactions from the abandoned fork that are still valid are returned to the mempool |
DPoS produces far fewer forks than PoW because block production is scheduled, not competitive. Two witnesses never race to produce the same block. Forks only occur when network connectivity fails between parts of the witness set — and they resolve within seconds once connectivity is restored.
A block becomes irreversible when it can no longer be undone by any fork resolution. On Pixa, this happens after a sufficient number of unique witnesses have produced blocks on top of it.
A block is considered irreversible once ⅔ + 1 of the active witnesses (at least 15 out of 21) have produced a subsequent block. At that point, no reorganization can undo it.
| Parameter | Value |
|---|---|
| Witnesses needed for irreversibility | 15 of 21 (⅔ + 1) |
| Time to irreversibility | ~45 seconds (15 × 3-second blocks) |
A fork would need to be produced by a majority of witnesses to overtake the canonical chain. If ⅔ + 1 witnesses have built on a block, no minority fork can ever surpass it in length.
On Bitcoin, irreversibility takes ~60 minutes (6 confirmations). On Pixa, it takes ~45 seconds.
DPoS tolerates up to ⅓ of witnesses acting maliciously without compromising consensus. As long as ⅔ + 1 witnesses are honest, the chain progresses correctly.
| Attack | Feasibility | Defense |
|---|---|---|
| Double-spend via fork | Requires controlling ⅔+ of witnesses | Stake-weighted elections make this expensive |
| Block censorship | A witness can exclude specific transactions | Other witnesses include them in the next block |
| Long-range attack | Rewriting deep history | Irreversibility checkpoints prevent this |
| Nothing-at-stake | Witnesses signing conflicting blocks | Detectable on-chain, punishable by vote removal |
As long as at least one honest witness is online and reachable, the chain can continue producing blocks. Full network halt requires all 21 witnesses to be simultaneously offline — an extremely unlikely scenario.
| Property | PoW (Bitcoin) | PoS (Ethereum) | DPoS (Pixa) |
|---|---|---|---|
| Block time | ~10 minutes | ~12 seconds | 3 seconds |
| Finality time | ~60 minutes | ~15 minutes | ~45 seconds |
| Energy consumption | Massive | Low | Minimal |
| Validator set size | Unlimited (miners) | ~900,000+ | 21 (elected) |
| Throughput | ~7 TPS | ~30 TPS | Up to 300,000 TPS |
| Governance | Off-chain (informal) | Mixed | On-chain (stake-weighted voting) |
| Parameter | Specification |
|---|---|
| Consensus algorithm | Delegated Proof-of-Stake (DPoS) |
| Active witness set | 20 top + 1 VST backup |
| Block interval | 3 seconds |
| Round length | 21 blocks (63 seconds) |
| Schedule determination | Deterministic shuffle per round |
| Fork resolution | Longest chain rule |
| Irreversibility | ⅔ + 1 witnesses (~45 seconds) |
| Byzantine tolerance | Up to ⅓ of witnesses |
| Throughput capacity | Up to 300,000 TPS |
DPoS is the consensus mechanism that gives Pixa its speed. Three-second blocks, sub-minute finality, and negligible energy cost — all achieved by trusting a small, elected, accountable set of witnesses. The tradeoff is centralization risk, which is mitigated by continuous elections, transparent on-chain accountability, and the community's ultimate power to fork.