> ## Documentation Index
> Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# IntentionBFT

> HotStuff-family consensus extended with canonical sequencing, in-consensus price quorums, batch availability, and leader reputation.

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 $(\text{epoch}, \text{round})$. Combined with sequential execution over that committed order, CSC elevates [OTD](/architecture/otd) from an implementation convention to a cryptographically committed property.

<Note>
  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.
</Note>

## 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](/architecture/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](/architecture/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.