Skip to main content
HotStuff L1 is a purpose‑built, exchange‑grade Layer‑1 optimized for on‑chain order books, margining, and custody. It combines a pipelined, two‑round BFT protocol (DracoBFT) with deterministic execution, modular side‑consensus loops, and a “Change‑Log Hash” (CLH) commitment scheme that replaces heavyweight global state‑root computation. The result is sub‑second finality, high throughput, and a developer experience that treats trading and settlement as first‑class primitives. A dual‑block roadmap, Engine API compatibility, and trustless proof ingestion (SP1, zkTLS/zkFetch) connect HotStuff to the broader EVM and real‑world rails.

​
Motivation

Most general‑purpose L1s optimize for smart‑contract flexibility at the expense of deterministic latency, transaction ordering, and predictable execution under throughput pressure. Exchange workloads (order placement, cancels, matching, margin updates, liquidations) have stricter requirements:
  • Deterministic, Pipelined Finality under partial synchrony.
  • State‑Update Heavy Throughput without global trie bottlenecks.
  • MEV‑Resistant Ordering and fairness constraints for order books.
  • Composable Proofs of external events (on‑chain and off‑chain) to trigger actions.
  • Practical Cryptoeconomics where core trading actions are gasless, while auxiliary environments use gas for general computation.
HotStuff L1 addresses these with DracoBFT, CLH commitments, and a modular execution fabric.

​
Architecture Overview

​
DracoBFT (Pipelined Two‑Round BFT)

DracoBFT is a leader‑based, round‑driven BFT state‑machine replication (SMR) protocol derived from the HotStuff lineage and two‑round optimizations. It achieves full finality in two rounds under a correct leader, with linear view change, and pipelined proposal/commit to keep the network saturated. Safety is Quorum Certificate (QC) based; liveness holds under partial synchrony.

​
Pipelining

DracoBFT decouples proposal, vote, and commit across consecutive rounds. Leaders propose when they possess a valid QC for the highest known block; replicas speculatively process and pre‑stage votes, enabling a steady 2‑round commit cadence. This keeps effective commit latency near (~2\Delta) in optimistic conditions.

​
Side Consensus Event Loops

In addition to the primary loop (order‑book + margining FSM), HotStuff L1 supports side consensus loops with their own leaders and committees. Side loops handle auxiliary workflows (e.g., proof verification, settlement netting, custodial attestations) without stalling the primary loop. When a side loop needs to affect canonical exchange state, it emits an action envelope that is re‑injected into the primary loop and finalized with the same two‑round guarantees. Committees are pluggable and may be stake‑weighted or permissioned per application.

​
Deterministic Ordering = Deterministic Execution

Transactions/actions are ordered using a ruleset that combines action class (e.g., new order, cancel, liquidation) with ingress timestamp and explicit tie‑breakers (deterministic, verifiable). Deterministic ordering ensures that every correct replica produces identical state transitions and events.

​
State & Block Synchronization

  • State Snapshots. Nodes periodically produce state snapshots. A joining node obtains the most recent snapshot, verifies its QC/CLH, computes a target view, then requests missing blocks to catch up before switching to live proposals.
  • Block Synchronization. Nodes can fetch blocks and proofs by number/range from peers. Missing segments are requested opportunistically; snapshots minimize cold‑start time while preserving verifiability.

​
Change‑Log Hash (CLH) Commitments

Instead of computing a global state root each block, HotStuff L1 commits to a Change‑Log Hash: a cryptographic digest of all deterministic state deltas produced by the block. CLH values are chained (parent‑included), yielding a tamper‑evident sequence of per‑block state changes. This eliminates high‑latency global trie updates while preserving verifiability and auditability. Sketch: For each block, derive an ordered stream of changes (key, pre, post) from the FSM. Serialize canonically; hash via a collision‑resistant Merkle accumulator. Commit CLH_b = H(CLHB_{b-1} || MerkleRoot(changes_b) || QC_b). Light clients verify safety via QCs; full nodes can replay deltas to reconstruct state or materialize a trie lazily for contract modules that need it. Rationale: CLH matches exchange workloads where the correctness primitive is “exactly these deltas were applied in this order”. For modules that require authenticated key‑value proofs, HotStuff can maintain secondary tries/commitments asynchronously without gating finality.

​
Engine API Compatibility & Dual‑Block Roadmap

HotStuff L1 plans Engine API compatibility so an EVM environment can run alongside the exchange core. A dual‑block roadmap mirrors the separation of concerns: small, fast blocks for core actions; large, slower blocks for contract‑heavy work. This preserves gasless UX on core while enabling gas‑metered general computation in the EVM context.

​
Cryptoeconomics

​
Validator Incentives

  • Gasless Core; Metered Auxiliary. Core trading actions are gasless; validators are compensated via (a) protocol distributions sourced from EVM gas, bridges, or programmatic revenue shares; and (b) service‑provider fees for permissioned auxiliary services (on/off‑ramps, KYC custody, FX rails) offered by whitelisted operators running validator software modules. Participation in these modules is optional and gated by compliance + quality‑of‑service rules recorded on‑chain.
  • Staking & Slashing. Stake‑weighted leader selection with slashing for equivocation, safety violations (conflicting QCs), censorship (provable), and quality‑of‑service breaches in service modules. Side‑loop committees may have distinct stake and risk parameters.

