Skip to main content
IntentionBFT is Intention’s consensus protocol — a HotStuff-family BFT protocol extended for financial infrastructure. Safety holds unconditionally under the fault threshold; liveness holds after the network stabilizes. Consensus does two things here that a general-purpose chain’s consensus does not: it commits an ordering as a first-class object, and it commits a certified price vector in the same event. Everything the kernel can guarantee about execution depends on both being settled before execution begins.

​
Model

IntentionBFT tolerates a Byzantine adversary controlling up to a third of the total stake. Honest stake is therefore always more than two thirds, and the standard quorum is any set of validators whose combined stake exceeds two thirds — what these pages call a 2f+12f+1 stake-weighted quorum. The network is partially synchronous: before a stabilization point delays are arbitrary; after it, delays between honest validators are bounded.
Leader
Validators
Chain
2f+1 stake-weighted aggregate
Ordering and prices are now immutable
Propose block — batch digests and certified prices
Verify availability, ordering and prices
Vote
Certify round
Commit
Rounds each have a designated leader. Within a round a proposal collects successive 2f+12f+1 signature aggregates, and the phases pipeline across adjacent rounds, so a block reaches finality in two network round-trips in the common case. Under optimistic responsiveness, progress is bounded by actual message delay; the pacemaker’s backoff only engages when the network is adversarial or partitioned.

​
Committing an ordering

The transaction order inside a block is promoted to a consensus-committed object rather than left as an artifact of execution. The block hash covers the ordered payload, so any reordering after consensus invalidates the signatures that committed it. The effect: once a block is finalized, a 2f+12f+1 stake-weighted quorum has signed a commitment to that exact ordering, and no honest validator will have signed a different ordering of the same transactions in the same round. Combined with sequential execution over that committed order, this is what turns deterministic replay from an implementation convention into a property anyone can check.
Leader discretion within a single proposal — which available batches to include and how to arrange them — remains a residual surface, mitigated by leader reputation and by the fact that a leader cannot produce a block at all without valid price observations. Stronger fair-ordering constructions are tracked as a candidate future upgrade.

​
Batch availability

In a naive protocol a leader proposes a block whose payload carries all of the round’s transactions, coupling consensus message size to throughput. IntentionBFT separates data dissemination from ordering. Validators continuously disseminate transaction batches in the background. Each batch is acknowledged until its originator can prove 2f+12f+1 stake-weighted availability, and only then may a proposal reference it — by digest, not by contents. Consensus messages stay small regardless of throughput, and a committed block is always replayable, because no block can reference data that a Byzantine minority alone was holding.

​
Certifying prices

Validators are also price observers, and a block carries the prices it was executed against.
Oracle sidecarone per validator
The validator validates and signsincluding freshness against configured thresholds
Gossiped between validatorsas a consensus network message
Certified pricesper epoch and round
Price availability gates block productionA validator is eligible to propose a block only if it can present valid price observations for the current round — so the signatures that commit the transactions also commit the prices those transactions settle against.
What this does not claimIt binds price to transaction. It does not make the price correct — consensus certifies that a quorum of validators submitted these observations at this round, nothing more.
Each validator runs its own oracle sidecar, which collects venue data and produces an index price per instrument. The validator pulls that price, validates it — including freshness against configured thresholds — signs it, and gossips the signed submission to other validators as a consensus network message. Certified prices are assembled per epoch and round and carried in the block, so the signatures that commit the transactions also commit the prices those transactions settle against. A validator is eligible to propose a block only if it can present valid price observations for the current round. Price availability is therefore a precondition of block production, not an input that execution hopes to find.
This binds price to transaction; it does not make the price correct. Consensus certifies that a quorum of validators submitted these observations at this round. Whether the underlying venues were accurate is a separate question, addressed by the aggregation rules on the Oracle page and bounded by risk disclosures.

​
Leader reputation

Leaders are selected round-by-round by deterministic stake-weighted rotation, extended with a reputation heuristic over a sliding window. A validator with repeated failed proposals — indicating unavailability or adversarial behavior — is demoted in later selections and its slots redistributed to recently responsive validators, so an unavailable validator does not stall progress by claiming leadership of its assigned slots. Because price observations gate proposal eligibility, reputation also has to avoid concentrating leadership among validators with the best market-data connectivity. A venue-diversity requirement — observations drawn from multiple independent sources per instrument — closes that path.

​
Epochs and reconfiguration

Time is organized into epochs. Within an epoch the validator set and most parameters are constant. At epoch boundaries they may change through a reconfiguration authorized by governance: validator-set changes, consensus parameter changes, risk-parameter updates, and emergency actions. Transitions are atomic — every honest validator sees the same transition at the same block height.

​
Network topology

Validatorsconsensus · mempool · oracle sidecar · kernel · storage
The only participants that vote
Validator full nodesfollow and execute committed blocks; do not vote
Insulation — they absorb public read traffic and peer connections so validators are not directly exposed to the open internet
Public full nodesanyone can run one; follow, execute, serve reads
The open tier
Clientsfront ends · trading agents · market makers · indexers
They connect to full nodes, never to validators. A client that needs the lowest-latency, most complete view runs its own.
Four tiers, outward from consensus
Why the tier exists
Validators participate in consensus. Each one runs the full stack: consensus, mempool, an oracle sidecar, kernel execution, and storage. They are the only participants that vote. Validator full nodes sit directly behind validators. They follow committed blocks and execute them, but do not vote. Their purpose is insulation — they absorb public read traffic and peer connections so that validators are not directly exposed to the open internet. Public full nodes are the open tier. Anyone can run one. They follow the chain, execute committed blocks, serve reads, and feed downstream systems. Clients — front ends, trading agents, market makers, indexers — connect to full nodes rather than to validators. A client that needs the lowest-latency, most complete view runs its own full node rather than depending on someone else’s. Nodes joining the network do not replay from genesis by default; see state sync for how a new node catches up.

​
Where to go next

Mempool

What reaches consensus, in what order, and what gets dropped.

IntentionKernel

What happens to a block once its ordering and prices are committed.

Oracle

How an index price is produced before a validator signs it.

Run a node

Why the validator set is closed, and how to ask about joining.