BFT Finality in One Second

Most blockchains have probabilistic finality. Bitcoin requires six confirmations — roughly one hour — before a transaction is considered irreversible. Ethereum's finality checkpoint takes 12-15 minutes. During that window, the chain can fork, and a transaction that appeared confirmed can disappear.

Feedable Network uses Byzantine Fault Tolerant consensus with deterministic finality. When a block is finalized, it is final. There is no confirmation window. There is no reorg risk after the quorum is reached. This is not a design aspiration — it is a mathematical property of the BFT protocol.

What deterministic finality means in practice

For AI inference, finality timing matters in a specific way. When a requester submits an inference job, they want to know: is this job committed? Will it run? If the miner's block gets orphaned, the job might not run, and the fee might not be refunded cleanly.

With deterministic finality, the answer is unambiguous. The moment 2/3 of validators precommit to a block, that block is final. The inference job is committed. The FeedProof is on-chain. The fee is settled. No waiting.

This also enables the optimistic execution model. When a miner broadcasts an Intent (Phase 1 of the PoF protocol), inference starts immediately — before block finalization. If the block is later rejected, TigerBeetle's linked transfer reversal unwinds the fee atomically. This gives AI users sub-second job start times while the network maintains deterministic finality.

The BFT round structure

Feedable Network uses a Tendermint-inspired BFT protocol adapted for PoF. Each round has four phases:

Propose: The designated proposer for this round broadcasts a block candidate containing FeedProofs, transactions, and InferenceReceipts. Timeout: 3 seconds.

Prevote: Each validator independently verifies the FeedProofs in the block and casts a prevote. Verification means querying TigerBeetle for each TransferId. Timeout: 2 seconds.

Precommit: Once a validator sees 2/3 prevotes for the same block, it casts a precommit. Timeout: 2 seconds.

Commit: Once a validator sees 2/3 precommits, the block is finalized. Coins are minted. State root is updated.

Worst-case round time: 7 seconds. Block time target: 10 seconds. The 3-second buffer allows for network variance and view changes when a proposer is offline.

Why 66µs on devnet

On our local 3-node devnet, we measured 66µs from block proposal to all-nodes finalized. This number will not hold on a global production network — it reflects zero network overhead between nodes on the same machine.

The number is meaningful for a different reason. It demonstrates that the BFT protocol implementation has no software overhead. The 66µs is essentially the time for three processes to exchange messages over localhost. The protocol adds nothing on top of the network.

On a well-connected 21-node validator set with 50ms average inter-node latency, we expect finality in the 200-400ms range. On a 100-node set with global distribution, we expect 500ms-1s. Both are well within the 10-second block time.

View changes and liveness

A BFT protocol must handle proposer failure without halting. When the current proposer is offline or misbehaving, the network needs to elect a new one and continue.

Feedable Network uses a round-robin proposer schedule with a 10-second view change timeout. If the current proposer has not broadcast a valid block within 10 seconds of the round start, validators vote to advance to the next proposer. The new proposer takes over and proposes a new block.

View changes are expected — nodes go offline, network partitions happen. The protocol treats them as normal operations, not exceptional cases. As long as 2/3 of validators are honest and online, the chain makes progress.

Validator set size and finality latency

The dynamic validator set adds a practical consideration. More validators means higher security (more nodes to compromise) but higher finality latency (more signatures to collect).

Feedable Network targets 21 to 100 validators. Selection is based on 30-day rolling average TPS contributed to the network — not just stake. This means validators who run Blazil at high throughput are preferred over validators who merely stake capital.

The 30-day measurement window prevents burst gaming. A node cannot spin up for a day, post high TPS, and immediately enter the validator set. They need to demonstrate sustained performance.

At 21 validators, finality is fast. At 100, it is slower but the network is more decentralized and harder to attack. The target block time of 10 seconds accommodates both extremes.

Comparison with other finality models

| Chain | Finality model | Time to finality | |-------|---------------|-----------------| | Bitcoin | Probabilistic (6 blocks) | ~60 minutes | | Ethereum | Checkpoint-based | 12-15 minutes | | Solana | Optimistic + confirmation | ~400ms (optimistic) | | Feedable Network | BFT deterministic | ~200-500ms (production est.) |

The Solana comparison is useful. Solana achieves low latency through a different mechanism — optimistic confirmation with eventual deterministic finality. Feedable Network achieves deterministic finality directly, without an optimistic layer.

The tradeoff is validator set size. Solana has thousands of validators. Feedable Network's BFT consensus is practical up to 100. For the use case — AI inference settlement — 100 well-selected validators is sufficient and provides strong security guarantees.