OneSig Deployment

The verifyNSignatures function checks whether the provided signatures are sufficient to meet the multisig threshold. However, the function reverts if any of the provided signatures is invalid, even when the remaining valid signatures are enough to satisfy the threshold.

One of the signers in a multisig can intentionally provide an invalid signature, especially when the proposal conflicts with their personal interests. For example, in a 3-out-of-5 multisig, all five signers submit their offchain signatures to the executor, but one of them is deliberately invalid. When the executor attempts to execute the proposal, it reverts, despite the fact that the remaining four valid signatures should be sufficient. As a result, the executor must manually identify and remove the invalid signature, regenerate the calldata, and attempt execution again.

Instead of reverting on the first invalid signature, consider iterating through all provided signatures and counting the number of valid ones. Then, compare the count of valid signatures against the multisig threshold to determine whether the proposal is executable.

Alternatively, make sure the executor validates each signature off-chain before generating the calldata and ensures the function is called only with valid signatures.

OneSig performs double hashing on the Merkle leaf link, presumably to reduce the probability of hash collisions, as recommended in a previous audit report. (Page-4)

However, double hashing does not reduce the probability of collisions — in fact, it can slightly increase it. Consider this:

• If H(a) ≠ H(b), it's still possible that H(H(a)) == H(H(b)) due to a second-layer collision.
• If H(a) == H(b), then H(H(a)) == H(H(b)) definitely holds.

Thus, applying a hash function multiple times introduces no additional collision resistance and may slightly worsen it.

That said, double hashing can be helpful against second preimage attacks if the leaf might be exactly 64 bytes. But this is better addressed using domain separation, prefixing, or explicit encoding, which are standard cryptographic best practices. Furthermore, there is no way for the leaf encoding to be 64 bytes for one-sig as the base encoded data is 49 bytes and the Call object stores 64 bytes plus the arbitrary data itself.

There is no immediate risk posed by the current double hashing, so no change is strictly required. However, be aware that double hashing does not reduce collision probability.

OneSig introduces a feature enabling both permissioned and permissionless execution via executors, which can be added or removed using designated functions.

The intended security mechanism is to call removeExecutor when an executor is identified as malicious. However, a gap exists: once an executor is flagged for removal, it can still execute previously scheduled transactions until the removal transaction (based on nonce) is processed.

If the protocol attempts to submit a transaction with nonce + 1 to bypass this window, the malicious executor could front-run by executing the previously scheduled nonce + 1 transaction first — effectively griefing the removal attempt.

A similar parallel exists with setExecutorAllowed, where changing a flag from true to false does not immediately revoke the executor's ability to execute already queued transactions. A malicious executor could front-run the disabling call by executing transactions just before the update takes effect.

Be aware of this race condition. Even using front-run resistant RPCs may not guarantee protection, due to involvement of multi-chain scenarios where latency and ordering are less predictable.

If this scenario is considered a serious threat, consider introducing a separate transaction queue specifically for executors pending removal or permission revocation, to ensure immediate containment of their privileges.

Some networks may be incompatible with the OneSig EVM implementation for various reasons. Firstly, the Solidity version used in the OneSig contracts includes a version higher than 0.8.20 which uses PUSH0 as an opcode. Some networks such as Linea or Kava do not yet support PUSH0 and may therefore be incompatible with the OneSig contract without compiling specifically for their EVM compatibility.

For example:

cast call --rpc-url <RPC> --create 0x5f5c

Produces Error: server returned an error response: error code -32000: invalid opcode: PUSH0 for Linea and Error: server returned an error response: error code -32000: rpc error: code = Internal desc = invalid opcode: PUSH0 for Kava.

Furthermore, certain networks may lack support for ECDSA which is necessary for the OneSig contract, though no popular networks with this behavior have been identified.

Be aware of these requirements for compatibility.