Arc’s Deterministic Finality: the Bespoke Consensus Layer Built Using Malachite

Malachite is a flexible, reliable, high-performance Byzantine fault-tolerant (BFT) consensus engine implemented in Rust. It’s designed first and foremost as a core consensus library that makes no assumptions about the applications built on top, which is why it travels well across very different systems. In practice, that means a lean, stateless core with clean, message-driven interfaces and a modular architecture teams can compose as needed.

Bundled with Malachite is a state-of-the-art implementation of Tendermint, an optimistically responsive consensus algorithm for driving a network of peers to agreement without a trusted intermediary. Tendermint’s determinism underpins one of the biggest innovations Arc brings to the table: deterministic settlement finality.

Arc¹ adopts Malachite as its consensus foundation to deliver deterministic sub-second settlement finality with enterprise-grade reliability — the outcome that matters most to builders of stablecoin payments, FX, and capital markets flows. A key ingredient in achieving sub-second settlement finality is the choice of validator teams. Arc’s validators are selected from vetted established institutions that demonstrate exceptional standards of security, compliance, and operational resilience.

Malachite’s performance experiments illustrate how this design scales: average finalization latency around 780ms at 100 validators with 1 MB blocks, and ~330–490ms in smaller, geo-distributed networks with throughput that can reach 13.5 MB/s (~50k TPS) depending on setup.

Key Arc design choices

Arc’s bespoke consensus layer centers on four choices: decoupling consensus from execution (i.e., two-binary architecture), running consensus on compact references while moving bulk transaction data off the critical path, replacing a general gossip layer with a targeted liveness sub-protocol, and a minor customization for refining block timestamp validation to adapt the system to very fast block production. Together, these keep consensus rounds predictable and reinforce deterministic finality.

Two-binary system architecture

Arc decomposes consensus and execution into separate processes, meeting in a stable Engine API boundary. This reduces fate-sharing and simplifies upgrades by making it possible to scale the underlying hardware for each process independently. It also lets teams provision each process for what actually limits it in practice — consensus is network-bound, while execution is typically storage I/O-bound — so each can be tuned on its own terms.

This decoupling gives Arc stable foundations: security isolation between layers, predictable operations under load, and an upgrade path that doesn’t tangle consensus and execution concerns. It also strengthens finality guarantees: even if an execution client stalls or is upgraded independently, the consensus process can still reach commits and preserve deterministic finality.

Efficient block propagation

In BFT systems, transaction propagation consumes significant bandwidth, so the path matters. Arc’s consensus layer is network-bound, which makes propagation strategy central to predictable finality.

Arc leverages Malachite’s flexibility to run consensus on references to proposed blocks rather than on full block payloads — separating the proposal and the transactions within that proposal. For progress, a validator needs both, but as long as it has the proposal hash and the corresponding transaction data by the decision deadline, the finality schedule remains bounded and deterministic.

This separation lets each component travel the path that fits it best (e.g., with or without streaming, chunking, selective retransmission, and so on). In consensus terms, we separate value propagation (throughput-sensitive) from value decision (latency-sensitive). The decision path carries compact identifiers, while bulky transaction data moves on a purpose-built dissemination path. The result is lower bandwidth pressure where it matters and more predictable consensus round timing for finality — improving efficiency and raising confidence in SLAs without complicating core Tendermint logic.

As a final remark, the Arc team will continue iterating on efficient block propagation, which is always a factor when it comes to performance. Arc’s current design approach allows us to continue exploring alternatives that are potentially even more efficient, for example, those that use erasure codes to reduce redundancy while maintaining reliability.

Targeted liveness sub-protocol

In most Tendermint deployments today, a general-purpose network (i.e., gossip) layer is used to provide reliable message delivery specifically for consensus messages — powerful, but high in message complexity. In Malachite’s Tendermint, reliable delivery is handled by a dedicated liveness sub-protocol, applied precisely where it’s needed for ensuring liveness. In other words, we’ve moved a reliability feature (retransmission) from the networking (i.e., gossip) layer into a well-defined sub-protocol at the consensus layer.

By moving selective retransmission into an explicit liveness sub-protocol, the system is easier to analyze, benchmark, and optimize to reduce message complexity. With fewer moving parts on the critical path, consensus rounds become more predictable and the likelihood of escalations drops — strengthening deterministic finality under real-world conditions.

Refining block timestamp validation

EVM clients typically require strictly increasing, second-granularity block timestamps — sensible at ~12s block times on Ethereum, but problematic under Arc’s sub-second production. To avoid clock-granularity stalls, we adjusted the header timestamp validation in reth to permit consecutive blocks that share the same second-level timestamp. This is an execution layer customization.

Earlier MVPs of EVM networks built using Malachite worked around this with manual timestamp bumps, and we also considered switching to millisecond granularity. In the end, we determined that the targeted validation change is simpler and safer. This implementation leaves consensus untouched while aligning execution-side checks with real network timing.

Practically, this removes a non-consensus bottleneck that could otherwise halt commits during bursts of sub-second blocks. Honest validators can finalize on schedule without stalling or forking over timestamp quirks, keeping deterministic finality on track even when consensus rounds complete faster than seconds tick.

Deterministic finality by design

Arc’s bespoke consensus layer based on Malachite delivers deterministic finality by design: once a block gathers 2/3 commitments, it’s final. The two-binary architecture isolates consensus from execution, preserving finality under load and during upgrades. By running consensus on compact references while pushing bulk transaction data onto a separate propagation path, Arc keeps the decision loop lean and commit times predictable even as blocks grow. And by replacing a general gossip layer with a targeted liveness sub-protocol, it offers reliable delivery precisely where and when it’s needed, reducing message complexity and stabilizing round timing.

Taken together, these choices turn Tendermint’s commit rule into a practical, network-scale property: less fate-sharing, more efficient bandwidth use, simpler reasoning and testing, and smooth sub-second operation. That combination is why Arc can offer the finality characteristics that real-world settlement and high-throughput applications actually need.

‍

‍

¹ Arc testnet is offered by Circle Technology Services, LLC (“CTS”). CTS is a software provider and does not provide regulated financial or advisory services. You are solely responsible for services you provide to users, including obtaining any necessary licenses or approvals and otherwise complying with applicable laws.

Arc has not been reviewed or approved by the New York State Department of Financial Services.

The product features described in these materials are for informational purposes only. All product features may be modified, delayed, or cancelled without prior notice, at any time and at the sole discretion of Circle Technology Services, LLC. Nothing herein constitutes a commitment, warranty, guarantee or investment advice.

© 2025 Circle Internet Group, Inc.