Governance

FPOS GOVERNANCE BUILT FOR DETERMINISTIC FINALITY

Fenine governance is executed through consensus-critical rules, epoch system transactions, and contract-based validator coordination. It combines predictable block leadership with transparent reward and validator state transitions.

Read DocsRead Governance Articles
Why FPoS

Core strengths

Deterministic Single-Leader Finality
Fenine enforces in-turn sealing only. Out-of-turn signatures are rejected, so block leadership is predictable and consensus safety is explicit.

Contract-Managed Validator Layer
Validator updates are executed via system transactions at epoch boundaries, allowing governance logic to live in transparent contract flows.

Latched Reward Integrity
Block rewards are latched from parent state to prevent same-block reward mutation and preserve deterministic execution across builders and verifiers.

Operational Observability
Consensus metrics and snapshot checkpoints provide operators with direct insight into sealing behavior, epoch transitions, and signer health.

Stack

Fenine governance stack

Consensus Core

• Fenine PoA engine with FPoS governance model

• In-turn signer scheduling from ordered snapshot set

• Strict header validation (timestamp, signature, mix digest, uncle hash)

Epoch Execution Layer

• System transactions for validator updates and reward distribution

• RewardManager sync transaction for state visibility

• Transparent on-chain reward flow via contract calldata + value

State & Snapshot Layer

• In-memory snapshot/signature caches for fast verification

• Checkpoint snapshots written every 1024 blocks

• Genesis extraData signer parsing and deterministic signer ordering

Operator & Monitoring

• Operator runbooks for genesis, startup, key management, and monitoring

• Prometheus/Grafana guidance in consensus docs

• RPC namespace exposure for fenine-specific methods

Rules

Consensus governance guarantees

Who can seal
Only authorized signers from snapshot can seal blocks. Unauthorized or out-of-turn signers are rejected.
When rewards move
Non-epoch blocks mint latched block rewards to FeeRecorder. Epoch blocks route distribution through system transactions.
How validator set evolves
Validator candidate updates run at epoch boundary before reward distribution, preserving deterministic ordering.
Failure behavior
Missing parent state, invalid signature, malformed reward payload, or consensus rule mismatch causes block rejection.

Join Fenine Governance Today

Participate in FPoS governance, validator coordination, and transparent reward operations with production-ready consensus infrastructure.

Read DocsExplore Governance