H1 2025 Web3 Security Report$3.1B in losses, DeFi hit hardest, AI threats on the rise
Read the full report

Audit name:

[L1] COTI | MPC | Jan2025

Date:

Apr 2, 2025

Table of Content

Introduction
Audit Summary
System Overview
Risks
Findings
Appendix 1. Severity Definitions
Appendix 2. Scope
Disclaimer

Want a comprehensive audit report like this?

Introduction

We express our gratitude to the COTI and Soda Labs team for the collaborative engagement that enabled the execution of this Garbling-Based MPC Protocol Security Assessment.

The MPC protocol leverages garblers and dual evaluators to privately compute smart contracts, preserving privacy and security for Ethereum Virtual Machine (EVM) execution in a blockchain setup.

Document

NameGarbling-Based MPC Protocol Review and Security Analysis Report for COTI and Soda Labs
Audited By
Approved By
LanguageC++
TagsGarbled Circuit, MPC, Secure Computation
Methodologyhttps://hackenio.cc/blockchain_methodology
  • Document

    Name
    Garbling-Based MPC Protocol Review and Security Analysis Report for COTI and Soda Labs
    Audited By
    Approved By
    Language
    C++
    Tags
    Garbled Circuit, MPC, Secure Computation

Review Scope

Repositoryhttps://github.com/soda-mpc/soda-mpc
Commit7fb3a27404df5720bf557eca2f0e19cd56081458
Commit After Fixes649eb99e44061b06cad77acbe626f6edded53065

Audit Summary

55Total Findings
53Resolved
2Accepted
0Mitigated

The system users should acknowledge all the risks summed up in the risks section of the report

Documentation quality

  • Documentation is accessible within the codebase, offering clear explanations for components like input wire types and method functionalities.

  • Efforts to articulate intent are evident, providing a solid starting point for a complex cryptographic system.

  • The client provides a comprehensive whitepaper, "Soda Labs MPC Specification for: A Protocol for Two Evaluators" (December 2024), detailing the system design, including security assumptions for IT-MACs, label authentication, and high-level protocol overviews for both semi-honest and malicious threat models. This enhances the effectiveness of security analysis, though minor gaps in implementation specifics remain.

  • README and building instructions are present but outdated, requiring revision to reflect current developments.

  • Recommendations include completing TODOs, adding security notes, unifying comment depth, and providing a protocol summary.

Code quality

  • Codebase demonstrates high potential with advanced techniques like Half Gates and Free XOR for private smart contract computation.

  • Core cryptographic logic shows thoughtful design.

  • Issues include unowned pointers, hardcoded values, and missing input validation/buffer checks.

  • Non-constant-time operations and unresolved TODOs highlight areas needing attention for robustness.

  • Modularity is maintained, but edge cases and integrity checks require further specification to ensure security.

Architecture quality

  • Architecture leverages innovative separation and distribution of the garbling and evaluation design with Half Gates and Free XOR, enhancing privacy and decentralization.

  • Cryptographic whitepaper provides a clear foundation, supporting maintainability of the garbling process.

  • The Garbler’s central role in generating garbled circuits and reliance on fixed cryptographic seeds for key derivation suggest opportunities for dynamic key management enhancements, such as periodic key rotation or distributed key generation, to enhance security and resilience.

System Overview

Soda MPC Protocol is designed to facilitate privacy-preserving execution of user-defined smart contracts. Built on Yao’s Garbled Circuits with Half Gates optimization and Free XOR techniques, it operates as an MPC-as-a-service platform. Users onboard with a symmetric encryption key, shared among MPC nodes, to encrypt private transaction data, ensuring confidentiality even from individual nodes. The protocol supports malicious mode  - tailored to different threat models, aiming to guarantee correctness and privacy under limited adversarial corruption.

System Architecture