​
Execution Environments: Non‑EVM → Dual‑Block

Phase 1 ships a non‑EVM core specialized for order‑book and margining. Phase 2 adds an EVM environment with a dual‑block schedule. Core remains gasless; EVM uses a native gas token. Cross‑environment calls are mediated by action envelopes and capability filters to preserve determinism and latency on the core path.

​
Real‑World DeFi: Validators as Coordinators

Validators (or permissioned committees) can coordinate institutional workflows: fiat↔stablecoin ramps, settlement with banks/PSPs, FX, custody attestations. These actions are provable and rate‑limited, with trust minimized via external proofs (Section 4) and transparent on‑chain policy.

​
Trustless Proof Ingestion

HotStuff L1 integrates two proof rails to trustlessly trigger actions:

​
On‑Chain Proofs via SP1

For actions contingent on another chain’s state (e.g., Ethereum), off‑chain provers generate SP1 proofs of smart‑contract execution. Side loops verify SP1 proofs (cheaply, on‑chain or in a verifier module) and emit action envelopes to the primary loop.

​
Off‑Chain Proofs via zkTLS / zkFetch

For actions based on Web2 APIs (payments, bank ledgers, FX quotes), zkTLS/zkFetch produces a verifiable transcript of an HTTPS fetch—including private API key usage—without revealing secrets. Side loops validate these proofs and translate them into canonical actions.

​
Example Flows

  • On‑Chain Deposit Unlock: User calls an Ethereum gateway contract; event + state checked by SP1 proof; HotStuff side loop verifies proof; primary loop credits balance.
  • Off‑Chain Receipt: PSP ledger exposes HTTPS endpoint; zkFetch proof attests to a credited payment; side loop validates; primary loop releases stablecoins.

​
DeFi‑CeFi Rails & Signature Schemes

HotStuff embraces multi‑scheme signing to interoperate across venues and L1/L2s:
  • ECDSA (secp256k1): Native to many chains and widely supported. Used for HotStuff multisig accounts and EVM bridges.
  • Ed25519 (EdDSA): Required by some centralized venues (e.g., Binance) and supported by others (e.g., Deribit asymmetric API keys). Validators can co‑sign venue orders using Ed25519 for multi‑venue strategies.
  • BLS12‑381: Ubiquitous on Ethereum’s consensus layer and ZK ecosystems. While general BLS verification is not yet universally precompiled in EVMs, HotStuff’s verifier modules can batch/aggregate off‑chain or leverage chains with BLS precompiles.
  • Threshold Signatures (TSS): Validator committees can generate t‑of‑n ECDSA/EdDSA signatures via MPC libraries. This avoids single‑point HSMs, supports key resharing, and yields standard signatures accepted broadly.
Bridge Design. The HotStuff bridge (EVM contract) accepts arrays of validator ECDSA signatures today; future versions can switch to BLS aggregate verification where precompiles exist. Off‑chain, a signing service abstracts MPC/TSS and policy. Use Cases: Cross‑exchange market making, basis/funding arbitrage, coordinated liquidation backstops, and off‑ramp/on‑ramp attestations signed by validator committees.

​
Customer Acquisition Primitives

  • Builder Codes. On‑chain referral + usage attestations scoped to builders (bots, MM strategies, integrators) with programmable rebates and API throughput budgets.
  • Hyper‑Local Payment Rails. Regional validator‑operators offer optional fiat rails via zkFetch‑verifiable PSP integrations; users discover providers via on‑chain QoS registries.
  • Neobank Coordination Layer. Side loops standardize issuance of crypto cards, virtual accounts, and KYB‑gated stablecoin wallets; settlement proofs feed the core for instant exchange funding.

​
Roadmap (High‑Level)

  1. Alpha: DracoBFT core + CLH commitments; deterministic ordering; snapshots; basic side loops; ECDSA multisig; MPC‑ECDSA.
  2. Beta: Proof rails (SP1 verifier; zkFetch integration); service‑provider modules; quality‑of‑service metrics; Ed25519 support.
  3. v1.0: Engine API‑compatible EVM; dual‑block scheduling; bridge contracts; optional BLS verifiers on supported chains.

​
Security Considerations

  • Safety: QC‑based commit rules, lock rules, and slashable evidence for equivocation/censorship.
  • Liveness: Linear view change; responsive leaders; pipelined proposal/commit; committee fallback.
  • Data Integrity: CLH chaining; optional secondary tries/verkle/KZG for modules that need key‑value proofs.
  • Proof Soundness: Third‑party audits for SP1 verifier and zkTLS circuits; sequenced rollouts with canary committees.
  • Key Management: MPC/TSS for validator and venue keys; key rotation and resharing without downtime.

​
Glossary

  • CLH: Change‑Log Hash – per‑block commitment to ordered state deltas.
  • QC: Quorum Certificate – aggregated votes proving a block’s safety predicate.
  • Side Loop: An auxiliary consensus committee running in parallel to the primary loop.
  • Engine API: JSON‑RPC interface between consensus and execution layers, used by Ethereum clients and compatible systems.