Bullshark: DAG-Based Byzantine Fault-Tolerant Protocol

Updated 6 July 2026

Bullshark is a DAG-based Byzantine fault-tolerant ordering protocol that separates data dissemination from order computation, using Narwhal’s certified DAG for reliable broadcast.
It achieves high throughput by allowing validators to work in parallel and extract total order from existing DAG edges without sending extra consensus messages.
Its design integrates leader anchors, quorum intersection, and adaptable voting rules, making it influential in practical deployments and future protocol enhancements.

Searching arXiv for recent Bullshark papers and related analyses to ground the article. arxiv_search(query="Bullshark DAG BFT Narwhal consensus", max_results=10) arxiv_search(query="Bullshark DAG BFT Narwhal consensus", max_results=10) is not available in this environment. Proceeding with the supplied arXiv dataset, which already contains the relevant papers and details needed for a research-grounded article. Bullshark is a directed acyclic graph (DAG)-based Byzantine fault-tolerant ordering protocol, or Byzantine Atomic Broadcast (BAB) protocol, that operates on top of a Narwhal-style certified data-dissemination layer. Its defining architectural move is to separate dissemination and equivocation elimination from ordering: vertices are reliably disseminated first, and validators then derive a total order by locally interpreting the DAG, without sending additional consensus messages. In its original formulation, Bullshark was introduced as the first DAG-based asynchronous BAB protocol optimized for the common synchronous case, while later work provided a separate deterministic partially synchronous presentation and multiple implementation-level, analytical, and comparative extensions (Spiegelman et al., 2022).

1. Origins and position in the DAG-BFT lineage

Bullshark belongs to the family of DAG-based BFT protocols that includes DAG-Rider, Tusk, and Narwhal-based designs. In this family, every validator contributes to data dissemination in parallel, and consensus is extracted from the graph structure rather than from a separate stream of vote or commit messages. Bullshark retains the “zero-overhead” property emphasized in the original work: ordering is computed from the existing DAG edges rather than by adding a distinct consensus message path (Spiegelman et al., 2022).

The protocol is usually presented as an ordering layer over Narwhal’s certified DAG. Narwhal handles availability, anti-equivocation, and reliable dissemination, while Bullshark consumes the resulting certified sub-DAGs and outputs a total order. This split is central to Bullshark’s identity in both theoretical and implementation-oriented accounts, because it isolates the throughput-oriented data plane from the simpler ordering logic (Tanaka, 7 Jul 2025).

Bullshark also occupies an intermediate position on what later work describes as the leader–DAG spectrum. It preserves the throughput benefits of parallel DAG dissemination, yet introduces leader anchors and timeouts so that partial synchrony can be exploited for lower latency than fully asynchronous DAG ordering. Comparative work therefore places Bullshark between fully decoupled asynchronous DAG protocols and tightly leader-driven partially synchronous protocols (Yu et al., 19 Sep 2025).

Production-oriented literature treats Bullshark as more than a purely theoretical construction. The Autobahn study describes Bullshark as a state-of-the-art DAG-based BFT protocol adopted in production systems such as Sui and Aptos, while Sui-focused studies analyze a Bullshark-like or BullShark-derived implementation written in Rust (Giridharan et al., 2024, Liu et al., 28 May 2026).

2. System model, dissemination layer, and DAG structure

The canonical Bullshark model assumes a committee of $n = 3f + 1$ validators with up to $f$ Byzantine faults, and quorums of size $2f + 1$. Partial synchrony is expressed in the Dwork-Lynch-Stockmeyer model through an unknown Global Stabilization Time (GST), after which messages between honest validators are delivered within a known bound $\Delta$ (Spiegelman et al., 2022). The original asynchronous formulation also uses a shared coin for fallback progress, while a later quorum-size study generalizes the validator set as $n = kf + 1$ with $k \ge 2$ to study reduced or expanded redundancy (Ladelsky et al., 10 Apr 2025).

