Anoma Q4 2025 - RISC Zero RM & EVM Protocol Adapter Audit Final Report v2

Security Audit Report

Anoma Q4 2025: RISC Zero RM & EVM Protocol Adapter

Authors: Manuel Bravo, Ivan Gavran, Last Revised: Aleksandar Stojanovic, 24.11.2025 Carlos Rodriguez Anoma Q4 2025 Security Audit Report

Contents Audit Overview 1 The Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Scope of this report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Audit plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Audit Dashboard 3 Target Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Engagement Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Severity Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

System Overview 5 arm: Anoma Resource Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

EVM protocol adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Threat Model 9

Definitions 9 Property ARM-01: The RM implements both the ARM and the shielded specifications correctly (minus the documented discrepancies) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Property ARM-02: Only valid transactions pass verification . . . . . . . . . . . . . . . . . . . . . . . . . 11 Property ARM-03: If a transaction is valid, then it passes verification . . . . . . . . . . . . . . . 13 Property ARM-04: The integration of risc0 follows best practices at the host-side code. . . 14 Property ARM-05: The aggregation-proof guest code follows best practices . . . . . . . . 15 Property ARM-06: The encryption module is secure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Property ARM-07: The authorization module is secure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Property ARM-08: The action Merkle tree implementation is safe . . . . . . . . . . . . . . . . . . . 19 Property EPA-01: The adapter implements the protocol adapter specification correctly. . . 21 Property EPA-02: Type definitions and methods of the proving systems match those defined in the arm-risc0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Property EPA-03: Only valid transactions are executed successfully . . . . . . . . . . . . . . . . 29 Property EPA-04: Assume that the risc0 verifier is available and the adapter has not been paused. If a transaction is valid, it is then executed successfully. . . . . . . . . . . . . . . 31

Property EPA-05: The emergency stop feature is implemented correctly . . . . . . . . . . . . 32 Property EPA-06: Given a transaction that passes verification, the commitments of the transaction’s created resources are added to the commitment accumulator. . . . . . . . . 33 Property EPA-07: Given a transaction that passes verification, the nullifiers of the transaction’s consumed resources are revealed, i.e., added to the nullifier set. . . . . . 34 Property EPA-08: The variable-size Merkle Tree implementation is safe . . . . . . . . . . . . 34 Property EPA-09: Standard Solidity practices are followed . . . . . . . . . . . . . . . . . . . . . . . . . 36 Property EPA-10: The ecAdd function implementation is safe, as well as its usage . . 39

Findings 42 The transaction verification function does not check for double-spending . . . . . . . . . . . 44 The transaction verification function does not check that compliance units partition an action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Missing validation of input points to ensure coordinate bounds and curve membership. . . 46 No automatic memory zeroing of sensitive cryptographic data . . . . . . . . . . . . . . . . . . . . . . 49 The encryption module requires nonces to be computed by applications . . . . . . . . . . . . 52 Missing checks of logic app_data size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 When reserving commitment bytes, some fields treated as a wrong type . . . . . . . . . . . 54 Lack of domain separation in authorization signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Lack of domain separation in Merkle tree implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Missing identity point validation in ECDH key exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Invalid root and Merkle path for empty action trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Empty Merkle paths provide no cryptographic authentication . . . . . . . . . . . . . . . . . . . . . . . 71 Inefficient Merkle tree depth computation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Miscellaneous code improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Feedback on specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Appendix: Testing of ecAdd 82

Appendix: Review of PRs 90

Appendix: Vulnerability Classification 92

Disclaimer 96

Audit Overview

The Project In October 2025, Anoma engaged with Informal Systems to conduct a security audit of the Anoma Resource Machine (ARM) protocol, its implementation with RISC Zero and the EVM protocol adapter.

The ARM is used to create, compose, and verify transactions. Anoma users submit their intents to the intent gossip network in the form of unbalanced ARM transactions, which are received and processed by solvers that output balanced ARM transactions. Balanced transactions are routed to settlement protocol adapters (such as the EVM protocol adapter for EVM-compatible chains) that validate and coordinate execution of resource machine transactions.

Scope of this report The audit focused on evaluating the coherence and consistency of the state architecture protocol (for resource machine and shielded resource machine) and the correctness and security properties of the ARM RISC Zero implementation and the EVM protocol adapter.

Audit plan The audit was conducted between October 13th, 2025 and October 31st, 2025 by the following personnel:

• Manuel Bravo • Ivan Gavran • Aleksandar Stojanovic • Carlos Rodriguez

Conclusions We praise the Anoma development team for the exceptional quality of their work on both the ARM RISC Zero implementation and the EVM protocol adapter. The codebases demonstrate strong cryp tographic expertise, thoughtful architectural decisions, and careful attention to security best practices. The well-structured code and comprehensive edge case handling reflect a mature approach to building complex zero-knowledge proof systems.

