IntentionBFT is Intention’s consensus protocol — a HotStuff-family BFT protocol extended with five mechanisms for running financial infrastructure. Safety is unconditional under the fault threshold; liveness holds after the network stabilizes.
Model
IntentionBFT tolerates a Byzantine adversary controlling up to f of the total stake S, subject to 3f<S. Honest stake is therefore always strictly greater than 2S/3. The standard quorum is any subset of validators whose combined stake strictly exceeds 2S/3 — a 2f+1 stake-weighted quorum. The network is partially synchronous: before a Global Stabilization Time delays are arbitrary; after it, delays between honest validators are bounded.
The HotStuff pipeline
Consensus is organized into rounds, each with a designated leader. Within a round, a proposal progresses through three phases — prepare, pre-commit, commit — each collecting a 2f+1 stake-weighted signature aggregate. The phases are pipelined across adjacent rounds, so a block reaches finality in two network round-trips in the common case. The two-chain commit rule says a block is committed once a descendant of its descendant has been certified. Under optimistic responsiveness, forward progress is bounded by actual message delay; the pacemaker’s exponential-backoff timeout kicks in only when the network is adversarial or partitioned. IntentionBFT inherits its safety and liveness from HotStuff; the extensions below add properties on top of that inheritance.
Extension 1 — Batch availability
In a naive protocol, a leader proposes a block whose payload contains all of the round’s transactions, coupling consensus message size to throughput. IntentionBFT decouples data dissemination from consensus ordering using a construction in the Narwhal / Bullshark / Quorum Store family. Validators continuously broadcast transaction batches in the background, each acknowledged so the originator can prove 2f+1 stake-weighted availability before referencing it in a proposal. Block proposals reference batches by cryptographic digest rather than carrying the full contents, so consensus messages stay small regardless of throughput. The 2f+1 availability requirement prevents the “unreplayable committed block” failure mode.
Extension 2 — Canonical Sequencing Commitment
The Canonical Sequencing Commitment (CSC) promotes the transaction order within a block to a first-class consensus-committed object. In its implicit form, the block hash covers the ordered payload, so any post-consensus reordering would invalidate the signatures. In its explicit form, the ordering is exposed as a distinct signed component in the vote data.
The theorem: if a block is finalized by a quorum certificate, 2f+1 stake-weighted validators have signed a commitment to the specific ordering. No honest validator will have signed any other ordering of the same transactions in the same (epoch,round). Combined with sequential execution over that committed order, CSC elevates OTD from an implementation convention to a cryptographically committed property.
Leader discretion within a single proposal — which available batches to include and how to arrange them — remains a known residual surface, mitigated by price-aware leader eligibility and reputation demotion. Stronger fair-ordering constructions in the Aequitas / Themis family are tracked as a candidate future upgrade.
Extension 3 — In-consensus price quorums
Validators are also price observers. Each validator collects market data from approved external venues; the leader aggregates these via stake-weighted median with MAD outlier rejection and embeds the resulting price quorum in the block payload, so it is covered by the same quorum certificate as the transactions. Under the f<S/3 threshold, a Byzantine coalition cannot move the stake-weighted median outside the range of honest observations. The Oracle page covers the mechanics in detail.
A validator is eligible to propose a block only if it can demonstrate valid price observations for the current round. PTA is therefore not merely an execution-layer property — it is a precondition of block production.
Extension 4 — Stake-weighted 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 subsequent selections, with its slots redistributed to recently responsive validators. An unavailable validator does not stall progress by claiming leadership of its assigned slots. A venue-diversity requirement — each validator must draw observations from multiple independent venues per instrument — closes the concentration path that price-aware eligibility would otherwise create.
Extension 5 — Post-quantum migration path
IntentionBFT currently uses Ed25519 for individual signatures and BLS12-381 for aggregation. Migration to post-quantum schemes targets ML-DSA (NIST FIPS 204) as primary and SLH-DSA (FIPS 205) as backup. In the hybrid phase, validators sign each vote with both a classical and an ML-DSA signature. In the PQ-only phase, governance removes the classical requirement at an epoch boundary.
A design property makes this tractable: the core mechanisms (CSC, price quorums, PTA) refer only to the abstract notion of a 2f+1 stake-weighted signature over a message — they do not depend on any specific cryptographic construction. Native key rotation lets each validator rotate to a hybrid key pair before the mandatory deadline.
Epoch boundaries 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 transaction authorized by a governance quorum: validator-set changes, consensus parameter changes (including the PQ transition), risk-parameter updates, and emergency actions. Transitions are atomic — every honest validator sees the same transition at the same block height. 
