> ## 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

> Consensus: how an ordering and a certified price vector are committed together, and how the network is laid out.

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](/protocol/architecture/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+1$ stake-weighted quorum**. The network is partially synchronous: before a stabilization point delays are arbitrary; after it, delays between honest validators are bounded.

<div className="dg" data-dg="bft-round">
  <div className="dg-c" style={{aspectRatio:"720 / 318"}}>
    <svg className="dg-w" viewBox="0 0 720 318" aria-hidden="true">
      <path className="dg-rule dg-dash" d="M 90 40 L 90 266" />

      <path className="dg-rule dg-dash" d="M 360 40 L 360 266" />

      <path className="dg-rule dg-dash" d="M 630 40 L 630 266" />

      <path className="dg-wire dg--blue" d="M 94.00 64.00 L 349.60 64.00" />

      <path className="dg-head dg--blue" d="M 356.00 64.00 L 349.60 68.40 L 349.60 59.60 Z" />

      <path className="dg-wire dg--sky" d="M 364.00 92.00 L 414.00 92.00 L 414.00 114.00 L 374.40 114.00" />

      <path className="dg-head dg--sky" d="M 368.00 114.00 L 374.40 109.60 L 374.40 118.40 Z" />

      <path className="dg-wire dg--sky dg-dash" d="M 356.00 146.00 L 100.40 146.00" />

      <path className="dg-head dg--sky" d="M 94.00 146.00 L 100.40 141.60 L 100.40 150.40 Z" />

      <path className="dg-wire dg--blue" d="M 94.00 218.00 L 349.60 218.00" />

      <path className="dg-head dg--blue" d="M 356.00 218.00 L 349.60 222.40 L 349.60 213.60 Z" />

      <path className="dg-wire dg--green dg-dash" d="M 364.00 254.00 L 619.60 254.00" />

      <path className="dg-head dg--green" d="M 626.00 254.00 L 619.60 258.40 L 619.60 249.60 Z" />
    </svg>

    <div className="dg-b dg--blue" style={{left:"2.2222%",top:"0.0000%",width:"20.5556%",height:"9.4340%"}}><span className="dg-t">Leader</span></div>
    <div className="dg-b dg--sky" style={{left:"39.7222%",top:"0.0000%",width:"20.5556%",height:"9.4340%"}}><span className="dg-t">Validators</span></div>
    <div className="dg-b dg--green" style={{left:"77.2222%",top:"0.0000%",width:"20.5556%",height:"9.4340%"}}><span className="dg-t">Chain</span></div>
    <div className="dg-b dg-dashed dg-tight dg-solid" style={{left:"14.4444%",top:"52.2013%",width:"33.6111%",height:"8.1761%"}}><span className="dg-s">2f+1 stake-weighted aggregate</span></div>
    <div className="dg-b dg--green" style={{left:"68.8889%",top:"86.7925%",width:"31.1111%",height:"11.9497%"}}><span className="dg-s">Ordering and prices are now immutable</span></div>
    <div className="dg-lbl" style={{left:"31.2500%",top:"15.0943%",width:"34.4444%",whiteSpace:"normal"}}>Propose block — batch digests and certified prices</div>
    <div className="dg-lbl" style={{left:"72.7778%",top:"32.3899%",width:"26.3889%",whiteSpace:"normal"}}>Verify availability, ordering and prices</div>
    <div className="dg-lbl" style={{left:"31.2500%",top:"40.8805%"}}>Vote</div>
    <div className="dg-lbl" style={{left:"31.2500%",top:"63.5220%"}}>Certify round</div>
    <div className="dg-lbl" style={{left:"68.7500%",top:"74.8428%"}}>Commit</div>
  </div>
</div>

Rounds each have a designated leader. Within a round a proposal collects successive $2f+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+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.

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

## 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+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.

<div className="dg" data-dg="bft-prices">
  <div className="dg-c" style={{aspectRatio:"720 / 318"}}>
    <svg className="dg-w" viewBox="0 0 720 318" aria-hidden="true">
      <path className="dg-wire" d="M 163.00 78.00 L 176.60 78.00" />

      <path className="dg-head" d="M 183.00 78.00 L 176.60 82.40 L 176.60 73.60 Z" />

      <path className="dg-wire" d="M 350.00 78.00 L 363.60 78.00" />

      <path className="dg-head" d="M 370.00 78.00 L 363.60 82.40 L 363.60 73.60 Z" />

      <path className="dg-wire" d="M 537.00 78.00 L 550.60 78.00" />

      <path className="dg-head" d="M 557.00 78.00 L 550.60 82.40 L 550.60 73.60 Z" />
    </svg>

    <div className="dg-b dg--sky" style={{left:"0.0000%",top:"8.1761%",width:"22.0833%",height:"32.7044%"}}><span className="dg-t">Oracle sidecar</span><span className="dg-s">one per validator</span></div>
    <div className="dg-b dg--blue" style={{left:"25.9722%",top:"8.1761%",width:"22.0833%",height:"32.7044%"}}><span className="dg-t">The validator validates and signs</span><span className="dg-s">including freshness against configured thresholds</span></div>
    <div className="dg-b dg--blue" style={{left:"51.9444%",top:"8.1761%",width:"22.0833%",height:"32.7044%"}}><span className="dg-t">Gossiped between validators</span><span className="dg-s">as a consensus network message</span></div>
    <div className="dg-b dg--green" style={{left:"77.9167%",top:"8.1761%",width:"22.0833%",height:"32.7044%"}}><span className="dg-t">Certified prices</span><span className="dg-s">per epoch and round</span></div>
    <div className="dg-b dg--orange dg-left" style={{left:"0.0000%",top:"48.4277%",width:"100.0000%",height:"21.3836%"}}><span className="dg-t">Price availability gates block production</span><span className="dg-s">A 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.</span></div>
    <div className="dg-b dg-dashed dg-left" style={{left:"0.0000%",top:"75.4717%",width:"100.0000%",height:"19.4969%"}}><span className="dg-t">What this does not claim</span><span className="dg-s">It 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.</span></div>
  </div>
</div>

Each validator runs its own [oracle sidecar](/protocol/architecture/oracle), 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.

<Warning>
  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](/protocol/architecture/oracle) page and bounded by [risk disclosures](/protocol/security/risks).
