2025-07-18 Neutron-Timewave Q2 2025 Valence Protocol Audit Report Final

Security Audit Report

NEUTRON & TIMEWAVE Q2 2025: VALENCE PROTOCOL

Authors: Last Revised Aleksandar Ignjatijevic, Carlos Ro- 2025/07/18 driguez Neutron & Timewave Q2 2025 Valence Protocol

Contents Audit overview 2 The project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Scope of this report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Audit plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

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

System Overview 5 Core components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Execution flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Threat Model 9 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Account system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authorization system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Processor system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 OneWayVault.sol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Findings 24 target lacks zero-check in Account execute() function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Unexpected payable functions in OneWayVault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Lack of proper validation for withdraw request receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Malicious strategist could manipulate redemption rate to its own advantage . . . . . . . . . . . . . . . . . . . 29 Unpausing vault does not make it usable in the event of stale rate . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Unexpected payable function in LiteProcessor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Missing validation of redemption rate in contract initialisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Stale rate auto-pause mechanism wastes gas for unlucky users . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Malicious users can spam withdrawals with small amounts to overwhelm destination . . . . . . . . . . . . . 35 VerificationGateway might be zero address when adding/removing registries . . . . . . . . . . . . . . . . . . 36 Requests will be piling up and take up contract storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Differently sized arrays will cause panic in execute function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Processor functions are not protected by nonReentrant modifier . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Deposit and mint functions are not protected by nonReentrant modifier . . . . . . . . . . . . . . . . . . . . . . 40 Using msgSender function in contracts that do not support meta-transactions . . . . . . . . . . . . . . . . . 41 Miscellaneous code improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Recommendations for gas optimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Appendix: Vulnerability classification 45

Disclaimer 48

Audit overview The project In June 2025, Timewave engaged Informal Systems ↗ to to conduct a security audit of several competes of their Valence Protocol, a trust-minimized cross-chain execution environment.

Scope of this report The audit focused on evaluating the correctness and security properties of:

● Several sub-systems of the Valence Protocol: – Account system – Authorization system – Processor system ● A ERC4626 tokenized one-way vault contract that enables deposits on one chain with withdrawal requests processed on another domain/chain.

Audit plan The audit was conducted between June 11th, 2025 and July 8th, 2025 by the following personnel:

● Aleksandar Ignatijevic ● Carlos Rodriguez

Conclusions The Valence Protocol demonstrates exceptional architectural design and implementation quality, showcasing a sophisticated approach to trust-minimized cross-chain DeFi operations. The codebase exhibits strong engineering principles with well-structured modular components including the Account system, Authorization framework, Processor system, and innovative One-Way Vault implementation. The protocol’s integration of zero-knowledge proof verification through the SP1VerificationGateway represents cutting-edge cryptographic security practices, while the comprehensive separation of concerns between different system components demonstrates mature software architecture. The implementation of ERC4626 standards in the vault system and the thoughtful design of atomic and non-atomic execution models in the processor system reflect deep understanding of DeFi security requirements and operational flexibility needs. Our audit identified two high-severity issues were discovered: the absence of zero-address validation in the Account execute() function’s _target parameter, which could lead to failed transactions and potential fund locks, and unexpected payable functions in the OneWayVault contract that could result in unintended fund loss scenarios. The audit also identified 5 medium-severity and 5 low-severity issues that, while not immediately exploitable, could impact protocol operations and user experience, along with 5 informational findings that provide recommendations for enhanced security practices and gas optimization opportunities.

Audit Dashboard Target Summary ● Type: Protocol and implementation

● Platform: Solidity

Engagement Summary ● Dates: June 11th, 2025 → July 8th, 2025 ● Method: Manual code review, Foundry testing, Quint modelling ↗

Severity Summary

Finding Severity Number

Critical 0

Finding Severity Number

High 2 Medium 5 Low 5 Informational 5 Total 17

System Overview The Valence Protocol is a unified development environment for trust-minimized cross-chain DeFi applications, enabling developers to build Valence Programs. These programs simplify cross-chain operations, offering extensi- bility and rapid deployment without requiring complex smart contracts or multisig setups.

Core components In the next sections we go over the core architecture components of the protocol under scope, which are coloured green in the following diagram:

Figure 1: Architecture diagram