The architecture of the version under this audit revolves around a distributed setup involving two Garblers with different signing keys, two Evaluators, and a Key Management Service (KMS). These components collaborate across offline and online phases to prepare, distribute, and compute garbled circuits representing EVM opcodes of encrypted arguments. The design emphasizes privacy by splitting sensitive data and computation across parties, with no single node gaining full visibility into user inputs or outputs.

Garbler Replicas

Role: Acts as the circuit generators and coordinators, responsible for transforming EVM opcodes into a garbled form that obscures its execution.

Function: A Garbler produces garbled circuits using a randomized process, incorporating optimizations like Half Gates to reduce computational overhead. It generates and distributes shares of input labels, permutation bits, and authentication data to the Evaluators. To protect against a single malicious Garbler, two Garblers operate as replicas to protect against single-point compromise, ensuring consistency in circuit generation.

Evaluators E and E

Role: Serve as the computational engines, jointly evaluating garbled circuits to produce contract outputs without learning the underlying private data.

Function: Receive garbled circuits and shares from the Garbler, reconstruct necessary labels based on input types (public, private prior outputs, or secret-shared), and verify the authenticity of data using cryptographic checks. The dual-evaluator setup ensures that each party holds only partial information, requiring cooperation to complete the computation and maintain privacy.

Key Management Service KMS

Role: Initiating user key generation and authentication, mitigating risks from dishonest Evaluators.

Function: Generates pseudorandom key shares for users, encrypts them for delivery, and provides authentication data to Evaluators to ensure key consistency across uses. Typically co-located with the Garbler, it acts as a trusted intermediary to prevent Evaluators from supplying incorrect shares or disrupting the protocol. In order to mitigate a single malicious KMS node, this function is replicated twice and the Evaluators match their response before proceeding to the next steps.

Major Components and Workflow

  • Garbled Circuits: Represent EVM opcodes as cryptographic constructs, using Half Gates to optimize AND gates (two ciphertexts per gate) and Free XOR to eliminate XOR gate overhead. The Garbler creates these circuits offline, embedding a per circuit offset (Δ) to maintain label relationships.

  • Label and Bit Sharing: Inputs and outputs are represented by labels (e.g., L{i,0},  L{i,1}) and permutation bits (p_i), split into shares between Evaluators. This ensures no single party can encode or decode private values without collaboration.

  • Authentication Mechanisms: Information-theoretic MACs (IT-MACs) secure permutation bits, leveraging XOR-homomorphism for efficient verification, while AES-based PRP authenticate labels, ensuring integrity against tampering.

  • User Key Management: Users receive a symmetric AES key (k_U) during onboarding, split into shares held by Evaluators. In the semi-honest variant, Evaluators generate and deliver shares directly; in the malicious variant, the KMS ensures authenticated, consistent shares.

Protocol Phases

  • Offline Phase: The Garbler prepares garbled circuits and distributes them, along with shares and authentication data, to the Evaluators. This phase uses pseudorandom generation from seeds to enable matching of GCs from Garbler's replicas, enabling scalable circuit preparation.

  • Online Phase: Evaluators consume garbled circuits as needed, reconstructing labels for current inputs, verifying authenticity, and evaluating the circuit to compute outputs. The process supports public, private, and secret-shared inputs, adapting to each type’s privacy requirements.

  • User Onboarding: Users join the system by obtaining a symmetric key, shared among Evaluators, which they use to encrypt transaction data.

Threat Models and Security Goals

  • Malicious Variant (2 Garblers, 2 Evaluators): Handles active corruption of one Garbler or Evaluator, maintaining correctness and privacy (though availability may suffer); multiple corruptions can compromise both properties.

Summary

The Garbling-based MPC Protocol enables private smart contract execution by distributing trust across Garblers and Evaluators, with optional KMS support for malicious settings. It leverages optimized garbling, shared labels, and robust authentication to balance privacy, efficiency, and security, making it a specialized MPC solution for decentralized applications.

Risks