Bullshark cleanly separates equivocation elimination from committing. The generalized quorum analysis describes a reliable Byzantine broadcast black-box that disseminates vertices and guarantees agreement, integrity, and validity for delivered messages. This ensures that each validator eventually delivers the same vertex per sender per round and prevents a sender from producing two different vertices for the same round (Ladelsky et al., 10 Apr 2025).

At the DAG layer, each validator creates at most one vertex per round. In the standard $n = 3f + 1$ presentation, each vertex references at least $n - f = 2f + 1$ vertices from the previous round, which yields the dense parent structure on which Bullshark’s reachability arguments rely (Spiegelman et al., 2022). In the generalized $n = kf + 1$ formulation, each round contains between $(k-1)f+1$ and $f$ 0 vertices, and each vertex references at least $f$ 1 vertices from round $f$ 2 (Ladelsky et al., 10 Apr 2025).

Implementation analyses make the Narwhal/Bullshark split concrete. Workers receive client transactions, validate and batch them, disseminate batches, and send digests to a local primary. The primary constructs headers using payload digests and parent certificates, gathers $f$ 3 votes, forms a certificate, and exports certified vertices to Bullshark for ordering (Tanaka, 7 Jul 2025). This layered workflow is a practical realization of the more abstract claim that Bullshark adds total order on top of reliable broadcast without adding consensus-layer network traffic.

3. Ordering logic: anchors, votes, direct commit, and indirect commit

Bullshark’s ordering rule is local: DAG edges act as votes, and anchors or leaders are committed by checking reachability and quorum support within the local DAG view. The literature presents two main formulations.

In the deterministic partially synchronous manuscript, even rounds have predefined leaders, whose vertices are the round anchors, and odd rounds vote for the previous even round’s anchor. An anchor $f$ 4 in even round $f$ 5 is committed if there are at least $f$ 6 vertices in odd round $f$ 7 that vote for it; operationally, commitment is detected when a vertex in even round $f$ 8 arrives and at least $f$ 9 of its parents in round $2f + 1$0 have a path to $2f + 1$1 (Spiegelman et al., 2022). Once an anchor commits, validators walk backward over earlier anchors: if a future anchor has a path to an earlier anchor, that earlier anchor is ordered before it; if there is no such path, the earlier anchor is safely skipped.

The asynchronous formulation is more elaborate. Waves consist of four rounds and involve steady-state leaders, a fallback leader chosen via a shared coin, and per-validator voting types. Direct commit rules depend on type-aligned support sets of size $2f + 1$2: a fallback leader of wave $2f + 1$3, the second steady-state leader of wave $2f + 1$4, or the first steady-state leader of wave $2f + 1$5 is directly committed when enough potential votes of the matching type have paths to that leader. Indirect commit then traverses backward and commits prior candidate leaders if one vote type has at least $2f + 1$6 votes while the other has at most $2f + 1$7 votes (Ladelsky et al., 10 Apr 2025).

Implementation-level Sui analyses describe yet another concrete view of the same family: a wave spans four rounds, there are two anchor leaders per wave plus a fallback leader, and a steady-state commit requires both vote thresholds and linkage across anchors. In that account, if $2f + 1$8, $2f + 1$9, and $\Delta$ 0 hold, then anchors are committed in order and all previously uncommitted vertices in their causal pasts are atomically committed as well (Tanaka, 7 Jul 2025).

A common invariant across these presentations is that Bullshark orders anchors and then linearizes their causal histories deterministically. This design is what allows the protocol to advertise zero consensus communication overhead: the entire commit structure is extracted from already-disseminated DAG metadata.

4. Quorum geometry, safety, liveness, and the role of synchrony

Bullshark’s safety arguments are based on quorum intersection in the round-based DAG. In the deterministic partially synchronous account, every vertex references at least $\Delta$ 1 parents, and any two such parent sets intersect in at least $\Delta$ 2 elements. This intersection is used to show that if an honest party commits an anchor, every future anchor has a path to it, which in turn justifies the safe-skip rule and the agreement on total order (Spiegelman et al., 2022).

The later quorum-size analysis sharpens this point by asking whether asynchronous Bullshark remains correct once equivocation has been removed and the committee size is reduced from $\Delta$ 3 to $\Delta$ 4. Let $\Delta$ 5 and $\Delta$ 6. The relevant condition is