Account system The account system in the Valence Protocol is designed to securely manage funds and enable controlled execution of operations through approved libraries. At its core is the Account.sol contract, which serves as an abstract base for account management. This contract introduces a mechanism for approving specific library addresses, ensuring that only trusted libraries can interact with the account’s funds or execute operations. Additionally, Account.sol implements ownership control, allowing the account owner to manage approvals and execute privileged actions. Building on this foundation, BaseAccount.sol provides a concrete implementation of the abstract Account.sol. It inherits the functionality of library approval and ownership control, making it ready for deployment and integration into the Valence Protocol. These account contracts act as secure containers for funds and execution logic.

Authorization & access control This system enables secure and trust-minimized interactions within the Valence Protocol. The Authorization.sol contract serves as the entry point for managing permissions and submitting ZK proofs for verification. It supports two types of authorizations: Standard authorizations, which rely on address-based permissions, and ZK authorizations, which validate permissions using cryptographic proofs. Standard authorizations allow specific addresses to interact with the system, providing access control for known entities such as administrators or trusted users. ZK authorizations validate permissions through cryptographic

proofs generated off-chain by the ZK Coprocessor Service and verified on-chain. The Authorization.sol contract integrates with the VerificationGateway.sol and its specialized implementation, SP1VerificationGateway.sol, to perform cryptographic verification of ZK proofs. These gateways store verification keys for registered guest programs and use them to validate proofs submitted by authorized entities. Once a proof is verified, the Authorization.sol contract dispatches the associated processorMessage to the Processor contract for execution, ensuring that only authenticated and authorized actions are performed.

Processor system This system is responsible for executing program subroutines and handling cross-chain messages. It consists of three main contracts: ProcessorBase.sol, LiteProcessor.sol, and Processor.sol. These contracts enable flexible and efficient execution of subroutines. At the core is ProcessorBase.sol, which provides shared functionality for processors, including message handling and execution logic. It supports atomic and non-atomic execution models, allowing flexibility in how subroutines are processed. Atomic execution ensures that either all functions within a subroutine succeed or none are executed, providing strong guarantees for critical operations. Non-atomic execution, on the other hand, allows partial completion of subroutines, with individual retry logic applied to failed functions. Building on this foundation, LiteProcessor.sol offers a lightweight implementation designed for immediate execution of subroutines without queuing. The Processor system integrates seamlessly with the Authorization contract, which manages the addition of message batches to the queues and controls the processor’s state.

Verification system This system enables the validation of zero-knowledge (ZK) proofs and it consists of two main contracts: VerificationGateway.sol and its specialized implementation, SP1VerificationGateway.sol. At its core, VerificationGateway.sol serves as an abstract base for verification gateways, providing foundational functionality for managing verification keys (VKs) and performing proof validation. It stores VKs associated with specific registry IDs, which are used to verify proofs submitted by authorized entities. The contract also supports up- dates to the verifier address and domain verification key. Building on this foundation, SP1VerificationGateway.sol implements the verification logic specific to the SP1 zkVM. It integrates with the SP1 verifier to validate proofs against the stored VKs. This works in tandem with the Authorization contract, which delegates proof validation to the VerificationGateway.sol. Upon successful verification, the Authorization contract proceeds with executing the associated processor message.

One way vault The OneWayVault.sol contract implements the ERC4626 tokenized vault standard to enable deposits and with- drawals of assets. It supports one-way withdrawal requests, allowing assets deposited on one chain to be withdrawn on another. The contract also includes mechanisms for fee distribution, ensuring that both the platform and strategist receive their respective shares of collected fees. To enhance security and operational control, the vault includes pausability features, allowing the owner or strategist to pause operations in case of emergencies or stale redemption rates. Additionally, the contract enforces deposit caps to prevent excessive asset accumulation.

Execution flow The following diagram shows the complete interaction patterns within the Valence Protocol, showing how users interact with the system through both standard and ZK authorization flows, as well as vault operations for cross-

chain asset management.

Figure 2: Execution flow

Assumptions In order to understand the system we had several assumptions:

● Processor’s authorized addresses - our assumption is that the authorized addresses are addresses of authorized contracts that are to be trusted. However, since they will be calling external contracts and perform certain logic, we still left some room for potential bugs in the code that could lead to authorized addresses performing certain actions in ways that could lead to bugs. ● Strategist - our assumption is that the strategist is a trusted party, as well as the vault owner. However, there are

