Threshold signing allows multiple parties, each holding a secret key share, to jointly compute a signature over a specific message. Such a technology guarantees cryptographically the possibility of generating valid signatures if and only if at least $t$ participants actively take part in the signing process, where $t$ is the system’s threshold parameter. In other words, any $t-1$ malicious parties would fail to generate a valid signature without the inclusion of one honest signer.

Our system maintains a pool of eight signers. For each protocol instance, a subset of five signers is selected to participate, and operations require approval from all five participants (i.e., a 5-of-5 configuration). As we scale, we plan to increase the total number of available signers while preserving strong security guarantees and high performance.

A preliminary performance assessment revealed that the primary bottlenecks stem from the complexity of our deployed ECDSA scheme (based on Cait-Sith implementation), which we refer to as OT-Based ECDSA. This protocol requires more than eleven computation-heavy communication rounds and exhibits quadratic communication overhead with respect to the number of active participants. We split this scheme (as well as all other schemes) into two phases: an offline phase and an online phase. The offline phase is a precomputation stage that occurs before the message is known to the protocol participants. During this phase, participants collaboratively generate cryptographic assets that will be needed in the online phase. Once the message becomes known to the signers, the online phase begins, and signatures can be produced and delivered with minimal delay, since all necessary computations have already been performed in advance. In this blog post, all the schemes mentioned require a presigning protocol (Presign), which is part of the offline phase, and a signing protocol (Sign), which belongs to the online phase. Additionally, the OT-Based ECDSA scheme requires a Two Triple Generation protocol during the offline phase, which must be executed before the presigning protocol.

To address the OT-Based ECDSA performance limitations, we implemented and evaluated a more efficient ECDSA construction based on [DJNPO20], which we refer to as Robust ECDSA. To quantify the expected improvements, we developed a dedicated benchmarking methodology.

This blog post presents our approach, assumptions, and findings and shows results for the OT-Based ECDSA, Robust ECDSA and (for completeness) our EdDSA implementation based on FROST [KG20].

Benchmarking

Prior to this work, we had multiple threshold signature schemes implemented, but no systematic way to compare their practical performance. A key challenge in this setting is that these protocols are inherently distributed, yet benchmarking them on multiple machines is costly and difficult to control. As a result, our goal was to design benchmarking methodologies that run on a single machine while still providing results that are representative of real-world deployments.

To address this gap, we designed two benchmarking approaches based on Rust’s Criterion framework to measure computation time. To ensure a fair comparison between the implemented schemes, we evaluated them under a shared invariant: the security level, defined as the maximum number of malicious parties tolerated.

Importantly, for a fixed maximum number of malicious parties, different schemes may require different numbers of active participants. Our methodology accounts for this distinction, enabling an apples-to-apples comparison at an equivalent security level. Naturally, derandomizing our algorithms was a necessary precondition for producing consistent results, thereby improving the reliability of our benchmarks by eliminating protocol-induced randomness.

Our first approach measures the end-to-end execution time of each scheme by running all participants on a single machine. We refer to this as the naive technique. While straightforward and fast to implement, this method does not fully reflect realistic deployment conditions and may therefore produce results that are only partially representative. In the following section, we describe how this technique operates in practice and explain why we classify it as “naive.”

We then designed and implemented a more representative, advanced technique. This approach captures a snapshot of the communication during protocol execution and subsequently replays the protocol from the perspective of a single participant using the recorded data. By doing so, we are able to isolate and measure the per-participant computational cost, while still accounting for network latency and communication volume. The advantage of this approach is that it provides a more accurate approximation of real-world performance without requiring a fully distributed deployment for each benchmark run.

All benchmarks were executed on a laptop equipped with an AMD Ryzen 7 7730U processor with Radeon Graphics and 16 GB of RAM with a clock speed ranging between 3.2-4.3 GHz. Each experiment was run for a minimum of 15 iterations to ensure statistically meaningful results.

Naive Technique

A straightforward way to benchmark our schemes is to execute the entire protocol with all participants running side by side and then analyze the aggregated results. We refer to this approach as naive for several reasons:

1. Sequential execution distorts computation costs.
   Participants are executed sequentially in a single environment. When combined with the quadratic or cubic communication complexity of some protocols, this makes it difficult to isolate per-participant computation time.

2. Potential unfairness across schemes.
   Different signature schemes may require different numbers of active participants to tolerate the same maximum number of malicious parties. In our naive benchmarking approach, all participants are executed sequentially on a single machine, causing the total runtime to scale with the number of participants. This can introduce bias when comparing schemes, as protocols requiring more participants may appear slower, even though in a real distributed deployment these participants would operate in parallel.

3. Overcounting communication costs.
   When a participant broadcasts a message to all others, the same send operation is effectively measured multiple times, artificially inflating the perceived communication overhead.

The table below reports the results of our Criterion benchmarks for Robust ECDSA and OT-Based ECDSA, with the maximum number of malicious parties fixed at 6.

In this configuration, Robust ECDSA requires 13 active participants to tolerate 6 malicious parties, whereas the OT-Based scheme requires only 7. Despite the higher number of participants, Robust ECDSA demonstrates substantially faster offline phase performance by eliminating the costly “Two Triples Generation” phase.

Advanced Technique

A more accurate benchmarking approach is the snap-then-simulate method. In this setup, the protocol is executed with a single real participant (the coordinator), while all other participants are simulated.

We study protocol scalability by increasing the number of simulated participants within this framework. Although only one participant runs as a real process, the simulator emulates the interactions of all other parties with the real participant. As the number of participants grows, the real participant must handle a proportionally larger workload: it processes more messages, performs more computation, and sends/receives more data over the network. This allows us to faithfully capture how the per-participant computational and communication costs scale with the total number of participants.

More specifically, we first enabled derandomization of our algorithms during benchmarking to ensure reproducibility. Next, we implemented a function that executes a protocol with all participants and records all exchanged messages in a dictionary. We then developed the simulator logic, including a function that allows the simulator to respond to a real participant in a simplified, dummy manner using the previously captured snapshot data.

During the second (simulated) run, we benchmarked the real participant’s performance using Criterion. Additionally, we enabled measurement of the data volume received by each participant throughout the protocol execution.

Why is this technique better than the naive one?

1. Fair benchmarking across protocols.
   Even when one scheme requires more participants than another, this method focuses on the performance of a single real participant rather than measuring all participants simultaneously.

2. Accurate representation of $O(n^2)$ communication costs.
   By simulating all-but-one participants, we avoid artificially inflating communication complexity. This reduces the protocol from $O(n^2)$ to $O(n)$ for benchmarking purposes, allowing a clearer focus on the real participant’s computation and communication.

3. Easy measurement of data transmitted.
   The snap-then-simulate approach makes it straightforward to track the amount of data sent and received by each participant during a protocol run.

Results & Analysis

In this section, we present selected benchmark results. The tables below show the time required for a single participant (or coordinator, where applicable) to complete each protocol. These measurements were obtained using the advanced snap-then-simulate benchmarking technique, providing a more accurate and representative view of per-participant performance.

Note that in the naive benchmarking, the time reported for Two Triples Gen and Presign roughly corresponds to the time measured in the advanced setting multiplied by the number of active participants, i.e., \(\text{time}_{\text{naive}} \approx \text{time}_{\text{advanced}} \times \text{number\_of\_participants}\)

For a higher number of tolerated malicious parties, the measured results are as follows:

The Robust ECDSA offline phase is 40× faster than that of OT-based ECDSA when the maximum number of malicious parties is 6, and 22× faster when the maximum rises to 15. We attribute this difference primarily to the increasing number of active participants required in the Robust ECDSA setting which relies on honest majority assumptions.

Latency

