machineRFT Consensus
Paxeer's proprietary negative-attestation consensus that separates agreement from execution, achieving sub-second finality.
The problem with traditional BFT
Traditional BFT consensus operates on a positive attestation model: every validator must execute every transaction, verify the resulting state transition, and only then vote to commit. This execution-before-consensus pattern is the fundamental bottleneck preventing sub-second finality.
PBFT, Tendermint, HotStuff, and their descendants share this DNA - agreement and execution are inextricably linked.
machineRFT: agreeing on what did not happen
machineRFT inverts the entire model. Instead of validators executing transactions and voting on state correctness, validators:
- Order transactions without executing them - the consensus critical path handles pure ordering, not state verification.
- Sign negative attestations - validators cryptographically attest that they have not observed conflicting transactions for the same state keys.
- Defer execution - state transitions happen after consensus, not during it.
- Enforce via fraud proofs - a post-consensus fraud-proof mechanism slashes validators who signed false negative attestations.
This transforms consensus from a state-verification problem into a pure ordering problem, reducing the critical path to network latency plus cryptographic signing operations.
Theoretical foundation
The SOSP 2003 paper "Separating Agreement from Execution for Byzantine Fault Tolerant Services" (Yin et al.) proved that separating agreement from execution improves fault tolerance: 3f+1 replicas for agreement, but only 2f+1 for execution.
Tendermint's thesis later formalized this through TMSP. machineRFT takes this to its logical conclusion: the consensus critical path contains no execution at all.
How machineRFT differs from CometBFT
| Property | CometBFT (standard) | machineRFT |
|---|---|---|
| Attestation model | Positive - validators vote on state correctness | Negative - validators attest they did not observe conflicts |
| Execution timing | Before consensus (blocking) | After consensus (non-blocking) |
| Consensus critical path | Network latency + full transaction execution | Network latency + ed25519 signing |
| Fault enforcement | Slashing for invalid votes | Slashing for false negative attestations (fraud proofs) |
| Minimum replicas (agreement) | 3f+1 | 3f+1 |
| Minimum replicas (execution) | 3f+1 | 2f+1 |
| Finality | Deterministic after commit | Deterministic after commit (faster commit path) |
Performance characteristics
machineRFT on top of the Twin Turbo engine delivers:
- ~250ms average block time under real-world conditions
- 0.45ms record sustained low - demonstrating near-instant finality under favorable network conditions
- 5,000 TPS sustained throughput
- Zero reorgs - once a block is committed via negative attestation quorum, it is irreversible
The 0.45ms record demonstrates that the consensus critical path is bounded by network propagation, not computation.
Integration with LayerX
machineRFT's negative-attestation model is the foundation for LayerX, Paxeer's agent-only side channel. The combined flow:
- LayerX ingests - agents submit transactions to the LayerX sequencer with zero fees and instant settlement.
- Batch ordering - the LayerX sequencer orders transactions and builds Merkle-provable receipts.
- L1 anchoring - machineRFT commits batch roots to Paxeer L1 via negative attestation, anchoring LayerX state to the base layer.
- Fraud enforcement - if a LayerX batch contains invalid transactions, the fraud-proof mechanism can slash the sequencer and revert the batch.
This architecture lets Paxeer process thousands of agent transactions per second on LayerX while anchoring their finality to L1 through machineRFT's efficient consensus path.
Why it matters for developers
- No confirmation delays - treat a confirmed transaction as final immediately.
- Predictable latency - the consensus path is bounded by network RTT, not execution time.
- M2M-ready - designed for high-frequency automated transactions, not just human-paced interactions.
- Lower execution cost - validators can optimize execution independently of the agreement path.
You interact with machineRFT indirectly through the standard EVM interface and RPC endpoints.