Below is a summarized list of risks associated with the Garbling-based MPC Protocol with two Garbler replicas and two Evaluators, considering the scenario that stands in contrast to Soda Labs' recommendation, where a single entity operates the Garbler, Evaluator 1 (E₁), and Evaluator 2 (E₂) in good faith. This assessment integrates insights from the Soda Labs whitepaper with protocol specifications therein (December 2024), the code implementation, and the operational context. Each risk is evaluated based on its potential impact on security, privacy, and correctness, assuming the entity’s good-faith intent but acknowledging design, implementation, and operational factors.

Description: With one entity running all nodes (Garbler, E₁, E₂, and KMS), which is a operational mode not recommended by Soda Labs, a system failure, outage, or compromise affects the entire protocol. The whitepaper notes availability risks in the malicious variant if one node stalls (Section 1), amplified here by centralized operation.

Evaluation: The code lacks fault-tolerance mechanisms (e.g., no retry logic in ProtocolPreDeterminedRounds), and the whitepaper’s deployment details (Section 7) are deferred, suggesting unaddressed resilience planning. A hardware failure, DDoS attack, or software bug could halt service, as there’s no redundancy across entities. Good faith doesn’t prevent operational risks.

Description: The protocol employs a Key Management Service (KMS) to facilitate authenticated user key generation (Section 5.2), ensuring secure onboarding of users while maintaining the distributed nature of key shares across Evaluators.

Evaluation: The KMS generates a temporary user key share (kU') and IT-MACs (e.g., M1[kU,1,j'], M2[kU,2,j']) using its secrets S, GMK₁, and GMK₂, enabling Evaluators E1 and E2 to authenticate key shares during user onboarding (Section 5.2, steps 3-4). Evaluators independently compute kU*, ensuring the final user key (kU = kU' ⊕ k_U*) remains distributed and known only to the user, aligning with the protocol’s goal of preventing any single node from accessing the full key (Section 5). To enhance security, KMS replicas share the same secrets but are monitored by Evaluators, who verify the integrity of KMS responses (e.g., signed messages, step 4) and halt the protocol if inconsistencies are detected (e.g., mismatched receipts, step 5), triggering a manual check to address potential compromises. While this mechanism helps prevent immediate misuse of forged IT-MACs in the current session, a compromise of a KMS replica may still expose S, GMK₁, and GMK₂, increasing the risk of IT-MACs being forged in other contexts.

Description: In the ideal deployment, the Garbler, Evaluators (E1, E2), and KMS are operated by distinct entities, aligning with the whitepaper’s distributed trust model (Section 1). Security claims ensure correctness and privacy with at most one node corrupted, limiting the impact of insider threats or misconfigurations.

Evaluation: The protocol splits secrets across entities (e.g., kU = k{U,1} ⊕ k{U,2}, with k{U,1} at E1 and k{U,2} at E2, Section 5; labels Li^b = R{i,1}^b ⊕ R{i,2}^b, Section 3.1), ensuring no single entity can reconstruct private data. An insider at E1 can access k{U,1}, P2[k{U,1,j}], and GMK1 (Section 5.2), but cannot forge IT-MACs without GMK2 (held by E2) or decrypt user data without k{U,2}. A misconfiguration, such as over-permissive access to ek1 (AES key shared with E1, Section 6.3), might expose encrypted shares, but the distributed model limits the impact. However, the whitepaper lacks audit trails or role-based access controls (RBAC) to mitigate insider risks within each entity. For example, a rogue employee at the Garbler could leak SG (Section 6.2), potentially aiding side-channel attacks, though not directly breaking privacy. External coercion (e.g., legal pressure on one entity) or collusion between entities (e.g., Garbler and E1) could also combine shares (S1, k{U,1}), simulating multi-node corruption, but this is outside the protocol’s threat model.