still ways to gain control over trusted party’s keys or to act maliciously so we left some room for that. ● Approved libraries - approved libraries are a part of accounting system and our assumption is that they are

trusted by the owner of an account. However, since those libraries are out of our scope, we cannot rule out bugs

in that code that can lead to bugs in account system that we are inspecting.

Threat Model General ● Property GEN-01: Events are emitted for all state changes Conclusion: The contracts already emit events on several state changes (pause/unpause, when a withdrawal request is created, when the vault configuration is updated, etc), however there are other state changes that could benefit from emitting an event, and we list some recommendatiosn in finding “Miscellaneous code improvements”.

● Property GEN-02: All functions are marked with appropriate visibility Conclusion: Function visibility appears appropriate for almost all functions. Some of the functions that are marked as public are not used internally. We have mentioned that in finding “Miscellaneous code improvements”.

● Property GEN-03: Checks-Effects-Interactions pattern is applied consistently Conclusion: Overall the contracts adhere to the CEI pattern consistently and we would only recommend to apply it in function sendProcessorMessage() of Authorization, where the executionId is incremented ↗ after the external call to processor.execute(message).

● Property GEN-04: Division operations are protected against zero denominators Conclusion: As reported in finding “Missing validation of redemption rate in contract initialisation”, we recommend checking that input parameter startingRate ↗ is not zero.

● Property GEN-05: Rounding errors are not accumulated in ways that can be exploited Conclusion: We haven’t identified ways in which rounding error accumulation could be exploited.

Account system Definitions Approved libraries: Mapping to track approved library addresses. Maps library address to approval status (true = approved, false = not approved).

Properties ● Property ACC_AUTH-01: Admin operations can only be performed by contract owner

– Threat a: Other address than contract owner can add or remove approved libraries Conclusion: The property holds. Due to placed onlyOwner modifier, only owner is able to interact with approveLibrary() and removeLibrary() functions.

● Property ACC_EXEC-01: Execute function can only be called by owner or by approved libraries

– Threat a: Malicious address can call execute and drain the contract Conclusion: The property holds. Check placed here ↗ ensures that only approved libraries and contract owner can call execute().

– Threat b: Error data is not returned in the proper way Conclusion: During the audit, development team has run into an issue around reverting and returning returnData if .call returned no data. Development team fixed this issue in PR#404 ↗.

● Property ACC_APL-01: Once library is removed it cannot call execute function Conclusion: The property holds. Only owner can remove the library and the state is updated straight away by deleting entry from the map which will set the value to false.

● Property ACC_NFT-01: Contract has to be able to receive ERC721 Conclusion: The property holds. Account implements IERC721Receiver interface and implements onERC721Received function which returns this.onERC721Received.selector therefore ensuring that ERC721 can be transferred to the account.

● Property ACC_ETHER-01: Contract has to be able to receive ether needed for approved libraries Conclusion: The property holds. The contract implements receive() external payable {} which allows con- tract to receive native tokens.

Authorization system Definitions Guest program: A user-developed application that runs on the ZK coprocessor, consisting of a controller (a Wasm-compiled Rust program) and a ZK circuit. Registry: A unique identifier (uint64) that:

● Links a specific guest program to its verification key ● Controls which addresses can submit proofs for that program ● Acts as an access control mechanism in the Authorization contract

● Each registry has its own verification key and set of authorized users

ZK coprocessor: An off-chain service responsible for running and managing guest programs in a secure and isolated environment. By leveraging an underlying zkVM, such as SP1, the service generates cryptographic proofs that attest to the correctness of program execution. Once proofs are generated, the service makes them readily available for submission to the blockchain. Coprocessor root hash: The first 32 bytes of a ZK message that represent a cryptographic commitment to the current state of the ZK coprocessor. Domain: A specific blockchain environment defined by: 1) The blockchain name (e.g., Neutron, Osmosis) 2) The execution environment (e.g., CosmWasm, EVM) 3) The bridge type used for cross-chain communication. Domain proof: A cryptographic proof of the state of a specific domain, stored in the SMT of the ZK coprocessor. It is used to ensure that the state of the domain used in the computation of the

Excerpt (19996 of 105113 characters). Read the whole page on informalsystems/audits ↗

← Back to Documentation