> ## Content Index
> Fetch the complete content index at: https://www.notatechguy.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Orcaella protocol: choose fast commit or 54% fault tolerance
- URL: https://www.notatechguy.com/orcaella-protocol-choose-fast-commit-or-54-fault-tolerance/
- Published: 2026-07-13T00:40:23.000Z
- Updated: 2026-07-13T00:40:23.000Z
- Description: New preprint Orcaella lets clients pick a fast 2-message-delay commit or a resilient path tolerating 54% equivocation at double the latency.
- Author: Marcello Babbili
- Tags: Technology & AI

A new arXiv preprint called Orcaella lets consensus clients pick their own finality latency — a fast 2-message-delay commit tolerating 16% equivocating nodes, or a slower 4-message-delay path pushing that to 54%, in a 99-replica network \[S1\]. Double the wait, more than triple the resilience. But the fault model that makes this possible — and the recovery regime it falls back to when things go wrong — rewrites what "finality" means when some nodes are alive but lying.

## The speed-resilience dial

Most Byzantine fault-tolerant (BFT) consensus protocols force a single tradeoff: you pick your fault tolerance threshold and your latency, and you live with it. Orcaella's contribution is making that choice per-transaction, at the client level \[S1\].

The fast path commits in 2 message delays — what the paper calls a 1-RTT (round-trip time) commit. The authors prove a tight bound: to tolerate *f* crash faults and *c* alive-but-corrupt faults on this path, you need at least *n* ≥ 5*f* \+ 3*c* \+ 1 replicas \[S1\]. That bound is the mathematical floor — fewer nodes than that and you cannot guarantee both safety and liveness at 2-message-delay.

The resilient path adds two more message delays (4 total, or 2-RTT) and in exchange tolerates additional alive-but-corrupt faults up to *f*\_abc < *n* − 3*f* − 2*c* \[S1\]. Alive-but-corrupt (AbC) faults are a specific flavour of misbehaviour: the node is running, responding, not crashed — but it is sending conflicting information to different peers. Think of a witness who tells different stories to different detectives, rather than one who simply goes silent.

## The 99-node example

The paper grounds the abstract maths with a concrete configuration: *f* \= 16, *c* \= 6, *n* \= 99 \[S1\]. Plug those into the bound and 5(16) + 3(6) + 1 = 99 — the tightest possible fit.

In that network:

- **Liveness**: 22% of replicas (roughly 22 nodes) can fail and the protocol still makes progress \[S1\].
- **1-RTT safety**: 16% of nodes can equivocate — send conflicting messages — and the fast path still guarantees safety \[S1\].
- **2-RTT safety**: 54% of nodes can equivocate and the resilient path still holds \[S1\].

That last number is the headline. More than half the network can be actively lying, and the slower path still reaches a safe commit. In traditional BFT systems, the safety threshold is typically around one-third of nodes — 33%. Orcaella's 2-RTT path pushes past 50%.

## The catch: synchronous recovery

The protocol's core liveness — the guarantee that transactions eventually commit — holds only when at most *f* equivocators are active \[S1\]. If that threshold is breached, for instance by AbC-induced forks where corrupt nodes create conflicting transaction histories, the protocol drops into what the authors call "synchronous recovery" \[S1\].

In that mode, only the resilient-path safety guarantee survives. Liveness depends on eventual synchrony — the assumption that message delays eventually become bounded. This is a standard fallback in distributed systems theory, but it means the protocol's strongest properties are conditional, not unconditional.

## What it means

Orcaella's core idea — letting the client, not the protocol designer, choose the latency-resilience tradeoff — is a genuine shift in how to think about consensus finality. Today, most blockchain L1 networks offer a single finality time. Public benchmarking efforts like OpenChainBench measure that finality as a fixed property of each chain \[P3\]. Orcaella proposes making it a spectrum.

For the reader with no distributed systems background: imagine a bank where you choose, per transaction, between a 2-second confirmation that is very hard to reverse unless 16% of the bank's branches are corrupt, or a 4-second confirmation that is nearly impossible to reverse even if 54% of branches are lying. The faster option is enough for most payments. The slower one is for settlement-grade finality.

The mixed fault model matters too. Real-world networks do not just have honest nodes and crashed nodes — they have nodes that are running but misbehaving, whether due to bugs, compromise, or adversarial control. By formally separating crash faults (*f*), alive-but-corrupt faults (*c*), and equivocators, Orcaella gives a more precise vocabulary than the binary "Byzantine or not" model that dominates most consensus literature.

## What it means for business

For a two-person fintech startup building on a permissioned chain, the practical implication is cost. If you need 99 replicas for the configuration above, that is infrastructure you either run yourself or pay a cloud provider to host. Orcaella's client-selectable latency means you do not always pay the full latency tax — routine transactions can use the 1-RTT path, while high-value settlement can wait for 2-RTT.

