Notes on NEAR's MPC

tl;dr: The good: Audit went well. Lúcás Meier’s Caith-Sith threshold ECDSA protocol seems like a reasonable, conservative choice. The bad: Near’s MPC currently works in a 5 out of 8 setting, without any proactive refresh.

Notes

Good

• MPC’s configuration is transparent, on-chain $\Rightarrow$ can monitor for suspicious membership changes
• “uses the Cait-Sith protocol in a secure manner”¹
• “we did not identify any issues related to Beaver triple or nonce reuse that could compromise the security of a shared key”¹
• NEAR currently only uses Cait-Sith on mainnet (May 1st, 2026)
  • (The MPC committee can change this over time, of course.)

Unclear

• There is a proof for Cait-Sith but it’s in a new framework called MPS which is claimed to be UC-like
  • (For all I know, this framework could be much better than UC!)
  • Overview
    • (0): Preliminaries
    • (1): Echo Broadcast
    • (2): Key Sharing
    • (3): Multiplication and Triples
    • (4): Signing
    • (X): Cheat Sheet
  • Initially, I thought the proof was missing
• ❓ No audit for the robust threshold ECDSA scheme by Damgård et al.²

Somewhat concerning

• Claude Code identified four unaddressed items from the Trails of Bits audit; they are not high-severity though:
  • #4 Ciphertext swapping (DB AAD missing) – Informational, Cryptography
  • #5 Hash function used as KDF (derive_tweak) – Informational, Cryptography
  • #6 P2P identity misbinding (duplicate p2p public keys) – Medium, Data Validation
  • #10 AES-GCM nonce reuse (96-bit random, no rotation) – Medium, Cryptography
• NEAR modified the Cait-Sith scheme¹
  • multiplicative rerandomization of presignatures

Concerning

• TEE-backed MPC nodes are off on mainnet (as of May 1st, 2026)
• NEAR had a lot of GitHub CI security issues in the Trail of Bits report (#12, #13, #14¹)
  • #14 could’ve allowed an attacker to release a completely malicious binary (was rated “difficult” though)

Deeply concerning

• 5 out of 8 secret-sharing on mainnet (see here)
  • The Ronin Bridge attack compromised exactly $t=5$ out of $n=9$
• No proactive refresh, even though re-sharing (for nodes leaving and joining) is implemented and would be trivial to call periodically
  • Not sure why: without proactive refresh an attacker can slowly take its time and compromise all 5 keys
  • The last re-sharing (and thus refresh) was on March 3rd, 2026
    • $\Rightarrow$ any progress an attacker made in the last 2 months (as of May 1st, 2026) is still good progress
  • Maybe proactive refresh would invalidate the ECDSA presignatures?
• The Cait-Sith threshold ECDSA library was not part of the audit; only its use by NEAR’s MPC node implementation was audited¹
  • This library may not have been production-ready.

Resources

Links and notes

• NEAR actually implemented two different threshold ECDSA protocols: Cait-Sith³ and Damgård et al.²
• Documentation on Caith-Sith library and design
• Near MPC repo

NEAR MPC nodes

Operators:

• lacksandtech.near,
• mpc-lgns.near,
• multichain-mainnet-aurora.near,
• near-mpc-staking4all-01.near,
• nodemonster.near,
• n1-multichain.near,
• everstake-mpc-1.near,
• stakin-mpc.near

NEAR-affiliated names visible:

• n1-multichain.near (NEAR One)
• multichain-mainnet-aurora.near (Aurora)

The rest are independent operators (Everstake, Stakin, etc.).

Fetch all NEAR participants

curl -s -X POST https://rpc.mainnet.near.org -H "Content-Type: application/json" -d '{
    "jsonrpc":"2.0","id":"1","method":"query",
    "params":{"request_type":"call_function","finality":"final",
              "account_id":"v1.signer","method_name":"state","args_base64":"e30="}
  }' | jq -r '.result.result | implode' | jq .

MPC evolution

Based on visible on-chain history, no pure refresh (same set) has happened on mainnet. Every reshare was triggered by a membership change.

Here’s what each epoch’s vote_new_parameters proposal actually contained (winning proposals only, ordered by epoch):

Run this vibe-coded script to reproduce these results.

References

For cited works, see below 👇👇