Our audit identified 15 findings with no critical or high severity issues. Two medium severity findings were discovered in the initial tag (v0.8.1): the transaction verification function lacked double-spending checks and didn’t validate that compliance units properly partition actions. Both were promptly resolved by the team in tag v0.8.2. Four low severity findings were identified: missing validation (before addition) of input points for elliptic curve membership, lack of automatic memory zeroing of

sensitive cryptographic data (which could leave private keys and intermediate values exposed in memory after use), the delegation of nonce computation to applications (which increases the risk of nonce reuse), and missing size validation of LogicVerifierInputs app_data, which could bloat the public output of the aggregation circuit.

Nine informational findings provide recommendations for code quality improvements, including en hanced specification documentation to address discrepancies between specification and implemen tation, domain separation improvements for authorization signatures and Merkle tree construction, and various refinements to Merkle tree handling and general code quality. The development team’s rapid resolution of medium severity issues and engagement throughout the audit process reinforces confidence in the project’s strong security posture.

Audit Dashboard

Target Summary • Type: Protocol and implementation • Platform: Rust, Solidity • Artifacts: ‣ Specs for resource machine and shielded resource machine. ‣ EVM Protocol Adapter (tag v1.0.0-rc.3) – All files in contracts/src except those in the folder forwarders – Additionally, the ecAdd function as used in Delta.sol file from the @elliptic-curve-solidity library ‣ ARM Risc0 (tag v0.8.2) – The folder arm, but excluding the files listed below • rustler_util.rs • tests.rs • test_logic.rs • evm.rs • hash.rs • aggregation/sequential.rs • aggregation/pcd.rs – arm-circuits/batch-aggregation folder

Engagement Summary • Dates: October 13th, 2025 → October 31st, 2025 • Method: Threat modelling, manual code review, testing

Severity Summary Finding Severity Number

Critical 0

High 0

Medium 2

Low 4

Informational 9

Total 15

Table 1: Identified Security Findings

System Overview In the Anoma Protocol, users send information about the desired state change (intent) to solvers. By analyzing the desired outcomes, solvers determine the optimal execution paths, and the resource machine generates transactions with the necessary cryptographic proofs to validate the proposed resource transitions. The protocol adapter receives these fully-formed transactions and serves as the authoritative source of truth for resource state.

Following, we describe in some detail the two components in scope: the ARM risc0 resource machine and the EVM protocol adapter. The definitions and properties in the threat model define more precisely the desired behavior of the components under scope.

arm: Anoma Resource Machine The ARM is used to create, compose, and verify transactions. It is stateless and run by every node that processes transactions. Anoma users submit their intents to the intent gossip network in the form of unbalanced ARM transactions with metadata, which are received and processed by solvers that output balanced ARM transactions. These transactions are then ordered and finally sent to the executor node, which verifies and executes the transactions in the determined order, updating the global state.

The resource machine generates three distinct types of proofs, each serving a specific purpose in the overall security and privacy model.

• Compliance proofs demonstrate that resource consumption and creation follow the fundamental protocol rules. These proofs verify that consumed resources actually exist in the commitment tree, that the user possesses the correct nullifier keys, that new resource commitments are properly formed, and that the balance changes are correctly computed. • Logic proofs validate application-specific constraints for each resource involved in the transaction. Unlike compliance proofs, which focus on protocol-level rules, logic proofs ensure that resources behave according to their specific application logic. • Delta proofs provide the critical guarantee that transactions maintain overall balance and conserva tion of value. In the abstract design, these proofs demonstrate that the sum of all resource changes across the entire transaction equals a specified expected value. For the current shielded imple mentation, this expected value is always zero, preventing any net value creation or destruction. The delta proof operates at the transaction level, aggregating the balance impacts of all individual resource transitions and proving that the net effect maintains system invariants according to the expected balance constraint.

Proof Type Purpose Scope What It Vali dates

Compliance Proof Protocol-level valida Compliance unit “Is this state transition tion allowed?”

Resource Logic Application-level vali Action “Does this action sat Proof dation isfy the rules specified by this resource?”

Delta Proof Balance validation Entire transaction “Is this transaction bal anced?”

Components architecture

Figure 2: Components diagram

EVM protocol adapter The EVM protocol adapter serves as a bridge, bringing Anoma’s privacy-preserving, intent-centric resource machine model to the Ethereum ecosystem. The primary functionality revolves around executing resource machine transactions on Ethereum. The protocol adapter validates resource transitions through zero-knowledge proofs and coordinates the execution of corresponding opera tions on other smart contracts.