$\Delta$ 7

For $\Delta$ 8, so $\Delta$ 9 and $n = kf + 1$ 0, the intersection size is exactly $n = kf + 1$ 1, which guarantees an honest intersection. For $n = kf + 1$ 2, so $n = kf + 1$ 3 and $n = kf + 1$ 4, the minimum intersection is only $n = kf + 1$ 5, which may be Byzantine (Ladelsky et al., 10 Apr 2025).

This distinction is decisive for the asynchronous instance. The paper proves that asynchronous Bullshark is safe and live for $n = kf + 1$ 6 and not safe for $n = kf + 1$ 7, even when reliable broadcast has already eliminated equivocation. The reason is specific to Bullshark’s two-type voting and indirect-commit logic: with only $n = kf + 1$ 8 validators, a validator that directly commits using $n = kf + 1$ 9 same-type votes may be observed elsewhere through at most one shared vote, leaving ambiguity about whether the leader should be interpreted as steady-state or fallback (Ladelsky et al., 10 Apr 2025).

By contrast, the same study states that partially synchronous Bullshark is safe and live for all $k \ge 2$ 0. In that formulation, the partially synchronous instance uses deterministic leaders, timeouts aligned with $k \ge 2$ 1, direct commit thresholds of $k \ge 2$ 2, and indirect commit via causal paths, so the safety argument no longer depends on the stronger honest intersection required by the asynchronous two-type voting rules (Ladelsky et al., 10 Apr 2025).

The original paper adds a further claim about the asynchronous design: safety is “post-quantum” in the sense that it relies only on information-theoretic properties of reliable broadcast and the agreement/fairness/termination properties of the coin, while computational unpredictability is needed for liveness in asynchrony rather than for safety itself (Spiegelman et al., 2022).

5. Latency, throughput, and implementation-level workflow

Bullshark’s practical appeal is the combination of high throughput with comparatively simple ordering logic. The original implementation paper reports that the protocol was implemented in approximately 200 lines of code on top of Narwhal and reached 125,000 transactions per second with 2 seconds latency for a deployment of 50 parties (Spiegelman et al., 2022). A later implementation-level workflow analysis reports 297,000+ tx/s with approximately 2-second latency in production settings, and describes Bullshark as a round-based DAG BFT protocol over Narwhal that achieves zero-overhead consensus by ordering certified DAG metadata locally (Tanaka, 7 Jul 2025).

Latency analyses depend on the chosen presentation. The deterministic partially synchronous manuscript states that after GST an optimistic commit needs one odd voting round plus the next even round to collect parents, informally yielding approximately $k \ge 2$ 3 commit latency (Spiegelman et al., 2022). Comparative work that normalizes multiple DAG-based protocols instead reports Bullshark leader-vertex commit latency as $k \ge 2$ 4 and non-leader commit as an additional $k \ge 2$ 5 after GST (Yu et al., 19 Sep 2025). These are distinct accounting conventions rather than a single unified metric.

A recurring theme in later work is that Bullshark’s throughput comes with a latency premium. Shoal attributes this premium to two factors: bad leaders, which cause anchors to be skipped, and sparse anchors, because not every round contains an anchor. In its best-case characterization, anchors are ordered in 2 rounds, while non-anchor vertices require 3 to 4 rounds to be ordered (Spiegelman et al., 2023). Shoal then adds leader reputation and pipelining to reduce latency, reporting up to 40% latency reduction in failure-free executions and up to 80% reduction in executions with failures against vanilla Bullshark (Spiegelman et al., 2023).

The Sui workflow analysis makes the implementation path explicit. Workers batch transactions and disseminate them; primaries wait for enough digests and parent certificates, create headers, gather $k \ge 2$ 6 votes, form certificates, and feed the resulting sub-DAG into Bullshark. The paper reports default parameters such as header payload target $k \ge 2$ 7 batches, maximum 1000 batches, maximum header delay of 1,000 ms, and garbage-collection depth of 50 rounds (Tanaka, 7 Jul 2025). This suggests that Bullshark’s performance is inseparable from batching, certification, and garbage-collection policy in the Narwhal substrate, not merely from the abstract commit rule.

