Sei Giga is being built to become the ultimate high-performance trading blockchain. Hermes is the consensus end goal for that vision, combining the speed of the fastest leader-based protocols with a fallback that ensures fast finality even when a leader is slow or offline.

Today’s fastest consensus protocols can finalize in as fast as two message delays. But a slow or crashed leader can still leave transactions waiting through a timeout and a fresh round of consensus. Make the timeout shorter and healthy leaders may get skipped too. That trade-off has been the focus of a considerable amount of consensus research.

Hermes keeps the same optimal fast path and changes what the network does when a leader misses the deadline. Validators can vote for different proposals and still finalize the history they share. Agreement already present in their votes becomes useful progress, even when no single proposal wins enough votes. The end result is a consensus protocol that is exceptionally fast in both good cases and bad cases.

Figure 1. Faster through leader failures, with no measurable good-case latency penalty at 51 validators. Hermes and Minimmit have overlapping latency distributions without faults, including at n = 51.

Hermes is a partially synchronous fast-path consensus protocol, built to bound tail latency. Like Minimmit or Alpenglow, Hermes runs in views, each with a leader, and requires at least 80% of votes to terminate a view. Unlike Minimmit, Hermes does not require at least 80% matching votes (a quorum) to finalize a value, and instead allows finalization of a common prefix among a quorum of votes (if any). The payoff is clear in the latest results. In the good case, testing 51 validators across 4 European regions, and a load of 100,000 txn/s, the median latency is just 68ms, with p95 at 101ms.