The adapter maintains two critical state structures: a commitment accumulator implemented as a Merkle tree that stores commitments to all created resources, and a nullifier set that prevents double- spending by tracking consumed resources. This dual-state system ensures both the availability of resources for future consumption and the prevention of replay attacks or double-spending scenarios.

The forwarder system enables interaction with other smart contracts. Forwarders act as trusted inter mediaries that receive calls from the protocol adapter, validate them against resource specifications, and forward them to target contracts.

Threat Model

Definitions A transaction is valid if:

• It is balanced: for any given resource kind, the transaction consumes the same amount that it creates, i.e., it includes a valid delta proof. • It satisfies the RM constraints, i.e., it includes a valid compliance proof for each compliance unit. • It satisfies the application constraints on resource consumption and creation, i.e., it includes a valid resource logic proof for each resource. • All external calls produce the expected output. • There are no duplicate resources in the transaction, i.e., the transaction attempts to consume or create a resource at most once • For any non-ephemeral resource that it is consumed in the transaction, its commitment is in the accumulator by the time the transaction is verified • No consumed resource in the transaction has been consumed by a previously executed trans action. • For any given created resource, its commitment is not in the accumulator by the time the transaction is verified.

We say that a transaction has been successfully executed when a TransactionExecuted event is emitted after the transaction’s execution, i.e. it passes all verification checks.

Property ARM-01: The RM implements both the ARM and the shielded specifications correctly (mi nus the documented discrepancies) Findings: When reserving commitment bytes, some fields treated as a wrong type (https:// www.notion.so/When-reserving-commitment-bytes-some-fields-treated-as-a-wrong-type-294d212b 18c38006b261c865f137fae0?pvs=21)

It implements all primitive types correctly
The primitive types (Set, Map) do not seem to be relevant (are they outdated documentation?). Even where there is a pointer to where a primitive type is used (such as Map in Action’s logic_verifier_inputs, this is not reflected in the code, where a vector is used.
For the fixed types:
NullifierKey is of type Vec<u8>

Nonce is indeed a fixed size, 32 bytes, e.g. here
NullifierKeyCommitment is indeed a fixed size, a struct structconsisting of only Digest (of 32 bytes)
The Arithmetic interface does not explicitly exist in the code. The instances of the interface, e.g., Resource.quantity field is of type u128, which satisfies the requirements of Arithmetic and fixed type.
It implements all main data structures correctly, including their computable components
Commitment: Commitment is calculated as a hash of all fields of Resource, with rand_seed taken into a separate, inner hash domain (combined with separators and nonce), as calculated in the function rcm. To the best of our understanding, this follows good cryptographic practices. There is a non-consequential finding “When reserving commitment bytes, some fields treated as a wrong type”, associated with inspection of the commitment.
Nullifier: Similar to commitment, it hashes the private key, nonce, commitment, and puts the rand_seed inside the psi function. The separator differs from the one for calculating commitment.
Kind: The implementation follows the spec, except that it hashes (logic_ref, label_ref) , as compared to the spec saying it should hash (label_ref, logic_ref). This does not constitute a problem inside the codebase, but may be confusing for somebody inspecting the values based on the spec.
Delta
compliance unit: implemented as in spec, as a difference between consumed resources and created resources, with added an independent generator point multiplied by a random scalar. One inconsequential difference to the spec: The spec is using old terminology on input and output resources, instead of consumed and created. Even with those, it has the signs the other way round than in the code (all of that shouldn’t matter since the check is for 0).
action: the implementation follows the spec
transaction: the implementation follows the spec
It implements all interfaces faithfully
The spec defines the interface for ProvingSystem.prove to accept three arguments, ProvingKey, Instance, Witness. However, the implementation follows RISC Zero’s interfaces and accepts only two arguments proving_key and witness, while instance is returned (since it is a part of the guest computation). It may be useful to note that difference in the spec, even if in a footnote.
The aggregation interface is faithfully implemented (though it goes from a vector of proofs into a proof, slightly differing from the spec).

Threats • Some required primitive types are not supported.

• The implementation of data structures differs from the specification, e.g, some fields are missing.

• The implementation of some methods is incorrect or missing according to the specification.

Property ARM-02: Only valid transactions pass ver ification Findings: The transaction verification function does not check for double-spending (https:// www.notion.so/The-transaction-verification-function-does-not-check-for-double-spending-29cd212b 18c380ab9544dc25000d9ba0?pvs=21), The transaction verification function does not check that compliance units partition an action (https://www.notion.so/The-transaction-verification- function-does-not-check-that-compliance-units-partition-an-action-29cd212b18c380f0a32ed161524 f89a7?pvs=21)

Threats • A transaction passes verification without verifying all compliance proofs.

The threat doesn’t hold.

Excerpt (19999 of 157320 characters). Read the whole page on informalsystems/audits ↗

← Back to Documentation