Phase 4 — Architecture Defined · Not Connected to Network · Not Connected to Validators
Current operational state of the consensus engine and its integrations.
Engine Status
Architecture Ready
Not Connected to Network
Current Phase
Idle
Waiting for Real Data
Active Validators
Waiting for Real Data
Source: Real Validator Node — Not Connected
Finalized Blocks
Waiting for Real Data
Source: Real Network — Not Connected
Six strongly typed domain models defining the consensus architecture.
The 8-phase consensus state machine from Idle to Finalized.
How consensus epochs progress from pending to finalized.
Epoch is scheduled but has not yet started. Validator set is being prepared.
Epoch is currently running. Validators are participating in consensus rounds.
Epoch end block has been reached. Final rewards and slashing are being calculated.
Epoch has been fully finalized. Rewards distributed and validator set updated.
Epoch failed to finalize due to consensus failure or critical error.
Six validator lifecycle statuses managed by the consensus engine.
Validator has registered but has not yet been admitted to the active set.
Validator is in the active set and participates in consensus rounds.
Validator is registered but not currently participating in consensus.
Validator has been jailed due to downtime or protocol violations.
Validator has been penalized for double-signing or equivocation.
Validator has been permanently removed from the validator registry.
7-step pipeline for validating and aggregating consensus votes.
Validator submits a prevote or precommit to the consensus engine.
BLS/Ed25519 signature is verified against the validator public key.
Validator is confirmed to be in the active set for this epoch.
Vote is checked against existing votes to detect double-voting.
Valid vote is added to the aggregation pool for the current round.
Total voting power is evaluated against the 2/3+ BFT threshold.
If quorum is reached, block proceeds to finalization. Otherwise, next round begins.
Note: Vote processing pipeline is architecturally defined. Live vote processing requires P2P Network (Phase 5) and real validator nodes.
10 services integrated across R3, R4, R6, and R7 execution layers.
Consensus State Management
R3 Core Orchestrator
Epoch Management
R4 Blockchain Protocol Engine
Validator Candidate Registry
R6 Security & Automation
Proposer Selection
R3 Core Orchestrator
Vote Validation
R6 Security & Automation
Vote Aggregation
R4 Blockchain Protocol Engine
Finality Calculation
R7 Enterprise Services
Slashing Rule Evaluation
R6 Security & Automation
Consensus Lifecycle Management
R3 Core Orchestrator
Consensus Event Publishing
R7 Enterprise Services
6 slashing rules defined for validator misbehavior detection.
Validator signed two different blocks at the same height and round (equivocation).
Penalty: tombstone
Validator missed more than the allowed threshold of consensus rounds within an epoch.
Penalty: jail
Validator submitted a vote with an invalid or forged signature.
Penalty: stake reduction
Proposer submitted an invalid or malformed block proposal.
Penalty: jail
Validator participated in consensus without being in the active validator set.
Penalty: removal
Validator deliberately withheld votes to prevent epoch finalization.
Penalty: stake reduction
Prerequisites for live consensus finality. Architecture is complete; network connectivity is deferred to Phase 5.
P2P Network Connected
Required for Phase 5
Live Validator Nodes
Required for Phase 5
Consensus State Machine
Architecture defined in Phase 4
Epoch Management
Architecture defined in Phase 4
Validator Registry
Architecture defined in Phase 4
Vote Validation Pipeline
Architecture defined in Phase 4
Slashing Framework
Architecture defined in Phase 4
Finality Calculation
Architecture defined in Phase 4
Core Engine Integration
R3, R4, R6, R7 integrated
Blockchain Protocol Engine
Phase 3 complete
All Phase 4 deliverables must be complete before proceeding to Phase 5.
consensus-engine module created
src/lib/consensus-engine/ module exists
RTWOConsensusState domain model defined
9 fields: height, round, epoch, phase, proposer, validatorSetHash, lockedBlockHash, finalizedBlockHash, status
RTWOValidatorCandidate domain model defined
8 fields: validatorId, operatorAddress, publicKey, status, votingPower, stakeAmount, joinedAt, lastSeenAt
RTWOConsensusVote domain model defined
9 fields: voteId, blockHash, validatorId, voteType, round, epoch, signature, timestamp, status
RTWOEpoch domain model defined
7 fields: epochNumber, startBlock, endBlock, validatorSetHash, status, startedAt, finalizedAt
RTWOFinalityRecord domain model defined
6 fields: blockNumber, blockHash, finalizedAt, validatorSetHash, voteCount, finalityStatus
RTWOSlashingRule domain model defined
7 fields: ruleId, ruleName, severity, description, penaltyType, enabled, status
Consensus phases defined (8 phases)
Idle → Proposer Selection → Block Proposal → Vote Collection → Vote Validation → Finality Check → Finalized → Failed
Validator statuses defined (6 statuses)
Candidate, Active, Inactive, Jailed, Slashed, Removed
Service interfaces defined
10 service interfaces with placeholder implementations
Core Engine integration complete
Integrated with R3 Core Orchestrator, R4 Blockchain Protocol Engine, R6 Security & Automation, R7 Enterprise Services
Consensus dashboard page created
/consensus-engine route with full architecture visualization
No fake blockchain data shown
Truthful Data Policy enforced — all runtime values are null or empty states
P2P runtime bridge activated
Consensus Engine connected to operational P2P provider — no fabricated network state
Phase 4 consensus engine integration points with existing execution layers.
Phase 4 Architecture Notice
This phase defines the RTWO Consensus Engine architecture and internal state machine only. RTWO Mainnet is not live. Validators are not running. Blocks are not being finalized. All consensus services are structurally defined with placeholder implementations. Live consensus operation requires Phase 5 (P2P Networking) and real validator node deployment.