Skip to main content
The network layer turns signed transactions into committed blocks. Each block commits two things under one set of signatures: the order of its transactions, and the prices those transactions settle against. The kernel then executes against both.

​
IntentionBFT

IntentionBFT is a HotStuff-family BFT protocol. It tolerates up to one third Byzantine stake and finalizes a block in two network round-trips in the common case. What Intention adds is in the payload: every block carries the prices it is executed against.

​
Prices certified in the block

Oracle sidecarone per validator
The validator validates and signsincluding freshness against configured thresholds
Gossiped between validatorsas a consensus network message
Certified pricesindex and external perpetual mid, per 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 produces an index price and an external perpetual mid per instrument from venue data. The validator checks both for freshness, signs them, and shares them with the other validators. The block carries the median of observations from validators holding at least two thirds of voting power, so the signatures that commit the transactions also commit their prices. The mark price is not certified: every node computes it from these inputs, deterministically.
  • No valid price, no block. A validator can propose a block only if it presents valid price observations for the current round.
  • No single data source. Observations must come from multiple independent venues per instrument, so leadership cannot concentrate among the validators with the best market-data connections.

​
Mempool

The mempool sequences transactions by what they do, not by when they arrived: each block orders them by protocol rules tuned to market microstructure. Liquidations are not transactions: the kernel runs them before any user order, so they cannot be front-run. Transaction sequencing gives the full rules. The mempool also validates a transaction before storing it, and returns a reason for every rejection.
Signed transaction
Validationsignature · format · account state · can the sender pay for it
Dropped, with a reason returnednot silently — the submitter is told why
Transaction store
Peer broadcast
Batch formation, then consensus
Validation is cheap and local, so the expensive resources downstream are spent only on transactions that could actually execute.
rejected
accepted
What this means for a client:
  • A rejection at submission is useful. The reason describes something you can fix.
  • Silence is not rejection. A valid transaction that is not yet next for its account waits until the gap in front of it closes, then becomes eligible. Track what you submitted and what committed.
  • Arrival time does not decide priority. Within a phase, transactions from different senders are ordered by consensus, not by who submitted first.
  • Heavy senders are shaped, not capped. Fairness is tracked over recent history, so one account’s order-and-cancel storm cannot crowd out the rest, without a hard per-account rate limit.