Because the computation time of both schemes is relatively small, adding network latency has a proportionally larger impact, effectively dominating the total measured time. As a result, the observed performance under latency depends primarily on the number of communication rounds each scheme requires. The table below provides the number of rounds per protocol run:

Our implementation does not yet support explicitly adding latency to the communication but we are currently working on this feature. However, when accounting for network latency, the total execution time can be estimated using the following formula: $\text{latency} \times \text{rounds} + \text{computation}$.

For example, we have the following results:

Notice that the Robust ECDSA offline phase is roughly 4.7× faster than the OT-Based ECDSA offline phase. In fact, as network latency increases, the ratio approaches 3.3×, reflecting the ratio of communication rounds (10 vs 3).

Bandwidth

In real systems, scalability is often limited by network bandwidth. To explore this, we measured the total amount of data received by a real participant during a snap-then-simulate protocol run. Inferring data per individual round from the snapshots would require a major refactor of our cryptographic communication channels—a complex task that could introduce breaking changes in our deployed product. As a result, computing per-participant, per-round data is ongoing work and is not included in this post. Instead, we report the total data received over the entire protocol execution.

For protocols that distinguish a coordinator from regular participants, we specifically measured the data received by the coordinator. As expected, the coordinator receives more data than other participants, since it is the only party capable of producing a signature. Across our benchmark runs, the amount of data sent was stable, with zero variance across iterations.

Additionally, the reported sizes are expressed in bytes and include the metadata (e.g., receiver ID, session number, etc.) sizes. The measurements reflect the raw data transmitted by the protocol itself, including application-level metadata such as the sender, receiver, and session identifiers. They do not include transport-layer overhead such as TLS or TCP headers, which would slightly increase the total byte count in a real deployment.

Conclusion

The primary goal of this work was to determine whether the Robust ECDSA scheme can replace OT-based ECDSA as a more scalable and efficient alternative. Our benchmarking results confirm that it can: Robust ECDSA outperforms OT-based ECDSA across all measured dimensions — latency, communication rounds, and bandwidth. With 15 maximum malicious parties and 100 ms of latency, the Robust ECDSA offline phase is approximately 4.7× faster than OT-based ECDSA and transmits 130× less data over the network. We found no scenario in which OT-based ECDSA holds an advantage.

It is important to note that FROST is not directly comparable to the ECDSA schemes, as it implements EdDSA — a fundamentally different signature algorithm operating over a different curve. The choice between ECDSA and EdDSA is dictated by the target blockchain’s requirements, not by performance alone. We include FROST in our benchmarks to provide a complete picture of the threshold signing implementations available in our system. That said, FROST’s results are noteworthy: with only one communication round in the offline phase, it achieves 3–15× lower latency than both ECDSA variants while maintaining comparable online-phase performance and low bandwidth usage. For chains that support EdDSA, FROST is the most lightweight option available.

Overall, both Robust ECDSA and FROST exhibit reasonable bandwidth usage as the number of participants grows, demonstrating that our system is well-positioned to scale further with an increasing number of active signers.

This is the problem that confidential key derivation (CKD) solves. In this post we describe how we designed and implemented CKD as a new feature of NEAR Protocol’s Chain Signatures, an implementation of threshold signature schemes secured by a Multi-Party Computation (MPC) network. Chain Signatures allow smart contracts and accounts on the NEAR blockchain to securely authorize transactions on external, heterogeneous blockchains without relying on centralized custody or wrapping assets.

At its core, CKD turns our MPC network into a decentralized key management service (KMS). It offers authenticated clients the ability to derive cryptographic keys for various purposes, such as data-at-rest encryption. These keys are available to any authenticated client at any time and are protected against corruption of individual nodes. The keys supplied by the system are deterministic and remain confidential by using public key encryption during the generation process. Determinism is a critical property, particularly for TEE-based applications, where consistent key derivation is essential.

Confidential Key Derivation (CKD)

The confidential key derivation feature is an extension of the current MPC system. At its core it uses threshold BLS signatures. On a high level, it provides authenticated applications with deterministic secrets. Deterministic means that the same application may request the same secret at different points in time. Confidential means that the secret itself is never revealed to any entity other than the application itself, not even to individual nodes in the MPC network.

Applications

Our main use-case for CKD is to allow any app running inside a TEE (for example, Intel TDX) to have a deterministically derived key that is unique to the app and not specific to the TEE. The app can derive the exact same key as many times as it desires even when running on a different TEE. To obtain the key, the app can leverage the CKD functionality in the NEAR protocol blockchain. This key can be used, for example, to encrypt its storage, so that it can be decrypted later in another machine while remaining confidential.

More generally, creating a service that can supply confidential deterministic keys in the NEAR blockchain unlocks a massive range of decentralized possibilities. For example, it can be used to enable time-lock encryption. A smart contract could encrypt data under a key that is only derivable once certain on-chain conditions are met, such as a deadline passing or a governance vote concluding. Until then, not even the MPC nodes can decrypt the data. This enables sealed-bid auctions, delayed reveals, and scheduled disclosures without a trusted third party.

Another example is the generation of verifiable randomness (private or public). Because the derived key is deterministic and verifiable, it can serve as a source of unbiased randomness: no single party can influence the output, and anyone can verify it was computed correctly. This is useful for decentralized applications that require fair randomness, such as games, lotteries, and leader election protocols.

Problem

Informally, confidential keys satisfy the following properties:

• The TEE app should be able to recover the confidential key without having to store it directly, which is very useful in the case of crashes or reboots
• The key should never leave the TEE app that requested it. This entails that the key can only be determined by the expected receiver. In particular, neither an MPC node nor a blockchain observer should be able to deduce such a key.
• Each TEE app should obtain a unique confidential key
• Correctness assurance. The TEE app should be able to check that the received key was computed correctly

Formally, these keys must be:

• Deterministically extractable, depending only on the TEE app’s authenticated identifier $\texttt{app\_id}$ and MPC Public Key $\texttt{pk}$
• Confidential
• Verifiable

Attacker Model

These are the attacker models we consider throughout this blog post:

• MPC nodes might be malicious, and try to obtain app’s secrets. In our $t$-of-$n$ threshold setting, where $n$ is the total number of nodes and $t$ is the minimum number required to reconstruct a secret, up to $t-1$ nodes might be malicious.

• App developer might be malicious. It may attempt to obtain secrets belonging to other applications or to extract secrets from the MPC network.

• App developer colluding with up to $t-1$ malicious MPC nodes. This is the most general attacker, as it subsumes the two previous cases.

Possible Solution with Encrypted Signatures

One approach to solve the problem is to encrypt signatures over some message, and use the signatures to obtain a secret. As we require determinism, not every possible threshold signature scheme is fit for this purpose. Before CKD was implemented, the MPC network supported only threshold ECDSA and EdDSA signatures, none of which are deterministic. Given that a deterministic signature scheme can be used as a PRF to generate random coins, we use BLS for this purpose. Furthermore, these signatures are very efficient to compute in our threshold setting.

System Overview