The beauty of Hermes is how it barely degrades under attacks, validator crashes, or network disruptions. With three consecutive slow leaders, Hermes’ 95th-percentile (p95) latency settles at 206 ms, versus 365–664 ms for the other protocols tested. That is 44–69% lower tail latency. At 51 validators without faults, Hermes matches Minimmit (built with Autobahn's lanes) across the latency distribution in the good case where leaders are fast enough, but halves its latency under unfavorable conditions. By building Hermes on top of Autobahn, Sei Giga can aim for more dependable finality while preserving the speed of the fast path.

The strongest performance when leaders fail

We stopped three consecutive leaders in the same region for five seconds, at a configured load of 100,000 transactions/s. This puts a rotating-leader protocol under direct pressure: the network cannot simply rely on the next leader being healthy. Hermes delivered the lowest median and p95 plateau of every protocol in the comparison.

Plateau latency during the three-leader stall. Hermes and Minimmit use 16 validators; Autobahn and Ambulance use 10. Each committee tolerates three faults. p95 is the 95th percentile, not a maximum.

Hermes cuts p95 latency by 44% against Minimmit, 47% against Autobahn, and 69% against Ambulance. Its p95 rises just 2.2× from the no-fault baseline, compared with 3.5–5.8× for the alternatives. The traces show a lower, steadier plateau while the leaders are offline.

That difference matters for applications built around a quick response. A delayed order cancellation or a payment stuck waiting for finality is still a poor experience, however fast the chain looks on average. Reducing those waits is central to the experience Sei Giga is being built to deliver.

Most importantly, this allows Hermes to deploy under very aggressive timeouts without suffering as much the impact of the aggressive timeout causing a few leaders to skip. That is, the improvement in tail latency might cause a direct impact in common case latency.

The same fast path and throughput as the state of the art

Hermes’ fallback brings no measurable latency penalty in the larger good-case test. With 51 validators across 4 European regions at 100,000 transactions/s, its latency distribution overlaps Minimmit’s from the 1st to the 99th percentile. The latency is shown in Figure 1.

This is the combination that makes Hermes compelling for Sei Giga: the normal-case speed of a leading fast-finality protocol, with a much stronger response when leaders stop doing their job.

How Hermes achieves the lowest, most stable latency

A good mental model for psync Hermes is to take Minimmit and perform four modifications:

1. all processes propose, not only the leader;

2. fallback votes replace nullification;

3. finalization commits the common prefix of a quorum (>80%)

4. Notarization extends the longest extension to the common prefix of a weak quorum (>40%)

As a result, it is a protocol that benefits from the simplicity and low good-case latency of Minimmit, but reduces its tail latency, because a nullified view may now finalize the common prefix of any subset of at least 80% of votes.

The common prefix among different proposals is likely to exist in certain scenarios, for example when processes propose the tip of an available chain in an ebb-and-flow protocol (much like Ethereum's Gasper) or tipcuts shared via an Autobahn or Narwhal layer that precedes consensus. We however focus on the case we built Hermes for: Sei Giga. As a result, we present Hermes as the consensus layer of Sei Giga, preceded by Autobahn DA, in which multiple proposers maintain hashchains (lanes), and a deterministic interleaving derives the sequential ordering once a list of tips from each lane (a tipcut) is decided via Hermes.

Hermes starts each consensus view with proposals (tipcuts) from the validator set. The designated leader remains the preferred choice, so a healthy network takes the familiar fast path. If that leader misses the deadline, a validator can vote for an available backup proposal, or its own proposal when no backup is available.

The key is what Hermes does with those votes. Different proposals often describe the same history up to a certain point. Hermes can finalize that shared prefix even when the votes disagree about what comes next.

Figure 2. Nine votes support different tips, but all nine include A. Hermes finalizes A and carries a safe continuation into the next view. A slow leader has not erased the agreement already present in the network.

This is how Hermes keeps useful work from being lost to an empty view. When the shared prefix contains new transactions, those transactions can become final in that same view. When it only reaches the existing finalized history, the certificate still advances consensus without a separate round to discard the view.

Preliminaries

The following definitions make the four modifications precise. We consider n = 5f + 1 processes, of which at most f may be Byzantine: they can deviate arbitrarily from the protocol. The remaining processes are honest and cast at most one vote per view.

The network is partially synchronous. After an unknown Global Stabilization Time (GST), messages between honest processes arrive within a known bound Δ. Before that point, delays can be arbitrarily long. Channels are authenticated and pairwise. We use δ for the actual message delay in a timely execution.

A value represents an ordered history. We write X ⪯ Y when X is a prefix of Y, and call two values comparable when one is a prefix of the other. A vote for [A, B, C] also supports [], [A], and [A, B]. All prefixes of a single value lie on one chain, so two conflicting histories cannot both be prefixes of the same value.

For Sei Giga, proposals describe histories built from the available Autobahn lanes. The comparison is between the ordered histories those proposals derive. Parent references, deterministic interleaving, and explicit skips keep that ordering unambiguous; comparing lane-tip heights alone is insufficient.

Hermes uses two notarizations, each containing votes from distinct senders in one view:

1. An M-notarization contains exactly 2f + 1 votes whose endorsed values are pairwise comparable. It allows the next view to build on their highest tip and can advance the view before finalization.

2. An L-notarization contains exactly 4f + 1 votes. Their values may differ. It finalizes their heaviest common prefix and supplies the continuation on which the next view builds.

These thresholds exceed 40% and 80% of the full committee, respectively. The exact counts are what the protocol uses. If more votes have arrived, each chosen set of 4f + 1 votes is a separate L-notarization; the larger collection is not used as one certificate.

For an L-notarization S, the heaviest common prefix HCP(S) is the longest prefix supported by all 4f + 1 votes. The selected continuation SC(S) is the longest prefix supported by at least 2f + 1 votes inside that certificate. Those 2f + 1 votes are a threshold measured against the full committee, not 40% of the certificate.

Votes carry identifiers. A vote contributes support only after its value, justification, and validation dependencies have been resolved and checked. Unresolved messages remain buffered. This matters because Hermes must know the histories endorsed by different votes before it can compare their prefixes.

Why finalizing the common prefix is safe

In the good case, the leader’s proposal reaches the honest processes in time and collects 4f + 1 matching votes. Their common prefix is the entire proposal, so Hermes finalizes it in one voting round, just as Minimmit does.

If the leader reaches only some processes before timeout, the remaining processes may vote for different fallbacks. No exact proposal needs to receive a full quorum for their shared prefix to receive one. Safety requires that two such finalized prefixes can never fork, either within one view or across views.

Safety within a view

Let P and Q be two L-notarizations from the same view. Their sender sets intersect in at least:

2(4f + 1) − (5f + 1) = 3f + 1

At most f of those senders are Byzantine, leaving at least 2f + 1 honest senders in the intersection. Each honest sender casts only one vote in the view, so both certificates contain that sender’s identical endorsed value. The prefixes finalized by P and Q are both prefixes of this value. They are therefore comparable: one can extend the other, but they cannot fork.

Safety across views

A proposal in view v + 1 must extend the parent selected by a valid view-v notarization. That parent must preserve every prefix that could have been finalized in v, including a prefix already finalized by another honest process but not yet observed locally.

For an L-notarization S, the parent is SC(S). Its selection is unambiguous. If two candidate prefixes each have support from 2f + 1 votes inside S, their support sets overlap because:

2(2f + 1) = 4f + 2 > 4f + 1

A vote in that overlap endorses a value extending both candidates, which makes them comparable. There is therefore a unique longest supported continuation, with no tie-breaking between conflicting branches. For an M-notarization, the parent is the highest endorsed value in its comparable chain of votes, rather than their common prefix.

Now let b be finalizable from an L-notarization Q. Every other L-notarization P from that view shares at least 2f + 1 honest votes with Q. Those votes still support b inside P, so SC(P) must extend b. An M-notarization M intersects Q in at least:

(2f + 1) + (4f + 1) − (5f + 1) = f + 1

At least one sender in that intersection is honest. Its endorsed value extends b, and the highest value in M extends that value. Thus both types of notarization select a parent that preserves b.

The same rule applies when a process has not voted yet and receives a notarization from that view: it votes for the selected parent. Such an induced vote depends on a certificate validated from earlier counted votes. Applying these rules from one view to the next preserves every finalizable prefix, so honest processes cannot finalize conflicting histories later.

Description of the protocol

Minimmit finalizes quickly with a timely honest leader. A failed leader instead costs a 2Δ timeout, an empty view, and a retry under the next leader. Consecutive bad leaders accumulate those costs. A longer timer avoids some unnecessary skips but makes actual failures more expensive; a shorter timer reacts quickly but can discard views that were close to succeeding.

Hermes changes what a timeout can accomplish. The fallback votes can finalize work they already share and justify the next view using the same certificate. New work is committed when their common prefix extends the finalized head. Even when it does not, the certificate advances the view without an additional nullification round.

Modifications to Minimmit

Modification 1: All processes propose

Every process broadcasts a justified proposal at the start of a view. A deterministic round-robin leader remains the preferred proposer: with process indices starting at zero, its index is v mod n. The healthy case finalizes the leader’s proposal, while the other proposals are already available for fallback if that leader is slow or silent.

The proposer role can be assigned to a separate or restricted set, but the construction here lets every process propose. This makes the proposal stage all-to-all. The additional proposals give the fallback useful alternatives whose common history can still be finalized.

Modification 2: Fallback votes replace nullification

An honest process casts at most one vote per view. It votes for the valid leader proposal when it becomes available. If it has not voted when its 2Δ timer expires, it selects a valid available fallback:

1. Use the predetermined backup leader’s proposal if it is available. With multiple ranked backups, use the highest-ranked available proposal.

2. Otherwise, vote for its own proposal, which was prepared at the start of the view.

A process that first learns enough through an M- or L-notarization instead casts an induced vote for that certificate’s selected parent if it has not voted already. Every vote therefore endorses a justified value; there is no separate nullification vote. The amount of new work finalized depends on how much of the voted histories overlaps.

Modification 3: Commit the common prefix

With all-to-all proposals and fallback voting, a process can collect 4f + 1 votes without any single proposal receiving 4f + 1 matching votes. Hermes finalizes the longest prefix shared by the values in that chosen quorum. Disagreement near the tips leaves their common history usable.

Return to the example with f = 2 and n = 11. An L-notarization needs nine votes and an M-notarization needs five. Suppose two processes are unavailable, including the leader, and the nine fallback votes above the finalized head are:

1. Three votes for [A, B, C].

2. Three votes for [A, B].

3. Three votes for [A].

No exact tip has nine votes, but all nine extend [A]. Hermes can therefore finalize [A] in the failed leader’s view. This is the shared-work benefit illustrated earlier; the same vote set also determines where a proposal justified by this certificate may build next.

Figure 3. The same nine votes determine two different boundaries. A is final because all nine votes support it. B is the selected continuation because six votes support it, clearing the five-vote threshold. C has only three votes.

Modification 4: Carry a safe continuation into the next view

For the L-notarization in Figure 3, [A, B] has six supporting votes and [A, B, C] has three. The selected continuation is therefore [A, B], even though this certificate only finalizes [A]. Every proposal justified by this certificate must extend [A, B]. An M-notarization instead selects the highest tip among its 2f + 1 comparable votes.

The continuation protects against a certificate another honest process could have seen. A process receiving nine votes cannot infer that the two missing senders really crashed, or identify which of the senders it heard from are Byzantine. In another execution consistent with those received votes, two of the three A-only senders could equivocate and endorse [A, B] elsewhere, while one previously unseen sender also endorses [A, B]. Together with the six observed votes already extending B, that gives nine distinct senders supporting [A, B].

This is an alternative possible execution, not two extra Byzantine faults added to the two crashes in the example. The continuation rule handles that uncertainty through quorum intersection. In the actual execution where both missing processes have crashed, they already consume the entire fault budget.

The same arithmetic prevents a fork when honest votes split across incompatible tips. In Figure 4, four honest processes vote for B and five for B′ above A. Even if both Byzantine processes support either branch, neither tip reaches the nine-vote finalization threshold. All nine honest votes still support A.

Figure 4. Honest votes may disagree above A without allowing conflicting finality. B can have at most six supporters and B′ at most seven in this example. Each is below the required nine, while the common prefix A has nine honest supporters.

Informal pseudocode

Let L_v be the leader and L′_v the backup for view v. A process forwards the first validated notarization of each type that it learns for a view. Genesis supplies the initial justification. All other proposals must extend the parent selected by a justification from the immediately preceding view.

1. Propose. Select a valid view-(v − 1) justification, derive its parent, and broadcast a proposal extending that parent. If no new available history can extend the parent, re-propose the parent. Start the view timer.

2. Vote. Prefer the valid leader proposal. If no vote has been cast when 2Δ expires, vote for the highest-ranked available backup, or the local proposal if no backup is available. Count the vote only once its value and dependencies resolve.

3. Process an M-notarization. Select the highest tip among its comparable votes. If not yet voted in that certificate’s view, vote for this tip. Use the certificate to advance to the following view if it is not older than the local view.

4. Process an L-notarization. Finalize its HCP if it extends the finalized head. If not yet voted in the certificate’s view, vote for its SC. Use the certificate to advance to the following view if it is not older than the local view.

A later-view certificate allows a lagging process to catch up. It first resolves and validates the justification chain in increasing view order, applying each intermediate certificate’s induced vote if needed, then advances to the view after the latest certificate. The vote in each skipped view is justified by that view’s own certificate; the process does not invent intermediate votes by copying an arbitrary later value backward.

Liveness intuition

Assume proposals, vote records, and their validation dependencies eventually become available, and checkpoint pauses eventually finish. An honest process that stays in a view eventually has a valid fallback and an expired timer. A process that moves past the view has processed a notarization and votes if it has not already done so. Eventually the 4f + 1 honest votes can be counted, providing an L-notarization for any processes still waiting. This gives progress through views without needing every leader to succeed.

After the network stabilizes, a synchronized good-case view with a timely honest leader finalizes its proposal in two actual message delays: proposal dissemination followed by voting. For fallback, if the proposals and evidence needed by honest voters are available by timeout, the common-prefix certificate is available within 2Δ + δ of view synchronization. That prefix can equal the existing head; the bound does not promise fresh finalized transactions in every failed-leader view.

Eventual transaction inclusion also depends on the data layer and proposal policy. They must keep making each pending transaction available to sufficiently late honest leaders. Under those conditions, an eventual timely honest-leader view includes and finalizes it. Before stabilization, safety remains intact, but there is no fixed latency bound.

Formal pseudocode

The following is the same protocol written as event handlers. Parent(J) is the highest endorsed value for an M-notarization and SC(J) for an L-notarization. BuildChild(P) returns an available valid extension of P, or P itself. Genesis is the justification for view 1.

Handlers run after their dependencies have been resolved and validated. A vote can endorse a valid proposal, or the parent of a same-view notarization validated from earlier counted votes. Process justification chains from earlier to later views before jumping. If leader and timeout conditions become ready together, handle the leader first. The voted flag is maintained per view and is never reset to permit a second vote in that view.

Respond sooner when a leader falls behind

Because fallback votes can preserve progress, Hermes can use shorter timeouts more effectively. In a sweep from 10 to 200 ms with one validator stalled, Hermes remained live throughout. The most aggressive setting produced the lowest median plateau in the entire sweep. The tested Minimmit implementation lost liveness at 10 ms; Autobahn stayed live but paid for unnecessary view changes when its timer was too short.

We also disabled designated backups, forcing validators to fall back to their own proposals. Hermes kept progressing, with 87–114 ms median plateau latency across the three tested failure locations. Its ability to combine differing votes still works when there is no backup proposal to rally around.

The next step for Sei Giga

Sei Giga will bring parallel transaction dissemination and fast execution together. Hermes is the intended evolution of its consensus layer: turn work the network has already shared into final decisions quickly, even when a leader is late.

The fit with Giga’s Autobahn-based architecture is direct. Validators distribute transaction data concurrently across their lanes. Hermes can order that available work and extract a common history from independently proposed cuts. The network gains another way to make progress when those proposals differ.

For developers, the ambition is simple: build applications that respond quickly enough for the way people trade, pay, and interact online. For users, it means a more predictable wait for a transaction to become irreversible. Hermes tackles the consensus delays that otherwise show up when the network is under stress.

The latest results put that ambition on firmer ground. Hermes matches the fastest good-case performance in these comparisons and delivers the lowest, most stable latency in the leader-stall tests. That is why Hermes will be built on top of Autobahn  as the ultimate consensus protocol for Sei Giga: fast finality that holds up when the network gets difficult.

Benchmark context

These are consensus benchmarks across four European AWS regions using 512-byte no-op transactions. The protocols share the data layer and test harness; latency runs from client submission to commitment acknowledgement. Clients attached to stopped validators pause submissions and resume on recovery, so plateau figures describe continuing traffic under that policy. The plots retain transition spikes. The 51-validator comparison is a separate test without faults.

Hermes uses n = 5f + 1 validators and tolerates up to f faulty or malicious validators. Safety holds under that fault model; eventual progress assumes the network becomes timely and the required data becomes available. The design preserves two-message-delay good-case finality, with fallback progress determined by the prefix the quorum shares.

References

Hermes: Low Tail-Latency Via Prefix Consensus

Sei Research Initiative. Sei Giga Achieving 5 Gigagas with Autobahn Consensus