Consensus & Execution
TxCore is the trading core of TxFlow: the consensus layer that orders transactions and the deterministic state machine that executes them. This page covers how transactions become ordered, finalized blocks and how those blocks are replayed identically by every node.
Tx-BFT consensus
TxFlow orders transactions with Tx-BFT, a DAG-based (directed acyclic graph) Byzantine Fault Tolerant protocol.
- Validators organize transaction batches as vertices in a DAG in parallel. The protocol deterministically extracts a globally consistent commit sequence from the DAG. There is no single-leader, block-by-block proposal bottleneck, so throughput scales with validator parallelism.
- A batch reaches finality once a 2f+1 quorum of voting power confirms it. Finality is non-reversible — there is no chain reorganization.
v3 misses round 2 and the DAG advances regardless. Once 2f+1 vertices of the next round link to a round's anchor, the anchor and its causal history (shaded) commit, in an order every node derives identically from the same DAG.The transaction batcher
Between clients and consensus sits a transaction batcher that groups transactions into batches to amortize consensus overhead.
It exposes three confirmation states to clients:
| State | Meaning |
|---|---|
Submitted | accepted and handed to consensus |
Included | placed into a proposed block |
Committed | reached quorum and is final |
Consensus output
For each committed batch, consensus emits:
- a globally sequential block number,
- a commit digest, and
- a consensus timestamp — the finality time agreed by consensus for the batch.
The consensus timestamp is the single clock for all time-dependent logic in the state machine — funding settlement, order expiry (GTD), TWAP slicing — which guarantees identical results across the network. The state machine never reads wall-clock time.
Deterministic execution
Each committed block is executed by a single-threaded state machine under fixed rules. Every node that replays the same block produces byte-for-byte identical state.
The block executes in five stages:
- Signature verification — each transaction's EIP-712 signature is recovered and checked against the claimed sender in a pre-pass; any transaction that fails authentication is rejected, ensuring only validly signed operations reach execution. This is pure computation and does not affect determinism.
- Deterministic ordering — operations are placed in a canonical order derived from the committed sequence, so every node executes the block identically.
- Per-transaction execution — for each transaction: validate the nonce → route to the appropriate handler (match / clear / transfer / …) → collect state-change events and the set of affected users.
- Block-tail processing — funding settlement, margin recomputation, liquidation checks, and ADL. On the ordinary path this runs incrementally on accounts touched by the block; an oracle update in the same block triggers a full margin recalculation so every position is marked to the new prices.
- Event output — all state changes are emitted as an event stream, consumed by persistence and real-time push.