Catchain 2.0: Simplex Consensus in TON
Whitepaper by the TON Core team
Authors: TON Core team
Date: March 10, 2026
: Original whitepaper site
Simplex is a leader-based consensus protocol. Validators take turns proposing blocks and then collectively vote on them. The protocol produces a single, ever-growing chain of finalized blocks that every honest validator agrees on.
Simplex proceeds in slots, each representing a designated opportunity to propose a block. For every slot, a validator is selected as the leader responsible for proposing a candidate block. The leader broadcasts its candidate, every validator checks it, and if validation succeeds, casts a notarization vote. Once a validator sees notarization votes totaling of stake, it casts a finalization vote. A quorum of finalization votes irrevocably commits the block to the output ledger, and the protocol moves on to the next slot.
If the leader is offline or malicious, the slot eventually times out and validators cast skip votes instead. A quorum of skip votes lets the protocol move on without producing a block for that slot.
An honest validator never both finalizes and skips the same slot, and never notarizes two different candidates for the same slot. Because any two quorums overlap in at least one honest validator, these per-validator constraints lift to global guarantees: at most one candidate can be finalized per slot, and a finalized slot can never be skipped. This is the core of safety.
Multiple notarized but non-finalized chains may temporarily coexist if, because of network conditions or leader misbehavior, a sequence of slots is both skipped and has valid candidates. Such forks collapse as soon as the next finalization quorum is achieved, since any candidate in the later slot must necessarily be a descendant of a slot that was not skipped. Honest validators thus commit a candidate to the ledger once it has a finalized descendant.
The rest of this document rigorously develops the flavor of the protocol used in TON and is organized as follows:
-
Section 1 formally defines the ledger model and the voting rules that honest validators must follow to guarantee safety.
-
Section 2 proves safety: finalized chains are always consistent, regardless of network conditions or adversary behavior.
-
Section 3 refines the rules into a concrete protocol by adding candidate generation rules, formalizing timeouts, and describing mechanisms required for operation in a lossy network. We then prove that the resulting protocol achieves liveness: with probability , the output log grows without bound.
-
Section 4 covers practical considerations that do not affect safety or liveness but improve throughput, and maps concepts from this document to their counterparts in the C++ implementation.
Model and Definitions
1.1 System Model
We consider a system of validators , each with a positive integer weight . Let . At most total weight of validators may be Byzantine. Define the quorum threshold .
Each honest validator holds an EUF-CMA-resistant signing key pair; each validator's public key is known to all. No assumption is made about Byzantine validators' keys beyond possession of a public key.
1.2 Ledger Validity
Let denote the set of all possible block payloads. We assume an external predicate , which determines whether a sequence of payloads represents a valid ledger state. The predicate satisfies the following properties:
- Genesis validity. .
- Extendability. For every valid sequence , there exists some such that holds.
A sequence is called valid if .
Consensus does not depend on the internal structure of payloads beyond these properties.
1.3 Protocol Objects
Slots. Slot number is a discrete index . Slots are grouped into leader windows of size . Window covers slots with an associated leader .
Candidates. A candidate is a tuple where
- is the slot number,
- is the block payload,
- is a parent reference: either or a pair with ,
- is a valid signature by the leader of the window containing over .
For a candidate , define . The pair uniquely identifies the candidate.
Chains. A chain ending at is a sequence of candidates where each candidate's parent reference points to the previous candidate in the sequence. Formally, it is a sequence of candidates , identified by , such that:
- the first candidate has the genesis parent: , and
- each subsequent candidate references the previous one: for .
The slot set of a chain is .
The associated sequence is called the chain state.
A candidate is called valid if there exists a chain ending at with a state that is valid.
Votes. At any point, a validator may cast a vote signed by its signing key certifying some statement . Votes can be sent over the network.
Certificates. A certificate for a statement is a set of votes for from distinct validators with total weight .
We say that is reached in the network if a certificate for can be produced by an oracle that knows all cast votes. We say that is observed on validator when validator receives enough votes to construct a certificate for (possibly by receiving an already constructed certificate). Note that a statement can be reached without any single validator knowing it.
1.4 Statements
We implicitly set the statements , to be reached.
A particular validator may cast votes certifying the following statements:
-
. Validator has not cast a vote for for , and there exists a candidate identified by such that:
- is reached,
- for each slot , the statement is reached,
- the candidate is valid.
-
. Validator has not cast a vote for any statement .
-
. is reached, and validator has not cast a vote for .
Honest validators cast votes only when they can verify that the corresponding conditions hold. They are not required to cast votes immediately when the conditions become provable.
Safety
Lemma 2.1 (Final–Skip exclusion). For any slot and hash , the statements and cannot both be reached.
Proof. Suppose both are reached. Each certificate has total signing weight . Since , the honest overlap is positive: some honest validator voted for both and . But Section 1.4 requires that a voter has not voted , and a voter has not voted . Contradiction.
Lemma 2.2 (Unique notarization). For any slot , at most one can have reached.
Proof. If and are both reached with , the same overlap argument yields an honest validator that voted for both, contradicting the local uniqueness constraint on .
Lemma 2.3 (Finalization implies notarization). If is reached, then is reached.
Proof. The certificate for has honest signing weight (since ). Each honest signer verified that is reached before voting.
Lemma 2.4 (Unique finalization). For any slot , at most one can have reached.
Proof. Suppose and are both reached with . By Lemma 2.3, and are reached. This contradicts Lemma 2.2.
Lemma 2.5 (Chain notarization). If is reached, then for every in the chain ending at , the statement is reached.
Proof. By induction on chain length. For the head, is reached by assumption. For the parent , the conditions require to be reached. Apply the inductive hypothesis to .
Theorem 2.6 (Safety). If and are both reached with , then the chain ending at is a prefix of the chain ending at .
Proof. If , then by Lemma 2.4, .
Otherwise, let be the chain ending at with slot set . Suppose . Since , the chain must skip slot : there exists a candidate identified by in with . By Lemma 2.3, is reached; by Lemma 2.5, so is . The notarization conditions for require to be reached. But is also reached, contradicting Lemma 2.1.
Let be the candidate identifier with the largest slot such that has observed , or if no finalization has been observed. The output log of is the chain state of the chain ending at .
Corollary 2.7 (Consistency). Any two honest validators' output logs are such that one is a prefix of the other.
Proof. Let and be the latest finalized identifiers observed by validators and respectively. WLOG, . Both statements are reached (since they were observed). By Theorem 2.6, the chain ending at is a prefix of the chain ending at , so the output log of is a prefix of the output log of .
The permission for and to coexist means non-finalized histories may fork (a slot that is both skipped and notarized can be included or excluded by later candidates), but Theorem 2.6 guarantees that finalization collapses any such forks into a single consistent chain.
Liveness
Safety holds unconditionally but says nothing about progress. The voting rules in Section 1.4 are compatible with validators never casting a single vote. To prove liveness, we need to specify when honest validators actually vote, how leaders produce candidates, and how the network delivers messages between validators. This section provides those operational rules (Section 3.1), introduces a probabilistic network model (Section 3.2), and then proves that, under these rules and this model, finalization happens infinitely often with probability .
3.1 Honest Validator Rules
Fix parameters (skip-timeout scale), (standstill period), and (skip-timeout growth rate).
An honest validator maintains per-slot voting state (which , , and votes it has cast) and a local frontier (Rule 1). In all cases, "broadcast" means sending the message to every other validator.
Rule 1 (Frontier tracking). A slot is cleared for if has observed , , or for some . The frontier is the smallest slot that is not cleared for . Initially .
When crosses a window boundary , window becomes active for .
The next two rules describe how validators obtain and produce candidates.
Rule 2 (Candidate resolution). Honest validators store candidates they have voted for. Validator can obtain a notarized candidate identified by by requesting it from a uniformly random peer and retrying after an exponentially increasing timeout. When receives such a request for a candidate it has stored, it replies.
Given a certificate proving that is reached, a node can resolve the state of the chain at (or simply, resolve the state at ) by following parent links and recursively requesting missing candidates from other nodes.
Rule 3 (Leader duty). When window becomes active and is its leader, chooses any base for which it can prove all of the following:
- ,
- is reached,
- is reached for every .
Validator then resolves the state at and produces a valid candidate .
The candidate is broadcast to all validators.
The following three rules govern how validators vote on candidates and handle leader failures.
Rule 4 (Notarize). Upon receiving a candidate identified by , validator starts state resolution for . It votes and broadcasts the vote as soon as it can prove all of the following:
- has not previously voted for any candidate at slot .
- is reached.
- For every slot with , is reached.
- Candidate is valid.
Rule 5 (Finalize). Validator votes and broadcasts the vote as soon as it can prove all of the following:
- has voted ,
- is reached,
- has not voted .
Rule 6 (Skip). For each window , after the window becomes active for , and for each slot in the window, there is a finite timeout after which votes (unless it has already voted ), and broadcasts the vote.
Let be the window containing the largest slot such that can prove is reached at the moment window becomes active. Then for every slot in window .
The final two rules handle certificate propagation and recovery from stalls.
Rule 7 (Certificate formation and rebroadcast). When has received votes for a statement with total weight at least , it forms the corresponding certificate. Upon forming or receiving any certificate, broadcasts it.
Rule 8 (Standstill resolution). When has not observed any new finalized blocks since time , the -th standstill-resolution attempt () occurs at time . Each standstill-resolution attempt is a broadcast that sends:
- the certificate for with largest slot that has observed (unless ),
- all certificates holds for slots ,
- all votes cast by for slots .
3.2 Network Model
We consider the following two-phase network model:
- Adversarial phase (). The adversary controls message delivery between all pairs of validators: it may delay, reorder, or drop messages arbitrarily.
- Good phase (). Each message sent by an honest validator to another honest validator is an independent trial: it is delivered within time with probability and lost otherwise. Here is the drop rate.
Unlike the standard GST model, which assumes perfect delivery after stabilization, we retain independent message loss after . This forces the liveness proof to account explicitly for the operational mechanisms (standstill and candidate resolution) that a real implementation needs anyway.
Assumption 9 (Vote and certificate delivery). Each vote or certificate sent from one honest validator to another after is an independent trial that arrives within with probability at least .
Assumption 10 (Candidate broadcast delivery). For any slot where the designated leader is honest and broadcasts a candidate after , independently of other slots, some adversarially chosen set of honest validators with total weight at least receives that candidate within with probability at least .
Assumption 11 (Candidate resolution success). Each candidate-resolution request sent to an honest validator after is an independent trial that returns the candidate within with probability at least .
3.3 Almost-sure Liveness
Let be the set of honest validators.
Let , and let be the largest slot such that is reached by time . Consider the event
Lemma 3.1 (Eventual dissemination of honest-held data). Condition on . Then, with probability , every vote cast by an honest validator for a slot , and every certificate for a slot that is observed by an honest validator, is eventually delivered to every other honest validator.
Proof. Under , no honest validator ever observes a new finalized block after time . By Rule 8, every honest validator therefore performs standstill broadcasts forever, once every time units. Each such broadcast contains all certificates the validator holds above its latest observed finalization, as well as all of its own votes above that finalization.
Fix and a specific object for a slot , where is either a vote cast by or a certificate observed by . By Rule 8, validator retransmits infinitely many times. By Assumption 9, each retransmission reaches within with probability at least . Hence
Since the set of honest sender-receiver pairs is finite, this holds simultaneously for all of them with probability .
Lemma 3.2 (Every slot is eventually cleared under an infinite standstill). Condition on . Then, with probability , every slot is eventually cleared for every honest validator. Consequently, for every as .
Proof. Proceed by induction on .
Assume that every slot is eventually cleared for every honest validator. Then, for every honest validator , the local frontier eventually reaches at least . Hence the window containing slot eventually becomes active for every honest validator.
Now consider slot . There are two cases.
-
Some honest validator eventually observes for some .
By Lemma 3.1, every honest validator eventually observes the same notarization certificate. Therefore slot is eventually cleared for every honest validator by Rule 1.
-
No honest validator ever observes any .
It can be shown that in this case no honest validator can ever prove that any is reached. (Broadly, if no honest validator observes a particular certificate, no honest validator can prove the existence of such.)
Therefore no honest validator ever votes , because Rule 5 requires proving that some is reached. Since the window containing is active and Rule 6 gives a finite skip timeout, every honest validator eventually votes .
The total honest weight is , so honest skip votes alone suffice to reach . Each honest validator includes its own skip vote in every subsequent standstill broadcast, so by Lemma 3.1 every honest validator eventually receives enough honest skip votes to observe . Thus slot is eventually cleared for every honest validator.
In both cases, slot is eventually cleared for every honest validator. This completes the induction.
Lemma 3.3 (Locally provable eligible bases in sufficiently late active windows). Condition on . Let be the window containing slot . Let , and let be a window that is active for . Then, at the moment window becomes active for , there exists at least one base for Rule 3 that can already prove is eligible. Moreover, any chain ending at such a base has length at most .
Proof. Fix such and .
If has observed some or with , let be the largest such slot. Otherwise set , using the implicit genesis base.
Since window is active for , every slot is cleared for . Also, because , no slot is ever finalized on . Therefore, for every slot with , clearing cannot come from any observed finalization at or above . By maximality of , it also cannot come from any observed notarization or finalization at a slot in . Hence each such slot must be cleared by an observed skip certificate. Thus can prove is reached for every .
If , the genesis base is eligible by the implicit . If , then the observed notarization or finalization certificate at slot , together with the skip certificates for all slots in , gives a proof that is an eligible base for Rule 3. This proves existence.
Finally, any chain ending at a base with slot contains strictly increasing slot numbers, so its length is at most .
Lemma 3.4 (Tail bound for state resolution). There exist constants and such that the following holds.
Let . Suppose an honest validator needs to resolve the state of a chain whose length is at most . Then for every ,
In particular, for a base in window one may take , so
for a suitable constant depending only on and the protocol parameters.
Proof. Consider one missing candidate on the chain. Because the chain is certified slot-by-slot, at least one honest validator stores that candidate: honest validators store all candidates they vote for, and every notarized or finalized slot has positive honest overlap.
A single resolution request chooses a uniformly random peer. The probability that the request is addressed to an honest holder is at least . Conditioned on that event, Assumption 11 implies a reply within with probability at least . Hence one request attempt succeeds within with probability at least .
By Rule 2, retries use exponentially increasing timeouts. Therefore there exist constants such that by time at least request attempts have been made whenever . Hence
Setting , the right-hand side is bounded by for a suitable constant .
Now let the chain length be at most . Resolve candidates sequentially from the base upward and allocate time to each candidate. Let be "some candidate on the chain is not resolved within its allotted time". By the bound above and a union bound,
This proves the claim with . The window- specialization follows from Lemma 3.3.
Lemma 3.5 (Uniform positive chance of finalization in late honest windows). There exist constants and such that the following holds.
Let be a window whose designated leader is honest, and let be the time when window becomes active for that leader. Condition on any execution history up to time in which no slot larger than has been finalized by time . Then the probability that slot is finalized before the skip timeout in that window is at least .
Proof. Fix such a window , and let be its honest leader. Let , the lower bound from Rule 6 for skip timeouts in window .
Let be the base chosen by under Rule 3. By Rule 3, at the moment of choice, leader already has a local proof that is eligible: one certificate proving is reached, together with certificates proving is reached for every . By Lemma 3.3, such a base exists in every active window .
We will show that, for all sufficiently large , there is a uniform positive probability that:
- resolves the chosen base and produces the candidate quickly,
- the candidate reaches a quorum-weight honest set ,
- the leader's proof of eligibility reaches every validator in via standstill broadcasts,
- every validator in resolves the base state quickly,
- notarization and finalization votes are exchanged quickly enough.
We treat these steps in order.
First, the leader must resolve the chosen base state and produce its candidate. Since any chain ending at a base with slot has length at most , Lemma 3.4 gives
for some constant .
Second, once the candidate is produced and broadcast, Assumption 10 implies that with probability at least some honest set with total weight at least receives the candidate within .
Third, the validators in must receive enough certificates to prove Rule 4(2) and 4(3) for the leader's chosen base. Let be the set of certificates needed for that proof: one certificate for the base, and one skip certificate for each slot between and . Thus .
As long as no new finalized block is observed, Rule 8 makes the leader rebroadcast all of these certificates every time units. Over any interval of length , there are at least
standstill attempts once is large enough. For any fixed certificate and any fixed validator , the probability that none of those transmissions from to arrives within is at most . Let be "some validator in is still missing some certificate in after time ". A union bound over all certificate-recipient pairs shows that
The right-hand side tends to exponentially fast in .
Fourth, each validator in must resolve the same base state before voting . Applying Lemma 3.4 and union bounding over at most validators,
for some constant .
Fifth, the resulting notarization and finalization votes must be exchanged quickly enough. Choose some collector . Let be the event that:
- every validator in delivers its notarization vote to within ;
- delivers the resulting notarization certificate to every validator in within ;
- every validator in delivers its finalization vote to within .
This involves at most point-to-point deliveries between honest validators. By Assumption 9,
Now define the success event as the conjunction of the following:
- the leader resolves the chosen base and produces the candidate within ;
- the candidate reaches an honest set of total weight at least within ;
- by time , every validator in has received all certificates in ;
- by time , every validator in has resolved the base state;
- occurs.
On , by time every validator in has all information needed to prove Rule 4(2)--(4). Moreover, because the leader is honest and produces only one candidate per slot, no other properly signed candidate for slot exists, so no validator in can have previously voted for a different candidate, satisfying Rule 4(1). Thus all validators in vote . The collector forms the notarization certificate and rebroadcasts it. Since all of these validators have not yet skipped slot , they then vote , and the collector receives finalization votes of total weight at least .
The total time used on is at most . Because grows exponentially in while and are constant, there exists such that for all , , and simultaneously
For such , the chain rule gives
Set .
Finally, on the finalization certificate for slot is formed before time , hence before any honest validator's skip timeout for that slot expires. Therefore slot is finalized before timeout. Thus every sufficiently late honest-leader window succeeds with conditional probability at least .
Theorem 3.6 (A later finalization occurs almost surely). Fix any finite execution prefix ending at time , and let be the largest slot finalized by time . Then, conditioned on that prefix, with probability some slot is eventually finalized.
Proof. Let be the event that no slot larger than is ever finalized.
By Lemma 3.2, on every honest validator's frontier tends to infinity. Therefore every sufficiently late window eventually becomes active for every honest validator. Since leader windows rotate cyclically and the honest stake is positive, infinitely many of those active windows have honest leaders.
Enumerate, on the event , the honest-leader windows with index at least from Lemma 3.5 as . For each , let be the event that the leader slot of window is finalized before its skip timeout.
Lemma 3.5 states that for every , , where is the full execution history up to the activation time of window , under the condition that no slot larger than has been finalized before that activation time. Hence, by the chain rule,
But on , all of the windows exist and all of the events fail. Therefore
Letting yields . Thus, conditioned on the execution prefix up to time , some later slot is finalized almost surely.
Theorem 3.7 (Infinitely many finalized blocks). With probability , infinitely many slots are finalized.
Proof. Define a sequence of random slots recursively by , and for each , let be the smallest slot strictly larger than that is finalized, if such a slot exists.
Theorem 3.6 applies after any finite execution prefix. In particular, on the event that exists, condition on the history up to the time when is finalized. Then, with probability , some later slot is finalized. Equivalently,
By induction on ,
Hence, with probability , the sequence is defined for all , which means that infinitely many slots are finalized.
Theorem 3.7 establishes almost-sure liveness. Under the operational rules of Section 3.1 and the probabilistic post- network model of Section 3.2, the protocol finalizes blocks infinitely often with probability . Combined with the safety theorem from Section 2, this implies that honest validators' output logs form a single ever-growing chain.
Implementation Notes
4.1 Concept-to-Code Map
In the C++ node, the implementation lives in validator/consensus/. The following table maps
protocol concepts to their code counterparts:
| Protocol concept | Code |
|---|---|
| Slot | CandidateId::slot (types.h); per-slot state in ConsensusState::slots_ (simplex/state.h) |
slots_per_leader_window in NewConsensusConfig::Simplex | |
| Leader rotation | SimplexCollatorSchedule::expected_collator_for: (simplex/bus.cpp) |
| Candidate | struct Candidate (types.h): ID, parent, block data, leader signature |
| // votes | NotarizeVote, SkipVote, FinalizeVote (simplex/votes.h) |
| Certificates | Certificate<T> template (simplex/certificate.h); aliases NotarCert, SkipCert, FinalCert |
| Frontier | PoolImpl::now_ (simplex/pool.cpp): smallest slot not yet notarized or skipped |
| Rule 1 (frontier tracking) | PoolImpl::advance_present advances now_; ConsensusState::notify_finalized prunes old slots |
| Rule 2 (candidate resolution) | CandidateResolverImpl (simplex/candidate-resolver.cpp): random-peer fetch with exponential backoff (0.5 s initial, 1.5, 30 s cap) |
| Rule 3 (leader duty) | BlockProducerImpl::generate_candidates (block-producer.cpp): produces candidates per window |
| Rule 4 (notarize) | ConsensusImpl::try_notarize (simplex/consensus.cpp): async pipeline of parent wait state resolve validate vote |
| Rule 5 (finalize) | ConsensusImpl::try_vote_final (simplex/consensus.cpp) |
| Rule 6 (skip) | ConsensusImpl::alarm (simplex/consensus.cpp): fires after first_block_timeout_s_ per window |
| Rule 7 (cert formation/rebroadcast) | PoolImpl::handle_vote (simplex/pool.cpp) forms certs at quorum; PoolImpl::handle_our_certificate rebroadcasts obtained certificates |
| Rule 8 (standstill) | PoolImpl::alarm (simplex/pool.cpp): fires every 10 s, broadcasts all held certs and own votes |
Communication uses a private validator overlay (simplex/private-overlay.cpp). Votes and
certificates are sent individually to each peer. Candidates are broadcast using two-step FEC
erasure coding (overlay/broadcast-twostep.cpp), where the data is split into
symbols and each peer receives one symbol.
4.2 Deviations from the Rules
Rule 3 only requires the leader to produce one candidate per window. The implementation produces
: generate_candidates loops over all slots in the window, producing one candidate per slot
with each referencing the previous as its parent. Later candidates in the window begin generation
immediately without waiting for earlier ones to be notarized, since the leader already knows the
only possible parent — it just produced it.
The implementation sometimes suppresses votes that the Section 3.1 rules would require. None of these affect liveness, since in all such situations the suppressed vote would not lead to formation of a new certificate for a non-finalized slot.
Rule 6 requires , where is
determined by the last finalization that was reached. The implementation currently resets the
timeout upon seeing a leader window without skip votes — this is a bug and will be fixed. We
additionally cap at 100 s, in the expectation that any reasonable consensus
synchronization will not require longer skip timeouts. Regardless, a mechanism to manually
increase first_block_max_timeout_s is planned.
4.3 Network Model Discussion
Assumptions 10 and 11 require bounded delivery times and . This is justified because the implementation caps candidate payload size at a constant , so delivery time is for both broadcast and resolution.
The egress induced by the protocol is currently unbounded. In particular, a sufficiently long period of asynchrony (or a bug) can induce a state whose synchronization saturates link capacity, causing unsynchronized state to only grow further — a death spiral. We plan to address this with better timeout tuning and optimizations to the standstill resolution mechanism.
The two-step FEC encoding uses data symbols distributed one per peer. Reconstruction requires any of the symbols, tolerating at most losses. This is a count threshold, not a weight threshold. We consider this acceptable since we do not expect the number of Byzantine validators to significantly exceed their share of total weight.
The network model requires drop probabilities to be independent across packets. In practice, QUIC is more likely to drop packets after a burst of high momentary egress, even when it could have spread the load over time. We plan to address this by more precise tracking of the moment each message becomes irrelevant for the protocol, allowing earlier cancellation and reducing unnecessary egress.
4.4 Empty Candidates
The leader sometimes produces an empty candidate — one that references an existing block by
its BlockIdExt rather than carrying new block data. Empty candidates participate in consensus
normally (they are notarized, finalized, and form chains) but do not advance any user-visible
blockchain state.
Empty candidates are generated in two situations, both driven by constraints external to consensus:
-
A shardchain leader generates empty candidates when the masterchain's last finalized seqno falls more than 8 blocks behind the shard's current tip. This is a legacy validation requirement that prevents the shardchain from building an arbitrarily long tail of blocks that the masterchain has not yet acknowledged.
-
A masterchain leader generates empty candidates when the next block to produce would be more than one seqno ahead of the last consensus-finalized block. This ensures that every masterchain block eventually receives finalization signatures, which all non-validator nodes depend on.