Description: When a single entity operates all nodes (Garbler, Evaluators, KMS), it can access all shares (e.g., R{i,1}^b, R{i,2}^b, p{i,1}, p{i,2}, Section 3.1) and keys (GMK1, GMK2, k{U,1}, k{U,2}, Section 5.2), negating the whitepaper’s distributed trust assumptions and exposing the system to insider threats, misconfigurations, or architectural compromise.

Evaluation: A single entity can reconstruct all secrets, such as kU = k{U,1} ⊕ k{U,2}, Li^b = R{i,1}^b ⊕ R{i,2}^b, and pi = p{i,1} ⊕ p{i,2}, effectively simulating the worst-case corruption scenario in the malicious variant (e.g., both Garblers or Evaluators corrupted, Section 1), which breaks correctness and privacy. An insider (e.g., a disgruntled employee) could access these secrets to decrypt user data or forge IT-MACs (e.g., M1[k{U,1,j}]), bypassing authentication. A misconfiguration, such as exposing the KMS’s S due to poor access controls, would allow regeneration of all user key shares (kU') and, combined with Evaluator shares (k_U*), fully compromise user keys. Even in good faith, an internal breach or external coercion (e.g., legal mandate) could expose user data, as no cryptographic separation enforces trust distribution. The lack of audit trails or RBAC exacerbates this risk, as there’s no way to detect or limit insider actions, making a single breach catastrophic.

Description: The protocol’s current design does not explicitly implement sharding or parallelization (whitepaper Section 6.1 focuses on bandwidth optimization). However, the protocol does not preclude parallelization, suggesting potential for future scalability improvements.

Evaluation: The workload of garbling and evaluation is distributed across the Garbler and Evaluators, which helps balance resource demands as user demand grows, though the lack of explicit parallelization mechanisms within each role may still limit computational throughput for large-scale operations. The protocol leverages the Half Gates scheme (Appendix A) for gate optimization reportedly offering the best performance for privacy-preserving EVM-compatible MPC to date, as per the client’s performance documentation from the go-ethereum audit. Specific implementation details, such as unoptimized loops in MAC generation (e.g., IT-MAC computations in Section 6.3) and memory copies (e.g., in garbled wire assignments), may still degrade performance, particularly for large circuits. Addressing these bottlenecks and incorporating parallelization could further enhance scalability and efficiency for broader adoption.

According to the COTI team, they have introduced changes to address operational and architectural risks identified in the initial audit, particularly those related to trust concentration and single-entity control. They state that node management has been transitioned to a distributed model to reduce single points of failure and to incorporate redundancy as recommended by Soda Labs. The team mentioned that, during earlier pre-mainnet deployments, components such as the Garbler, Evaluators, and KMS were operated by a single entity for development and testing purposes. As stated by the team this is no longer the case in the current production environment. They also indicate plans to continue decentralizing operations by separating responsibilities among independent parties, expanding redundancy, and improving monitoring.

Findings

Code
Title
Status
Severity
F-2025-9152Weak Randomness, Potential Buffer Overflow in Commons::generateDeviceRandomBytes
fixed

Critical
F-2025-8886Failure to Enforce Minimum Entropy Requirements
fixed

Critical
F-2025-8671Insufficient File Path Validation in writeToFile and readVectorFromFile Functions, Exposing to Directory Traversal Attacks
fixed

Critical
F-2025-9195Exposure of Internal State through Raw Pointers
fixed

High
F-2025-9174Incomplete Cleanup in Destructor
fixed

High
F-2025-9173Resource Leak in setServerAddress Function
fixed

High
F-2025-9031Potential Memory Leak in GarblerServer
fixed

High
F-2025-8970Unsafe Destructor Implementation in GCManager
fixed

High
F-2025-8968Unsafe Exception Handling in GCManager::refillCapacities
fixed

High
F-2025-8951Non Atomic And Non Join Safety In Destructor
fixed

High
1-10 of 55 findings

Findings like these can secure your blockchain.

Appendix 1. Severity Definitions

Severity

Description

Critical
Vulnerabilities that can lead to a complete breakdown of the blockchain network's security, privacy, integrity, or availability fall under this category. They can disrupt the consensus mechanism, enabling a malicious entity to take control of the majority of nodes or facilitate 51% attacks. In addition, issues that could lead to widespread crashing of nodes, leading to a complete breakdown or significant halt of the network, are also considered critical along with issues that can lead to a massive theft of assets. Immediate attention and mitigation are required.

High
High severity vulnerabilities are those that do not immediately risk the complete security or integrity of the network but can cause substantial harm. These are issues that could cause the crashing of several nodes, leading to temporary disruption of the network, or could manipulate the consensus mechanism to a certain extent, but not enough to execute a 51% attack. Partial breaches of privacy, unauthorized but limited access to sensitive information, and affecting the reliable execution of smart contracts also fall under this category.

Medium
Medium severity vulnerabilities could negatively affect the blockchain protocol but are usually not capable of causing catastrophic damage. These could include vulnerabilities that allow minor breaches of user privacy, can slow down transaction processing, or can lead to relatively small financial losses. It may be possible to exploit these vulnerabilities under specific circumstances, or they may require a high level of access to exploit effectively.

Low
Low severity vulnerabilities are minor flaws in the blockchain protocol that might not have a direct impact on security but could cause minor inefficiencies in transaction processing or slight delays in block propagation. They might include vulnerabilities that allow attackers to cause nuisance-level disruptions or are only exploitable under extremely rare and specific conditions. These vulnerabilities should be corrected but do not represent an immediate threat to the system.
  • Severity

    Critical

    Description

    Vulnerabilities that can lead to a complete breakdown of the blockchain network's security, privacy, integrity, or availability fall under this category. They can disrupt the consensus mechanism, enabling a malicious entity to take control of the majority of nodes or facilitate 51% attacks. In addition, issues that could lead to widespread crashing of nodes, leading to a complete breakdown or significant halt of the network, are also considered critical along with issues that can lead to a massive theft of assets. Immediate attention and mitigation are required.

    Severity

    High

    Description

    High severity vulnerabilities are those that do not immediately risk the complete security or integrity of the network but can cause substantial harm. These are issues that could cause the crashing of several nodes, leading to temporary disruption of the network, or could manipulate the consensus mechanism to a certain extent, but not enough to execute a 51% attack. Partial breaches of privacy, unauthorized but limited access to sensitive information, and affecting the reliable execution of smart contracts also fall under this category.

    Severity

    Medium

    Description

    Medium severity vulnerabilities could negatively affect the blockchain protocol but are usually not capable of causing catastrophic damage. These could include vulnerabilities that allow minor breaches of user privacy, can slow down transaction processing, or can lead to relatively small financial losses. It may be possible to exploit these vulnerabilities under specific circumstances, or they may require a high level of access to exploit effectively.

    Severity

    Low

    Description

    Low severity vulnerabilities are minor flaws in the blockchain protocol that might not have a direct impact on security but could cause minor inefficiencies in transaction processing or slight delays in block propagation. They might include vulnerabilities that allow attackers to cause nuisance-level disruptions or are only exploitable under extremely rare and specific conditions. These vulnerabilities should be corrected but do not represent an immediate threat to the system.

Appendix 2. Scope

The scope of the project includes the following components from the provided repository:

Scope Details

Repositoryhttps://github.com/soda-mpc/soda-mpc
Commit7fb3a27404df5720bf557eca2f0e19cd56081458

The remediation check has been conducted based on commit hash 649eb99 , which reflects the status of each issue following this process. It is important to acknowledge that this commit may include changes made subsequent to the initial review commit, which were not part of the audit assessment.

Assets in Scope

lib - lib
opcodesTranslator - opcodesTranslator
Protocol for Two Evaluators - Protocol for Two Evaluators
RPC - RPC

Disclaimer