6. Extensions, critiques, and active research directions

Later work treats Bullshark as a baseline, a deployment target, and a source of reusable design ideas. The following developments illustrate the breadth of that research.

Line of work	Main modification	Stated effect
Shoal	Leader reputation and pipelining	Up to 40% latency reduction failure-free; up to 80% with failures (Spiegelman et al., 2023)
HammerHead	Dynamic leader scheduling for a Sui Bullshark-like protocol	2x latency reduction and up to 40% throughput increase with 100 validators, 33 faults (Tsimos et al., 2023)
Sparse Bullshark	Constant-size random parent sampling	Preserves $k \ge 2$ 8 while reducing metadata and improving scalability (Anoprenko et al., 16 Jun 2025)
Agora	Multi-agent protocol bug detection on Sui’s BullShark-style codebase	Found protocol-level DAG-layer bugs, including BlockManager memory exhaustion (Liu et al., 28 May 2026)
FairWave	Fairness-aware economic layer around DAG-BFT	Argues fairness risks arise from stake rules around Bullshark-like ordering, not from the ordering logic itself (Mujaddiq, 9 Jun 2026)

Sparse Bullshark is a particularly direct modification. It replaces the dense $k \ge 2$ 9 parent set with a constant-size random sample of size $n = 3f + 1$ 0, adds a verifiable sampling proof, and raises the direct commit threshold from $n = 3f + 1$ 1 to $n = 3f + 1$ 2. The paper states that this preserves the optimal resilience bound $n = 3f + 1$ 3 while reducing per-vertex metadata from $n = 3f + 1$ 4 references to $n = 3f + 1$ 5 references and lowering expected communication from $n = 3f + 1$ 6 to $n = 3f + 1$ 7 (Anoprenko et al., 16 Jun 2025).

Verification-oriented work has emphasized that Bullshark’s elegance at the protocol level does not remove implementation risk. Agora analyzes Sui’s BullShark-style DAG BFT implementation and identifies a DAG-layer vulnerability in the BlockManager: an unbounded “missing blocks” collection can be forced to grow until out-of-memory conditions or persistent liveness stalls occur under adversarial future-round flooding. The same paper treats cross-field consistency between certificate metadata and the block or round it certifies as another relevant bug pattern for BullShark-style systems (Liu et al., 28 May 2026). This is best understood not as a refutation of Bullshark’s proofs, but as evidence that production validation requires executable safety and liveness oracles in addition to paper proofs.

Fairness work has isolated a different issue. FairWave argues that the fairness risks observed in Bullshark-like Proof-of-Stake deployments are not caused by the DAG ordering logic per se; rather, they emerge when selection and reward rules around the consensus engine are stake-proportional, producing rich-get-richer dynamics, Sybil vulnerabilities under naive sub-linear rules, and concentration drift. In that framing, Bullshark contributes the fast DAG ordering substrate, while fairness must be addressed by the surrounding economic mechanism (Mujaddiq, 9 Jun 2026).

Finally, several protocols define themselves partly by comparison with Bullshark. Shoal++ keeps Bullshark’s certified DAG and anchor logic but adds fast direct commit, many anchors per round, and parallel staggered DAGs, claiming average latency reductions of up to 60% versus Bullshark while maintaining comparable throughput (Arun et al., 2024). Autobahn and BBCA-CHAIN make a different critique: Bullshark’s latency remains dominated by the cost of repeated DAG certification and vote interpretation, so they seek to preserve DAG-scale dissemination while replacing or compressing the Bullshark-style ordering path (Giridharan et al., 2024, Malkhi et al., 2023).

Bullshark therefore remains a reference design rather than a fixed endpoint. Its enduring contribution is the demonstration that a certified round-based DAG can carry enough structure to realize BAB with no extra ordering messages, while subsequent work continues to modify its quorum geometry, leader scheduling, dissemination density, latency path, fairness interface, and verification methodology.