flowchart TD
    TEEapp[TEE app] -->|"`1\. send (attestation, A)`"| DevC["Developer contract
    (verifies attestation)"]
    subgraph Blockchain
    DevC -->|"`2\. request key (A)`"| MPCC[MPC contract]
    end
    MPCC -->|"`3\. compute key (app_id, A)`"| MPCN[MPC Network]
    MPCN -->|"`4\. return (es)`"| MPCC -->|"`5\. return (es)`"| DevC -->|"`6\. return (es)`"| TEEapp

In this section we explain our solution in detail. While building our solution, we converged to a protocol similar to VetKeys, even though we were not aware of this result. For simplicity we will describe a reduced version of the system, shown in the diagram above. The details of the full system can be found in docs.

The system contains mainly four components: TEE app, Developer contract, MPC contract and MPC network. The TEE app wishes to use the CKD functionality to obtain confidential keys. To obtain a key in encrypted form, the TEE app sends a public key and an attestation proof to the Developer contract, which verifies that the app is running inside a secure environment through remote attestation. Upon successful verification, the Developer contract calls the MPC contract to request the key derivation. The MPC contract identifies the caller by its account id, which serves as a unique, authenticated identifier for the application, denoted by $\texttt{app\_id}$. The MPC contract then signals the MPC network to compute the corresponding key, encrypted by the public key of the TEE app. Once the MPC network is done computing the key in encrypted form, one of its members, which we call coordinator, publishes this value in the blockchain. Next, the encrypted key is returned to the TEE app that requested it. Note that in the full system the Developer contract can also pass an arbitrary key derivation string alongside the request, so that it can derive as many distinct keys as needed.

Next we will dive into the protocol details, but before that we need to define a few elliptic curve concepts and some notation.

Elliptic Curve Notation

Elliptic curves over finite fields are mathematical objects with many applications in cryptography. An elliptic curve is a set of points in two dimensions, where the point coordinates are scalars in a finite field. The curve points satisfy a polynomial equation, such as $y^2 = x^3 + 4$ for the BLS12-381 curve, and form a group with respect to the point addition operation. The group order is a prime $q$.

For the rest of this blog post, we use the following notation:

• Lower case variables, such as $x$ and $y$, denote scalars modulo group order $q$
• Upper case variables, such as $G$ and $Y$, denote elliptic curve points. $G$ will be reserved for the generator of the curve
• $H$ is a hash to curve function defined in RFC 9380, which translates bytes to elliptic curve points for which computing the discrete log is hard
• $ Y \gets y \cdot G $ is the scalar multiplication of $y$ by the group generator $G$
• $y \gets^{$} \mathbb{Z}_q $ is scalar $y$ picked uniformly at random from $ \mathbb{Z}_q $

MPC Network Notation

• $\texttt{msk}$: secret key of the MPC network
• $\texttt{pk} \gets \texttt{msk} \cdot G$: public key of MPC network
• $x_i \in \mathbb{Z}_q$: private key share of node $i$, for $i = 1, \ldots, n$
• $\lambda_i$: Lagrange polynomial coefficients. By definition we have $\sum_{i=1}^{n}{\lambda_i \cdot x_i} = \texttt{msk}$

Protocol Steps

• The TEE app generates a fresh elliptic curve ElGamal key pair $(a, A)$ and requests a key from the Developer contract. This request includes a remote attestation proof
• The Developer contract verifies the TEE app is correctly being executed inside a TEE, by verifying the remote attestation proof. Upon successful verification, it forwards the request to the MPC contract
• The MPC contract sets $\texttt{app\_id}$ equal to the account id of the caller (the Developer contract), which serves as a unique, authenticated identifier for the application, and approves the request to be handled by the MPC Network

• MPC node $i$ receives a new CKD request $(\texttt{app\_id}, A)$ and computes:

  \[\begin{aligned} & y_i \gets^{\$} \mathbb{Z}_q \\ & Y_i \gets y_i \cdot G_1 \\ & S_i \gets x_i \cdot H(\texttt{pk}, \texttt{app\_id}) \\ & C_i \gets S_i + y_i \cdot A \\ \end{aligned}\]

Notice that this is basically computing a BLS signature of $H(\texttt{pk}, \texttt{app\_id})$ using the node’s private share $x_i$ as private key, and encrypting the signature using ElGamal with the TEE app’s public key $A$.

• MPC node $i$ sends $(\lambda_i \cdot Y_i, \lambda_i \cdot C_i)$ to coordinator

• The coordinator adds the received pairs together and computes the encrypted secret $\texttt{es}$:

  \[\begin{aligned} & Y \gets λ_1 \cdot Y_1 + \ldots + λ_n \cdot Y_n \\ & C \gets λ_1 \cdot C_1 + \ldots + λ_n \cdot C_n = \texttt{msk} \cdot H(\texttt{pk}, \texttt{app\_id}) + a \cdot Y \\ & \texttt{es} \gets (Y, C) \end{aligned}\]
• Coordinator sends $\texttt{es}$ to TEE app on-chain through the MPC contract

• TEE app obtains $\texttt{es} = (Y, C)$ and computes the secret (which is a BLS signature):

  \[\texttt{key} \gets C + (- a) \cdot Y = \texttt{msk} \cdot H(\texttt{pk}, \texttt{app\_id})\]
• Then checks its correctness with respect to the MPC network public key $\texttt{pk}$

The choices related to the last step above, in which the TEE app verifies whether the secret obtained is correct, are explained in more depth in the next section.

Verifiability

As mentioned in the Problem section, achieving verifiability is a desirable feature for such a system. In this section we first show that it is actually necessary, as the system above without any verification step is insecure. Then we explain how we currently achieve private verifiability, and how we plan to achieve public verifiability in the near future.

We consider two definitions of verifiability:

• private verifiability: the TEE app is able to verify that the received confidential key is correct with respect to the MPC public key
• public verifiability: anyone, for example the MPC contract or any blockchain observer, should be able to verify that the encrypted key is correct, even without being able to decrypt it

To show why verifiability is needed, we first consider the case where no verification of the resulting confidential key (or its encryption) is done by any protocol party.

No Verifiability

If upon reception of the encrypted secret $\texttt{es}$ the TEE app does not execute any verification step, the following attack by the coordinator is possible. Consider the honest coordinator output:

If instead the coordinator computes:

Upon reception of $(Y, C)$, the TEE app would compute its confidential key as:

This is a value that is already known by the coordinator, breaking the confidentiality of the obtained key.

Private Verifiability

In our current system, upon reception of $\texttt{es}$, the TEE app first decrypts the key:

$\texttt{key} \gets C + (- a) \cdot Y$ and then verifies it is equal to the expected value $\texttt{msk} \cdot H(\texttt{pk}, \texttt{app\_id})$ by checking its validity as a BLS signature of the message $H(\texttt{pk}, \texttt{app\_id})$.

In a nutshell, this verification leverages the pairing function $e$ associated with elliptic curves used for BLS signatures:

This thwarts the attack explained above because the coordinator has no way to ensure the maliciously constructed $\texttt{key}$ is a correct BLS signature for $H(\texttt{pk}, \texttt{app\_id})$.

Public Verifiability

Achieving public verifiability (with minor modifications) is also possible. This is desirable, because it would allow the MPC contract to detect if something has gone wrong during the distributed computation by the MPC network. It would also guarantee that if the TEE app obtains a response, then this response is correct. One possible variant is the following:

• app public key:

• coordinator output:

• MPC contract verification:

The first check ensures that $Y_1$ and $Y_2$ are consistent, i.e. that the coordinator used the same scalar $y$ in both groups. The second check verifies that $C$ is a valid ElGamal encryption of the correct BLS signature under the app’s public key, without needing to decrypt it. Together, these prevent the coordinator attack described earlier, since the contract can reject malformed responses before they reach the TEE app.

• TEE app key decryption and verification:

This is the same private verification as before: the TEE app decrypts the ElGamal ciphertext and confirms the result is a valid BLS signature. With public verifiability, this step serves as a redundant safety check, since the contract has already verified the encrypted form.

Performance Considerations

CKD is lightweight by design. Each key derivation requires a single round of communication between the MPC nodes and the coordinator: every node computes one scalar multiplication and one hash-to-curve operation on its private share, and the coordinator aggregates the results with simple point additions. There is no multi-round interactive protocol or heavy on-chain computation involved. The on-chain footprint is limited to storing and forwarding the encrypted secret $\texttt{es}$, which consists of just two elliptic curve points. Verification on the TEE side requires a single pairing check. As a result, CKD adds minimal overhead on top of the existing MPC infrastructure.

Conclusion

In this post we introduced confidential key derivation (CKD), a new feature of NEAR’s MPC network that turns it into a decentralized key management service. CKD provides authenticated applications with deterministic, confidential keys by combining threshold BLS signatures with ElGamal encryption, ensuring that no single MPC node ever sees the derived key. We showed why verifiability is essential by demonstrating a concrete coordinator attack, and explained how private verifiability thwarts it. Public verifiability, which would allow on-chain verification of encrypted keys without decryption, is planned as a next step.

For the full protocol specification, including details on key resharing and threshold management, see the CKD documentation. If you are interested in building on top of CKD, check out the mpc repository.

Appendix: Implementation

For those of you who usually say: Talk is cheap. Show me the code. Here is a simple implementation that shows how the confidential key is computed using our threshold-signatures crate.

//!```cargo
//! [dependencies]
//! rand_core = { version = "0.6.4", features = ["getrandom"] }
//! threshold-signatures = { git = "https://github.com/near/threshold-signatures", rev = "01315cf9fef7064a0b529582c41ffad5f122d584"}
//!```
use rand_core::OsRng;
use threshold_signatures::blstrs::{pairing, Gt};
use threshold_signatures::confidential_key_derivation::{
    ciphersuite::{hash_to_curve, Field, G1Projective, G2Projective, Group},
    AppId, Scalar,
};

fn e(p1: &G1Projective, p2: &G2Projective) -> Gt {
    let p1 = p1.into();
    let p2 = p2.into();
    pairing(&p1, &p2)
}

fn gen_keypair_G1() -> (Scalar, G1Projective) {
    let x = Scalar::random(&mut OsRng);
    (x, G1Projective::generator() * x)
}

fn gen_keypair_G2() -> (Scalar, G2Projective) {
    let x = Scalar::random(&mut OsRng);
    (x, G2Projective::generator() * x)
}

fn H(pk: &G2Projective, app_id: &AppId) -> G1Projective {
    hash_to_curve(&[pk.to_compressed().as_ref(), app_id.as_bytes()].concat())
}

fn verify(pk: &G2Projective, app_id: &AppId, sig: &G1Projective) -> bool {
    e(sig, &G2Projective::generator()) == e(&H(pk, app_id), pk)
}

fn ckd(app_id: &AppId, A: &G1Projective, msk: &Scalar, pk: &G2Projective) -> (G1Projective, G1Projective) {
    let (y, Y) = gen_keypair_G1();
    (H(pk, app_id) * msk + A * y, Y)
}

fn main() {
    let (msk, pk) = gen_keypair_G2();
    let app_id = AppId::try_new(b"example-app.testnet").unwrap();
    let (a, A) = gen_keypair_G1();
    let (C, Y) = ckd(&app_id, &A, &msk, &pk);
    let sig = C - Y * a;
    assert!(verify(&pk, &app_id, &sig));
    println!("Computation ended correctly!")
}

Authors: Andrea Spurio, Jan Malinowski, Slava Savenko, Darioush Jalali

Background on NEAR protocol, stateless validation, and sharding

NEAR uses a sharded, leader-based blockchain where each block contains the outputs of multiple shards, and each shard processes a disjoint portion of the state. Blocks are produced in a fixed sequence of block producers, while chunk producers (one per shard per height) assemble the transactions and state transitions for their shard into “chunks.” A block is essentially a container for these chunks plus receipts that move between shards. Cross-shard communication is fully asynchronous: when a transaction in shard A produces a receipt for shard B, that receipt is routed via the next block and executed by shard B in its future chunk. This design avoids global synchronous execution and keeps the system horizontally scalable as shards are added.

To make such a sharded chain verifiable by ordinary nodes, NEAR supports stateless validation: instead of requiring validators to store the full state, each chunk includes Merkle proofs (state witnesses) that show which parts of the state were read or written. A validating node only needs to verify signatures, apply the transactions over the provided witness, and check that the resulting state root matches the one committed by the chunk producer. This allows NEAR to retain strong security even when individual validators are only assigned to a single shard at a time.

Goal, setup, and focus of benchmark

The focus of this benchmark is to demonstrate NEAR protocol’s scalability via sharding on commodity hardware. In this benchmark, we demonstrate this by using the same neard client reference implementation codebase that runs on mainnet (under different configuration and network setup), to run validator nodes of a high-throughput chain, reaching a peak of 1M native token transfers per second.

We considered cloud hardware that fits in a $1k / month budget for compute and storage. We believe this budget is not excessive in a way that is harmful to decentralization. Our estimates for network traffic at 64 MB/s is $4 / hr using on-demand cloud provider rates. Validators may run on dedicated hardware or use cloud provider service agreements to further reduce costs.

We were able to reach that target using 70 shards and the setup detailed below:

Configuration of network and nodes

• 140 nodes, assigned to 70 shards. Both nodes assigned to the same shard have the chunk producer role, i.e., alternate turns in producing chunks for their assigned shard.
• Nodes assigned across three regions:
  • us-central1 - 47 nodes
  • us-east1 - 47 nodes
  • us-east4 - 46 nodes
• All nodes using:
  • GCP c4d-highmem-16 (8-core CPUs)
  • 200 GB hyperdisk-balanced (440 MB/s, 4200 IOPS) as a boot disk
  • 400 GB hyperdisk-balanced (1200 MB/s, 20000 IOPS) as an attached disk

A note about “mandates” and network security in sharded stateless validation

In stateless validation, a block producer must include endorsement from a sufficient amount of stake (that have validated the state witness proving the new chunk is valid) in order to include a chunk in a block.

NEAR uses a concept called mandates, which represents a tradeoff between the number of witnesses each validator must validate and the safety of the network.

In this work, we choose a number of mandates such that the amount of witnesses validated by each node is the same as it is on the current top 20% mainnet network validators (by stake).

In other words, more nodes are needed to have acceptable security guarantees on a 70 shard network (this allows an increase in the number of mandates). Note that these additional nodes do not need to track state, therefore they need less powerful hardware compared to chunk producer nodes. Starting such large networks could easily have a justifiable cost to scale an actual blockchain, however the cost is prohibitive for benchmarking. Therefore, we study how the nodes of such a chain would operate under a computationally equivalent load that provides security for mainnet (each node ends up validating state witnesses for on average 5 shards).

We refer the reader to additional references around selecting secure committees:

• Sharding: How many shards are safe?
• Nearcore source code for mandate selection
• Random Sampling of NEAR’s Validators

Workload

• Native token transfers,
• Account selection:
  • Source accounts are selected from the shard of the producer using the Zipf-Mandelbrot distribution.
  • The target accounts pool is assembled using all accounts from all the shards randomly shuffled (on each load generator independently) to avoid shards skew. The Zipf-Mandelbrot distribution is afterwards used to select the target accounts for each particular transaction.
  • Distribution parameters for the source and target accounts selection are: shift=2.7, exponent=1.0. For the 1M accounts in 70 shards with 2 producers per shard that results in the following probabilities:
    • ~3.5% for the most frequent source account on each load producer.
    • ~2% for the most frequent target account on each load producer.
• Total number of accounts: 1M

Running the benchmark

To run the benchmark, first we create the accounts and access keys, and then gradually increase traffic over 6 minutes before applying the maximum load. During the initial period, we keep the traffic low as the chain initially has a few chunk/block misses while nodes are coming online.

Chunk producer nodes generate and sign the transactions: this simplified our benchmarking setup and allowed us to exclude RPC and focus on validator throughput. In the steady state, we apply a constant load and the system operates at 0.5 block/s without chunk/block misses. Peer traffic reaches around 64 MB/s in send and receive.

Optimizations

The following is a list of the more impactful and large scale optimizations the team worked on. We also worked on many other smaller scale optimizations, which are not detailed here.

Early transaction preparation

In normal operation, the chunk producer starts ordering transactions from the pool when it’s time to produce the chunk. This allows for inclusion of transactions that were submitted up to that moment, however delaying preparation of transactions until the last moment adds to the overall block latency. We implemented a change that prepares transactions as soon as the prior chunk’s post-state is computed, trading off inclusion of most recent transactions in favor of higher chain throughput. This behavior is controlled by the enable_early_prepare_transactions configuration option, and can be enabled on a per-chunk producer basis.

Persisting less to disk

In this benchmark, we focused on validator performance. By default, and out of convenience, neard persists a lot of data to RocksDB for each block. We found that large portions of this data was not needed for validators, and added configuration options to allow disabling writing of those (with sensible defaults – to avoid impacting existing node operator flows).

• save_tx_outcomes: Transaction outcomes are used by RPC nodes to respond to status queries, but not needed for validators.
• save_state_changes: StateChanges column is used by RPC nodes to respond to queries and by the Rosetta indexer, but not needed for validators.
• save_untracked_partial_chunks_parts: PartialChunks are saved in order to answer requests from nodes that are catching up with the chain; disabling this option avoids writing PartialChunks in the database, and keeps them only in the memory cache.

Ed25519 batch signature verification

NEAR blockchain natively supports ED25519 and SECP256K1 signatures. Since mostly ED25519 signatures are used, we implemented an optimization to verify those signatures in batches of 128, with graceful fallback to verifying individual signatures.

Batched signature verification uses around 40% less cpu resources. However this translated to only around 7-10% improvement in the overall benchmark.

Deserialized column cache

We found the NEAR implementation performs frequent reads of data such as recent chunks, blocks, and block headers. This would not only read through RocksDB but would also deserialize the item on each access! To mitigate this, we implemented a column-level cache for some of these frequently referenced columns, based on profiling observations.

RocksDB Tuning

To improve database throughput under write-heavy workloads, we implemented the following RocksDB optimizations:

• Pipelined Writes: enabled pipelined write path to reduce write stall latency, allowing write operations to overlap more efficiently.
• WAL Tuning: configured WAL (Write-Ahead Log) to sync roughly every 1 MiB, smoothing I/O patterns and reducing latency spikes from large fsync bursts.
• Compaction Tuning: relaxed L0 compaction triggers so background compaction interferes less with foreground writes, and increased target file sizes to reduce the number of SST files. Added compaction read-ahead to help sequential reads during compaction.
• Memtable Configuration: increased memtable memory budget and write buffer count to absorb write bursts and reduce flush frequency.
• Column Family Tuning: allocated more resources to write-heavy column families with larger memory budgets, more sub-compaction jobs for parallelism and bigger write buffers.

TCP Tuning

To reduce latency in state witness distribution and chunk distribution, we implemented several Linux TCP stack optimizations:

• BBR Congestion Control: we switched to Google’s BBR algorithm paired with Fair Queueing (fq). BBR models network capacity based on bandwidth and round-trip time rather than packet loss, achieving higher throughput and lower latency.
• Path MTU Discovery: enabled to automatically discover the optimal MTU along network paths, preventing packet fragmentation and reducing overhead.
• Connection Handling: Increased the SYN backlog to 8096 to queue more incoming connection requests during traffic bursts.
• Buffer Tuning: for benchmarks, we significantly increased socket buffer sizes and raised the network device backlog, allowing the kernel to handle high-volume data transfers without dropping packets.

Actor separation

neard is implemented using an actor-style programming: a collection of independent actors, each with its own state and a mailbox for incoming messages. Actors communicate exclusively by sending asynchronous messages. However, in practice individual actors can become bottlenecks, for example:

• some actors cannot make progress while waiting for a response from another actor,
• an actor takes on too many responsibilities, and ends up handling large amounts of work on the critical path.

Some examples where we identified and solved this type of issue:

• Creating state witnesses on a thread pool to avoid blocking a critical actor
• Separate actor for state witnesses
• Moving chunk-endorsement processing to a multi-threaded actor

Lock contention & trie witness recording optimizations

• Avoiding serialization and hashing nodes when not needed,
• Using dashmap to reduce lock contention in recorder,
• Removed unnecessary tracking of “visited nodes” for state witness – this was taking place due to re-using code from “state sync part verification” logic.

Solutions for some problems we encountered

Visualizing OpenTelemetry traces: Traviz

We used OpenTelemetry traces to analyze node performance. The traces allow us to view exactly how the node operates - when it receives and sends data, when it computes things, and how different nodes relate to each other. Being able to visually analyze all operations in the network was invaluable in understanding what the critical path looks like and which optimizations can be implemented to improve performance.

neard exports tracing data in an OpenTelemetry compatible format. A few mature tools such as Tempo and Jaeger are available in this domain, however they mostly focus on a hierarchical structure for traces (e.g., to break down calls to micro services). This was not enough to help us figure out bottlenecks in a distributed system such as a multi-shard blockchain network. Because of that we developed an in-house trace visualization tool - Traviz. It allows us to view the data exactly the way we need, and has custom NEAR-specific features which make analyzing the NEAR flow easier. We’re planning to publish another blog post with more details about traviz.

Consistently measuring benchmark results and monitoring regressions

To find out the maximum throughput the chain can support we have disabled/adjusted some safeguards supporting the chain stability in the prod. Those include the compute-cost and witness size caps for example that are used to limit the chunk size. While doing so we were not sure precisely which way the chain would break under the traffic exceeding its capacity. It turns out the chain reacts by exponentially increasing the block time and chunk size leading to missing blocks and severe drop in performance. Initial measurements involved running the series of experiments with the varying load to find out the optimal TPS volume. That was extremely human- and hardware- resources consuming, and resulted in noisy (+- 10%) measurements at irregular occasions. Finding the source of regressions (that did happen) used to be a rather painful procedure.

To improve the situation we implemented a proportional–integral–derivative controller (with some fine-tuning to better represent the system’s response) that modifies the load TPS to target the desired block rate. Experiments are fully reproducible with very low variance, allowing to catch the deviations of ~1%. That allowed us to fully automate the benchmarks and add them as periodic CI jobs, with the perf measurements and telemetry saved as artifacts for each run.

For the continuous benchmarking we are targeting the block production time of 1.5s. We found that it represents the throughput close to its maximum values while still keeping the chain in the stable operational range. The nightly jobs are run using the 4-shards chain as a minimal representative sample, and we are running the more expensive 20-shards scenario weekly. The CI setup also provides a convenient way to run the reproducible, self-documenting experiments with a few mouse clicks.

This proved to be useful not only for experiments run by the performance optimization team but also allowed us to catch and quickly bisect several performance regressions introduced by the others.

Scalability

Additionally, we report the following throughput capacity for smaller shards, keeping the same number of total accounts. Currently, mainnet is operating with 9 shards, and these experiments provide an idea about the shorter term scaling potential of the NEAR network:

Impact of optimizations

To specifically highlight the impact of the optimizations, we compared the throughput of 4-shard and 20-shard networks, prior to the optimization work using a commit from master on Mar 25, 2025. The results show around 3.5x improvement (graph included for 20-shard comparison).

Reproducibility

To ensure the community and industry can verify these results, we are releasing the following deliverables:

• Open-source benchmark scripts
• Public Grafana dashboards with 1M TPS runs: Run 1, Run 2, Run 3
• Commit hash of the benchmarked code

These materials enable researchers, auditors, validators, and the wider blockchain ecosystem to reproduce the benchmark and validate these performance claims.

Future work

Optimistic execution and separating consensus from execution

Many parts of the code could be optimized with optimistic execution. Currently execution and consensus are interleaved - the network processes some data, then runs consensus to agree on the state and then processes some more data. It’d be more efficient to run execution in parallel with consensus instead of running them sequentially. This can be achieved using “optimistic” execution which runs on unconfirmed state before the consensus agrees on it.

Separating consensus and execution is the leading theme in the upcoming SPICE upgrade. In SPICE chunks will be produced without waiting for the previous ones to execute, allowing consensus and execution to run at the same time and improving performance. Some optimistic execution might still be needed to achieve maximum possible throughput.

Further reducing storage redundancies

neard still stores state in formats that have redundancies. For example, the State column stores reference counted trie nodes in by hash, and the reference count changes are stored in a separate column (TrieChanges), to enable garbage collection.

Since the time that stateless validation was introduced, most validators operate using in-memory state. RPC nodes still rely on the State column for responding to queries. In the future, RPC nodes may be sharded and also use in-memory state, which could allow further optimizations.

Benchmarking fungible token transfers

In this benchmark, we focused on native token transfers to focus on scalability of the chain independent of the contract runtime. Benchmarking fungible token transfers and optimizing the contract runtime remains as future work.

Benchmarking simplifications

This benchmark focuses on showing NEAR protocol’s scaling potential and providing a validator implementation backed by the same reference client protocol that runs NEAR mainnet today. We want to highlight areas we considered out of scope.

Further work is required to improve the following areas necessary to operate an entire blockchain ecosystem at levels of throughput similar to those demonstrated in this work:

• RPC & archival support: Nodes that operate as “RPC nodes”, with the purpose of responding to queries about blocks and state, persist more data to disk than is needed for validators to operate. Archival nodes persist even more data to disk, including all historical state and block information.
• State sync part generation: Currently in the NEAR protocol, validators divide the state into “parts” and persist parts to disk at the beginning of an epoch. These parts are then served to new nodes who join the network later. We exclude the creation of these parts from the benchmark. In a high throughput chain, theoretically storing these parts could be a specialized role.
• Gas limits and congestion control: Normally, gas limits are set based on usage of mainnet. High-throughput benchmarks involve chunk sizes significantly larger than those observed on mainnet, which impacts gas limits and congestion control. These parameters should be adjusted alongside actual network usage growth.
• Partial Chunk persistence: When the option save_untracked_partial_chunks_parts is set to false, nodes will persist chunk parts only for the shard they track. All other part-owner nodes (the subset of nodes responsible for providing chunk availability guarantees) will only store partial chunks in a configurable-length in-memory cache. The downside of this configuration is that a node needing to request a chunk may not find any suitable peer able to respond successfully. This can happen if the chunk is too old thus out of the cache horizon, or if the other peer was restarted recently and its in-memory cache is fresh. A node that cannot fetch a required chunk will be unable to catch up to the latest block. This is not an issue in the benchmark because nodes are not restarted and no node is lagging behind the tip of the chain.
• Data center location: In this benchmark, we placed nodes across three data centers in “us-central” and “us-east”. Further distributing nodes geographically improves decentralization, however it may impact the network throughput as a result of increased networking latency.

The NEAR blockchain system uses a mechanism called stateless validation to ensure that all transactions are executed correctly. When a NEAR node processes a sequence of transactions and computes a new blockchain state, it produces a state witness alongside the new state. The state witness is a piece of data containing all the information necessary for anyone to verify (“validate”) the transition from the old blockchain state to the new one. The NEAR node then distributes this state witness to a set of other nodes that have the role of validators. Validators verify the state witness and vote if the state transition represented by the witness should be accepted as valid. Their votes (a.k.a. endorsements) are required for the next NEAR block to be produced.

The validators are called stateless because they do not need any prior knowledge of the blockchain state to verify the correctness of the state transition - the state witness is all they need. We are not going to dive into the details of how state witnesses work - they can be found in the corresponding documentation. What we are interested in now is how the validators are selected.

To become a validator, a node needs to lock some NEAR tokens as stake. It is then allowed to vote on (i.e., endorse) NEAR’s state transitions and receives rewards for doing so. We make the common assumption that strictly less than one third of all the stake belongs to faulty (potentially malicious) validators. Building only on this assumption, we need to ensure the following with high probability despite potential malicious attacks.

• Safety: The system does not accept an incorrect state transition.
• Liveness: The system does accept correct state transitions.
• Efficiency: The system does not spend too many resources on the validation process, even with many validators and many state transitions to be verified.
• Fairness: The rewards of correct validators are proportional to their stakes.

NEAR is a sharded blockchain system that splits its state into multiple parts called shards. A separate state transition happens in every shard with each block. If a transaction touches the state in two (or more) shards, it is split into two (or more) separate (though related) state transitions. Making every validator verify every state transition is, unfortunately, not efficient. Therefore, only a limited subset of validators must be responsible for validating each state transition.

How NEAR currently samples validators

NEAR’s current implementation splits each validator’s stake into a variable number of parts and, at each block, assigns each such part to exactly one random shard. The owner of the stake part then becomes responsible for verifying and voting on that shard’s state transition. If the validator consistently performs this task, it receives a corresponding reward.

This method ensures that each of NEAR’s shards is assigned validators with approximately the same amount of stake, intuitively making each shard similarly secure (as it is “backed by” a similar amount of stake). Note that non-sharded blockchain systems do not need to deal with this concern, as they consist of only a single shard.

Our current approach is sufficient for the number of shards and validators NEAR has at the time of writing of this article, but it has several drawbacks. While it does ensure fairness, it can easily become inefficient if the number of validators grows. Since each validator is involved in the voting process at each block, the system might need to process unnecessarily many votes and transmit large amounts of state witness data. We will not discuss the details of the current validation mechanism here (the interested reader can read more in the NEAR Enhancement Proposal 509). It involves variably sized parts of validators’ stake, stake-weighted endorsements, and the safety and liveness guarantees are difficult to formally analyze. It suffices to say that the above considerations bring us to designing a new method of validator selection we are now going to present.

New way of sampling validators

The basic idea is that, instead of assigning each validator to a random shard, we take each shard and assign some randomly selected set of validators to it (while adjusting the selection probability according to the validators’ stake). As we will see later, this subtle detail simplifies the reasoning about the system and allows us to easily quantify the safety and liveness guarantees. In a nutshell, for each state transition, we randomly$^1$ select a small subset of validators that we call the validator sample. The probability of choosing a validator to be included in the sample is proportional to its stake and a validator can be chosen more than once. If enough validators in the sample endorse (vote for) the state transition, we consider the state transition validated.

We pick the validators for a sample with replacement. Validators that have been chosen multiple times have the corresponding number of votes. For instance, if a validator has been included in a sample 3 times, then its endorsement is also counted 3 times. Validators’ endorsements are not weighted by stake, as their stake is already taken into account in the selection probability.

To ensure fairness, we keep rewarding the validators proportionally to their stake (and thus also proportionally to the rate of their endorsements) if they consistently keep voting for correct state transitions.

Safety and liveness requirements

Intuitively, we say: “If a sufficiently large subset (that we call a quorum) of a small representative sample of validators endorse a state transition, then most likely all correct validators would have endorsed it.” The word “representative” is very important here. It means that the sample’s proportion of correct and faulty validators will be similar to that of the overall validator set. Now let us formalize this intuition.

Let us translate “sufficiently large subset of a small sample” to “ $q$ out of $s$ endorsements”. Furthermore, “most likely” shall be “with probability at least $(1-\beta)$”. In other words, we need to choose our validator sample of size $s$ such that the probability that $q$ out of those $s$ validators endorse an incorrect state transition is upper-bounded by a security parameter $β$. Note that this corresponds precisely to the safety requirement defined above.

Conversely, for liveness, we want to ensure that the sample contains enough validators voting for the state transition so it gets accepted. That is, for some small parameter $\gamma$, we need the probability that less than $q$ out of $s$ votes are cast for the correct state transition to be at most $\gamma$. We know that correct validators will always endorse a correct state transition and never an incorrect one. If $f’$ is the relative fraction of faulty validators in a sample (making $(1-f’)$ the fraction of correct ones), we can express the above as follows.

We are free to choose the $\beta$ and $\gamma$ parameters according to our needs (within some constraints that we discuss later). For example, if we consider a system with 50 shards, a block rate of 3 blocks/second, a separate validator set for each state transition, and an expected time to a safety violation of 1 million years, we obtain $\beta$ = 1 / (1’000’000 years · 365 days · 24 hours · 3600 seconds · 3 blocks · 50 shards) = 1 / (4.73·1015 samples) = 2.11·10-16.

Calculating failure probabilities

Let us dive deeper into the representativeness of the sample. We are choosing (with replacement) $s$ validators for the sample, where a validator’s chance of being selected is proportional to its stake. This is equivalent to sampling from the stake itself and including the chosen stake’s owner in the sample. Our assumption is that at most $f = ⅓$ of all the stake may be owned by faulty validators, as depicted below (darts represent randomly selected parts of the stake)

Now it is easy to see that selecting a validator is a Bernoulli trial with the probability of the validator being faulty $f = ⅓$. That makes the number of times we select a faulty validator (denoted by $F$) in a sample of size $s$ a binomially distributed random variable: $F ~ Bin(s, f)$. To obtain the relative fraction of faulty validators $f’$, we divide by the sample size $s$ and obtain $f’ = F/s$, and thus $F = f’·s ~ Bin(s, f)$. We can perform an analogous calculation for the distribution of the number of correct validators with probability $(1-f) = ⅔$ of selecting a correct validator, leading to $(s - F) = (1-f’)·s ~ Bin(s, 1-f)$.

Let us focus on the number of faulty validators $f’·s ~ Bin(s, f)$. Since the expected value of a binomial distribution is $s·f$, the expected fraction of faulty validators in a sample will always be $s·f / s = f = ⅓$. What changes with sample size $s$ is only the variance (represented by the color gradient in the figure below). The bigger the sample size, the less likely $f’$ is to deviate much from $f$.

If we fix the acceptable safety violation probability $\beta$ and a sample size $s$, we can compute the minimal quorum size $q$ that satisfies our safety requirements by evaluating the binomial distribution$^2$. For example, in order to bound the safety violation probability by $\beta = 2.11·10^{-16}$ in a sample of $s = 50$ validators, we need to wait until $q = 45$ of them endorse the same state transition. If we had a larger sample of, say, 75 validators, we would require 60 endorsements to achieve the same safety violation probability. Note that, in a larger sample, we also need a larger absolute number, but a smaller relative number of endorsements (89% vs 79% in the above examples). The plot below shows possible combinations of sample sizes ($s$) and quorum sizes ($q$) for a tolerable safety violation probability $\beta = 2.11·10^{-16}$.

We see that if we use a small sample, we need all of its votes. As the sample grows, we can afford to “lose” some votes. Why does the plot start at a sample size of 33 validators? Because, if we only used 32 or fewer validators, we could not be sufficiently ($\beta = 2.11·10^{-16}$) sure that a state transition is correct even if all those validators endorsed it. There would still be a probability of $(⅓)^{32} ≈ 5.4·10^{-16} > \beta$ that all those 32 validators are faulty.

Safety vs. liveness trade-off

One might be tempted to say that the best choice is to stick with a small sample and a relatively large (but absolutely small) quorum. After all, a smaller validator sample means a smaller communication and computation overhead for the same safety guarantees. This has an important drawback, however: if we ever get even slightly unlucky with our sample, we can easily get stuck, since even a (absolutely) very small (but relatively large) number of faulty validators can block any state transition from being accepted. This is a symptom of a general trade-off: every choice we make regarding $\beta$, s, and q also determines the liveness violation probability $\gamma$. In a small sample, the quorum size required to achieve safety might be prohibitive for liveness. Increasing the sample size allows for a smaller relative quorum, decreasing the liveness violation probability $\gamma$ while maintaining safety.

We can also turn things around and start by fixing $\gamma$ to ensure the desired liveness. However, the resulting maximal allowed quorum size might prohibit us from guaranteeing safety with a sufficiently large $\beta$. We can thus say that the smaller the sample, the tougher the trade-off between safety and liveness.

In practice (i.e. in the NEAR system), safety and liveness requirements are not quite symmetric. A safety violation corresponds to accepting an invalid state transition, e.g., minting or transferring an arbitrary amount of tokens. This situation is very hard to meaningfully recover from and we need to make sure it simply does not occur. A liveness violation in the context of a single state transition, on the other hand, can be dealt with more easily. For example, if a state transition is not accepted by some time-out, we can try again, potentially even using a different, perhaps more conservative validation strategy. This manifests as a performance glitch which might be inconvenient, but, especially if rare, not critical. We can therefore say that for NEAR, we can tune the safety vs. liveness trade-off very much in favor of a low $\beta$ and a relatively larger $\gamma$.

Defending against an adaptive adversary

What was said above would suffice against a static adversary that has to choose the corrupted validators ahead of time. However, an adaptive adversary may wait until we select our validator sample and then corrupt a quorum of just that sample. If we rely on small validator samples, there is no defense against an adaptive adversary without making additional assumptions. Even corrupting the whole sample would fit in the adversary’s budget of ⅓ of the total corruptible stake. Therefore, to deter even an adaptive adversary, we make an additional assumption: a validator can only be dynamically corrupted if doing so doesn’t make it lose money. We then make it expensive to perform an adaptive attack through the following two measures:

1. A validator that endorses an incorrect state transition or consistently fails to endorse a correct one loses its stake.
2. We make sure that any quorum of validators in a sample always has some minimal cumulative amount of stake.

We call the cumulative amount of stake of a quorum in a sample the strength of that sample. There are many subsets of a sample that constitute a quorum with different amounts of stake and we always look at the one with the smallest stake. We assume that an adaptive adversary corrupting a quorum of validators in a sample would need to at least refund the stake to the corrupted validators to make them collude. The strength of a sample then corresponds to the price of an adaptive attack.

We introduce another security parameter $\alpha$ representing the required minimal strength of a sample. When picking a sample, we make sure that its strength is at least $\alpha$ – i.e., that the total stake of every quorum is at least $\alpha$. It is difficult to devise a probability distribution for the sample strength because it depends on how the stake is distributed among the validators (e.g. - “all validators have equal stake” or “most validators have small stake and few have a large one”, etc.). We do show, however, what the sample strength looks like for different quorum sizes in several simulated example scenarios in the figure below.

In the uniform stake distribution, all validators have the same stake. In the pseudo-exponential distribution, the first validator has 10% of the total stake, the second has 10% of the rest (i.e. 9% of the total stake), etc. The last validator, however, has all the remaining stake (that is where the “pseudo” comes from). The “actual” distribution corresponds to the assignment of stake to validators on the NEAR mainnet in September 2025. The standard deviation is not shown, as it is at least an order of magnitude smaller than the value itself.

Note that the uniform sample has less than ⅓ of the stake despite its size being more than ⅓ of the total number of validators. This is because it does not contain 111 distinct nodes - some validators have been picked multiple times, but their stake counts only once. The key takeaway from the above picture is that non-uniform stake distributions tend to lead to stronger samples. This is because very “rich” validators have a high probability of being chosen and drive the sample strength up.

We are slightly hand-wavy about the analysis of the sample strength since, at the end of the day, it is relatively easy to satisfy $\alpha$ whenever we are creating a validator sample in practice. We can simply choose the sample to satisfy $\beta$ and $\gamma$ and then, if necessary, keep increasing the sample size $s$ and quorum $q$ until $\alpha$ is satisfied too. While it might impact the performance, it will never compromise safety or liveness.

In a nutshell

We have seen how to randomly choose a sample of validators to vote on the correctness of NEAR state transitions. We also discussed how to quantify the safety and liveness guarantees we obtain based on the parameters of the sample:

• $s$: sample size
• $q$: quorum size required to accept a state transition

In essence, for a given sample size $s$, the quorum size $q$ is the knob we can turn to determine where on the safety-liveness trade-off we want to be. Increasing $q$ strengthens safety but weakens liveness and vice versa. The sample size $s$ determines how “tough” this trade-off is: if $s$ is too small, we only have bad options. The larger $s$, the more favorable options we have to choose from (using $q$). There is no free lunch, however, and we need to pay for these better options by an increased computation and communication overhead associated with larger samples.

To deal with an adaptive adversary that can corrupt validators on the fly, we use the concept of sample strength to quantify the cost of an adaptive corruption. We can then set acceptable limits on

• $\alpha$: The minimal cost of an adaptive corruption of a validator sample
• $\beta$: The safety violation probability
• $\gamma$: Liveness violation probability

and choose a sample that respects all these limits. To achieve this, we can proceed as follows:

1. Pick acceptable security parameters $\alpha$, $\beta$, and $\gamma$.
2. Pick sample parameters s and q based on $\beta$ and $\gamma$.
3. Draw a sample of size s by choosing a random validator s times, with the probability of choosing a validator proportional to its stake.
4. While the sample strength is less than $\alpha$, keep adding validators.

The first two steps only need to be performed once and only the last two steps are executed for each sample. A practical alternative to point (4.) is to simply pick an all new sample of size s and hope it will be stronger. We might tend to do this if most of the samples we draw are strong enough and this happens rarely, since it technically shortens the expected time until a safety violation happens. What we buy for it is a more consistent performance where no sample exceeds the size $s$.

Lastly, it is important to note that we have always been considering the worst-case scenario, namely one third of the stake being actually controlled by faulty validators throughout the lifetime of the system. The computed failure probabilities are upper bounds that are tight only in the worst case. In practice, the actual amount of stake controlled by faulty validators stays well below the assumed limit ($f$) the vast majority of the time. Therefore, the real-world failure probabilities can also be expected to remain significantly below $\beta$ and $\gamma$.

$^1$We use the entropy provided by the Near protocol at each block as the source of randomness. Whenever we perform “random” sampling, we use pseudo-randomness derived from this entropy. (back to text)

$^2$For details on how we compute the exact values, have a look at the code. (back to text)

This initial halving upgrade is a principles-driven and adaptive approach to maintain sustainability of issuance around the NEAR token, while also laying the foundation for a long-term and systematic inflation strategy. This upgrade is based on community feedback and a broadly supported initial proposal across the NEAR ecosystem. Going forward, House of Stake will play a critical role in the decision-making process around the economic parameters for the NEAR ecosystem.

Timeline and Details

If the vote passes by end of the epoch that includes 01:00:00 UTC on Tuesday, October 28, 2025, the protocol is expected to upgrade to version 81 approximately 7-8 hours after that voting epoch ends.

Conversely, if the vote does not succeed within the designated timeframe, the voting window may remain open for up to an additional 23 days. In this scenario, the protocol upgrade to version 81 is expected to occur in the epoch following the one during which more than 80% of stake has been upgraded.

There will not be any forking of NEAR Protocol because such an upgrade will not be effective until the threshold has been reached.

As inflation is reduced to ca. 2.5%, staking rewards will accordingly change to 4.75%, assuming 50% of the total supply remains staked. To support this transition, MetaPool, LiNEAR, HOT_DAO, and Gauntlet have proposed two complementary programs strengthen incentive alignment across validators and House of Stake governance participants:

1. Proposal – HSP-002: Support smaller validators to ensure network decentralization
2. Proposal – HSP-003: Increase rewards for veNEAR holders to reward early governance participation

Proposal HSP-002 is contingent on NEAR Protocol successfully reducing its inflation to 2.5%, and HSP-003 assumes HSP-002 has been approved and implemented. To read the full proposals, discuss them with the wider NEAR community, and gain governing power, join House of Stake today.

Conclusion

NEAR’s initial inflation rate, set over five years ago before mainnet launch, was designed to bootstrap an active validator set. Today, the network has over 300 active validators and uses a stateless validation security model, increasing cost-efficiency and eliminating the need to reward actors for monitoring and ensuring the security of shards. This halving upgrade and two complementary proposals aim to transition NEAR toward a more sustainable inflation model, while ensuring network decentralization and long-term incentive alignment across validators and NEAR token holders.

With NEAR now facilitating multi-billion dollar volumes and generating new sources of fees through NEAR Intents and future AI products, these economic enhancements help ensure the sustainable growth of the protocol for the long term and create economic opportunity for as many actors across the NEAR ecosystem as possible.

To support these enhancements, please upgrade your mainnet node today and vote on the proposals in House of Stake.

Timeline and Details

July 3rd, 2:30 AM, UTC
First report of a validator node crashing.

July 3rd, 2:48 AM, UTC
Second report, the same node has crashed again.

July 3rd, 2:54 AM, UTC
Initial assessment confirming the number of parts has to be over 256. At this point the chain is progressing and chunks are produced fine, some nodes occasionally crash and restart. Contract deployment is not a frequent action, thus the impact is limited.

July 3rd, 08:11 AM, UTC
A domain expert reviews the issue and identifies the root cause.

July 3rd, 08:27 AM, UTC
A quick fix is ready and sent for review. The fix disables contract code distribution if the number of recipients is over 256.

July 3rd, 10:08 AM, UTC
A concern is raised that not sending the contract code to the validators may create performance issues as they would need to fetch the contract code during state witness validation, slowing down this step. Considering the frequency of contract deployment the performance impact was overestimated.

July 3rd, 10:35 AM, UTC
Another fix is ready, truncating the list of recipients if it is longer than 256. This fix would prevent the chunk producer from crashing. The team does not realize that the recipients would be crashing instead if they are not applying the same fix.

July 3rd, 3:41 PM, UTC
After merging and testing the fix, the 2.6.5 release is ready.

July 3rd, 5:44 PM, UTC
2.6.5 is published and announced as CODE_YELLOW_MAINNET.

July 4th, 11:30 PM, UTC
As the validators adopt the version 2.6.5 they no longer crash upon contract deployment. Unfortunately, non-upgraded receiving validators start crashing. The Mainnet block rate drops to 0.15 (1 block in 7 seconds), the network performance degrades.

July 4th, 7:17 AM, UTC
2.6.5 is adopted by 73% of the validators, the block rate is back to normal. During the incident the block rate went down to almost 0.1 for 30 minutes (1 block in 10 seconds).

Conclusion

The original issue did not cause significant impact and was correctly assessed as CODE_YELLOW. Unfortunately we have overestimated potential performance impact of a simple fix and opted for a more complex one trying to preserve the optimized behavior, which caused a network degradation. At this point we should have upgraded to CODE_RED to accelerate the adoption of the patch.

NEAR One’s release testing includes a gradual rollout of a new version and could have caught the issue, but the full suite takes days to run and does not have hundreds of validators.

Going forward we will be taking a more careful approach towards mainnet hotfixes, opting for the safest option possible and making sure the changes are properly tested. That being said, dealing with Mainnet incidents is extremely hard due to the time pressure and severity of potential consequences.

Finally, we would like to highlight that this issue has been triggered due to progressing decentralization of NEAR and growing number of participating validators.