For a suburban conveyancing firm or a cafe accepting digital-asset payments, the distinction is simpler: small everyday transactions get fast finality; large ones get the resilient path. The protocol design implies this choice could be made automatically based on transaction value.

For exchanges and trading venues — the audience hinted at by the paper's q-fin.GN (quantitative finance) arXiv classification — the appeal is obvious. Finality latency directly affects counterparty risk. A protocol that can tolerate 54% equivocation at 2-RTT could, in theory, allow settlement in environments where trust is low and node corruption is a real possibility.

But none of this is deployable today. The paper is a preprint, not peer-reviewed \[S1\]. No implementation, no benchmarks against live networks, no deployment data.

## What we don't know yet

- **Peer review status**: The paper is explicitly marked as a preprint and has not been peer-reviewed \[S1\]. The tight bound proof, the liveness claims, and the recovery mechanism all need independent verification.
- **No implementation**: The paper presents theoretical results. There is no reference implementation, no performance benchmark, no comparison with existing BFT protocols like HotStuff or Tendermint on real hardware.
- **Parameter specificity**: The 22%/16%/54% figures are specific to the *n* \= 99, *f* \= 16, *c* \= 6 example \[S1\]. Different configurations yield different thresholds. The general behaviour of the protocol across parameter ranges is not fully characterised in the available evidence.
- **Synchronous recovery cost**: The paper describes the fallback to synchronous recovery but the evidence does not specify how long recovery takes or what throughput looks like during that period.
- **Real-world fault distribution**: The mixed fault model assumes specific ratios of crash faults to AbC faults to equivocators. Whether real networks exhibit these proportions — and whether AbC faults are common in practice — is an empirical question the paper does not address.

The next concrete event to watch: whether this preprint surfaces at a peer-reviewed venue such as OSDI, SOSP, or a crypto-economics conference, and whether an implementation appears on GitHub. Until then, Orcaella is an elegant idea with a striking number — and a proof nobody has yet checked.

If this kind of deep decode is what you want in your inbox, subscribe to keep reading.

---

**Sources**

- \[S1\] Orcaella: Hybrid Fault Tolerance with Client-Selectable Finality Latency, arXiv preprint (cs.CR, q-fin.GN), 7 July 2026 — [https://arxiv.org/abs/2607.04789v1](https://arxiv.org/abs/2607.04789v1?ref=notatechguy.com)
- \[P3\] OpenChainBench L1-finality benchmark harness, GitHub — [https://github.com/ChainBench/OpenChainBench/tree/main/harnesses/l1-finality](https://github.com/ChainBench/OpenChainBench/tree/main/harnesses/l1-finality?ref=notatechguy.com)

## Sources

- **\[S1\]** [Orcaella: Hybrid Fault Tolerance with Client-Selectable Finality Latency](https://arxiv.org/abs/2607.04789v1?ref=notatechguy.com) — arXiv preprint (cs.CR, q-fin.GN) (attributed)
- **\[P2\]** [Fault-Tolerant Hybrid-Parallel Training at Scale with Reliable and Efficient In-memory Checkpointing](https://arxiv.org/html/2310.12670v3?ref=notatechguy.com) — Fault-Tolerant Hybrid-Parallel Training at Scale with Reliable and Efficient In-memory Checkpointing (attributed)
- **\[P3\]** [OpenChainBench/harnesses/l1-finality at main · ChainBench/OpenChainBench · GitHub](https://github.com/ChainBench/OpenChainBench/tree/main/harnesses/l1-finality?ref=notatechguy.com) — OpenChainBench/harnesses/l1-finality at main · ChainBench/OpenChainBench · GitHub (attributed)
- **\[P4\]** [docs/LIVE\_PROTOCOL.md](https://github.com/FinalisCore/finalis-core/blob/main/docs/LIVE%5FPROTOCOL.md?ref=notatechguy.com) — docs/LIVE\_PROTOCOL.md (attributed)
- **\[P5\]** [LinasNas/core-reasoning](https://github.com/LinasNas/core-reasoning?ref=notatechguy.com) — LinasNas/core-reasoning (attributed)

## More from Not A Tech Guy

- [CamVLA: robots work after cameras move, no recalibration](https://www.notatechguy.com/camvla-robots-work-after-cameras-move-no-recalibration/)
- [Agentic Data Environments: turning data into agent guardrails](https://www.notatechguy.com/agentic-data-environments-turning-data-into-agent-guardrails/)
- [LLM personality traits mapped and controlled in weight space](https://www.notatechguy.com/llm-personality-traits-mapped-and-controlled-in-weight-space/)

---

*Generated from an audited evidence pack with primary-source research. Social-media items are discussion signals, not verified facts. Nothing here is financial, legal or medical advice.*