</Warning>

## 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

<div className="dg" data-dg="bft-topology">
  <div className="dg-c" style={{aspectRatio:"720 / 322"}}>
    <svg className="dg-w" viewBox="0 0 720 322" aria-hidden="true">
      <path className="dg-wire dg-soft" d="M 215.00 95.00 L 215.00 99.00" />

      <path className="dg-wire dg-soft" d="M 215.00 167.00 L 215.00 171.00" />

      <path className="dg-wire dg-soft" d="M 215.00 239.00 L 215.00 243.00" />
    </svg>

    <div className="dg-b dg--blue dg-left" style={{left:"0.0000%",top:"9.3168%",width:"59.7222%",height:"19.2547%"}}><span className="dg-t">Validators</span><span className="dg-s">consensus · mempool · oracle sidecar · kernel · storage</span></div>
    <div className="dg-b dg-plain dg-left" style={{left:"63.6111%",top:"9.3168%",width:"36.3889%",height:"19.2547%"}}><span className="dg-s">The only participants that vote</span></div>
    <div className="dg-b dg--sky dg-left" style={{left:"0.0000%",top:"31.6770%",width:"59.7222%",height:"19.2547%"}}><span className="dg-t">Validator full nodes</span><span className="dg-s">follow and execute committed blocks; do not vote</span></div>
    <div className="dg-b dg-plain dg-left" style={{left:"63.6111%",top:"31.6770%",width:"36.3889%",height:"19.2547%"}}><span className="dg-s">Insulation — they absorb public read traffic and peer connections so validators are not directly exposed to the open internet</span></div>
    <div className="dg-b dg--sky dg-left" style={{left:"0.0000%",top:"54.0373%",width:"59.7222%",height:"19.2547%"}}><span className="dg-t">Public full nodes</span><span className="dg-s">anyone can run one; follow, execute, serve reads</span></div>
    <div className="dg-b dg-plain dg-left" style={{left:"63.6111%",top:"54.0373%",width:"36.3889%",height:"19.2547%"}}><span className="dg-s">The open tier</span></div>
    <div className="dg-b dg--green dg-left" style={{left:"0.0000%",top:"76.3975%",width:"59.7222%",height:"19.2547%"}}><span className="dg-t">Clients</span><span className="dg-s">front ends · trading agents · market makers · indexers</span></div>
    <div className="dg-b dg-plain dg-left" style={{left:"63.6111%",top:"76.3975%",width:"36.3889%",height:"19.2547%"}}><span className="dg-s">They connect to full nodes, never to validators. A client that needs the lowest-latency, most complete view runs its own.</span></div>
    <div className="dg-free" style={{left:"0.0000%",top:"0.0000%",width:"59.7222%"}}><div className="dg-n">Four tiers, outward from consensus</div></div>
    <div className="dg-free" style={{left:"63.6111%",top:"0.0000%",width:"36.3889%"}}><div className="dg-n">Why the tier exists</div></div>
  </div>
</div>

**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](/protocol/architecture/state/sync) for how a new node catches up.

## Where to go next

<CardGroup cols={2}>
  <Card title="Mempool" href="/protocol/architecture/mempool">
    What reaches consensus, in what order, and what gets dropped.
  </Card>

  <Card title="IntentionKernel" href="/protocol/architecture/kernel">
    What happens to a block once its ordering and prices are committed.
  </Card>

  <Card title="Oracle" href="/protocol/architecture/oracle">
    How an index price is produced before a validator signs it.
  </Card>

  <Card title="Run a node" href="/developers/run-a-node">
    Why the validator set is closed, and how to ask about joining.
  </Card>
</CardGroup>