OneSig Phase 2 Audit

Summary

Type: Stablecoins
Timeline: May 28, 2025 → May 30, 2025
Languages: Solidity

Findings
Total issues: 5 (0 resolved)
Critical: 0 (0 resolved)
High: 0 (0 resolved)
Medium: 0 (0 resolved)
Low: 0 (0 resolved)

Notes & Additional Information
5 notes raised (0 resolved)

Scope

OpenZeppelin audited the LayerZero-Labs/onesig repository at commit a5ed4b2.

In scope were the following files:

 packages/onesig-evm
└── contracts
    ├── MultiSig.sol
    └── OneSig.sol

System Overview

This audit covers the LayerZero implementation of the OneSig protocol, which builds upon the previous codebase audited under the Everdawn-Labs/OneSig repository. The current version only introduces minor improvements and refinements, with no significant changes to the overall architecture or core logic.

As in the previous version, the system enables secure cross-chain execution of pre-authorized transactions. A proposer can send a batch of transactions to an off-chain server for review. A group of designated signers collectively approves the batch, producing a Merkle root representing the authorized set. On-chain, an executor can execute transactions from the batch by submitting a valid Merkle proof along with sufficient signatures.

Each transaction batch is uniquely identified using a nonce and a deployment-specific identifier to enforce ordering and prevent replay. This model continues to be well-suited for scalable, multi-chain deployments where frequent updates are required, such as in the LayerZero ecosystem.

Security Model and Trust Assumptions

The same assumptions outlined in the previous audit apply to this version of the system. However, this audit is limited to the on-chain components and does not include the off-chain infrastructure responsible for constructing the Merkle tree. It is assumed that this off-chain system correctly implements the double-hashing and encoding logic as defined in the encodeLeaf function.

All configured signers are assumed to be trustworthy, and the signature threshold is expected to be set according to best practices. More specifically, the signature threshold is high enough relative to the total number of signers to prevent compromise.

The system allows signatures to be reused across different chains due to the use of a static EIP-712 domain. This behavior is acknowledged and accepted by the project team as intentional, based on the protocol's documented design choices.

Privileged Roles

The set of privileged roles remains consistent with the previous audit. The designated signers are responsible for authorizing transaction batches by signing Merkle roots off-chain. They also have the authority to update the signer set and the contract's seed value, both of which are integral to the signature verification process. These privileged operations, like transaction execution, require the same threshold of signatures and cannot be performed unilaterally by any individual signer.

Acknowledged Issues

The LayerZero Labs team acknowledges a number of previously reported issues raised by OpenZeppelin and other independent audit firms. These issues have been documented in past audits and can be found in the appendix.

Notes & Additional Information

State Variable Visibility Not Explicitly Declared

Within MultiSig.sol, the SIGNATURE_LENGTH state variable lacks an explicitly declared visibility.

For improved code clarity, consider always explicitly declaring the visibility of state variables, even when the default visibility matches the intended visibility.

Update: Acknowledged, not resolved.

Incomplete Docstring

Within OneSig.sol, the SeedSet event has an incomplete docstring. More specifically, the seed parameter is not documented.

Consider thoroughly documenting all functions/events (and their parameters or return values) that are part of a contract's public API. When writing docstrings, consider following the Ethereum Natural Specification Format (NatSpec).

Update: Acknowledged, not resolved.

Possible Duplicate Event Emissions

Some setter functions in the codebase emit events without verifying whether the new value differs from the current one. This can result in duplicate event emissions when the same value is set repeatedly, causing the event to be emitted even though no actual change has occurred.

While the functions are permissioned and not prone to external spamming, redundant event emissions can still lead to confusion or inefficiencies for off-chain clients or indexers that rely on event data to detect meaningful state changes.

Throughout the codebase, multiple instances of potential duplicate event emissions were identified:

• The _setThreshold sets the threshold and emits an event without checking if the value has changed.
• The _setSeed sets the seed and emits an event without checking if the value has changed.

Consider adding a check statement to revert the transaction if the value being set is identical to the existing value.

Update: Acknowledged, not resolved.

Misleading Documentation

The internal documentation of the verifyNSignatures function in MultiSig.sol states that the function reverts if the number of signatures does not match the threshold, suggesting that an exact match is required. However, the implementation only checks that the number of signatures is not less than the threshold.

This means that any number of signatures equal to or greater than the threshold is accepted, which does not align with the stated behavior. This mismatch may lead developers or auditors to assume that the function enforces stricter validation than it actually does. While this does not introduce a direct vulnerability, it can cause confusion or unintended assumptions about how the signature verification works.

To improve code clarity and prevent misunderstanding, consider updating the documentation to clarify that the function accepts at least the threshold number of signatures. Alternatively, consider modifying the logic to require an exact match.

Update: Acknowledged, not resolved.

Ambiguous Error Handling

The verifyNSignatures function in MultiSig.sol reverts with SignatureError for two distinct failure cases: when the total signature data size is not a multiple of 65 bytes, and when the number of extracted signatures is less than the required threshold. These are logically separate conditions but are reported using the same error. Using the same error for both scenarios can make debugging more difficult and reduce clarity for developers and off-chain consumers, who may not be able to easily distinguish which condition caused the revert.

Consider introducing a separate error for each case to clearly signal the specific reason for failure. Doing so will help improve error traceability and diagnosis.

Update: Acknowledged, not resolved.

Conclusion

The LayerZero implementation of the OneSig protocol maintains the original design principles while introducing minor refinements for improved clarity and usability. This version preserves the core architecture, including off-chain batching, multi-signer authorization, and on-chain Merkle proof-based execution.

The system continues to provide a secure and scalable solution for cross-chain transaction execution, with strong protections against replay and misordering through the use of nonces and chain-specific identifiers. The overall design remains appropriate for high-throughput, multi-chain environments such as those enabled by LayerZero.

The codebase remains clean and well-structured, with no critical issues identified. The audit findings were limited to note-level observations and suggestions aimed at improving code clarity and developer experience.

Appendix

Acknowledged Issues