Chosen validation mode lacks explicity

When a user of the Smart Account wants to authorize several actions for several chains, and only use one signature to do so, they set the "chosen authorization module address" to the address of a deployed MultichainECDSAValidator module. The module function validateUserOp() will call _verifySignature() with either the userOpHash or the extracted merkleTreeRoot as part of the input parameters. The decision for which parameters to pick is not explicitly chosen by the caller, but instead relies on the length of the signature data being exactly 65 or not. We believe that showing the intention more explicitly could be safer. If a Merkle signature is specially picked, it is possible to make it go to the non-Merkle code path, where unexpected return values, events, or errors could arise.

Explicit intentions also slightly future-proof the module. If the module is likely to be expanded further, a third differentiator will be required. If this new type cannot be differentiated by length alone, the module will need refactoring to include a new field or extra data. That breaks compatibility with existing contracts that interact with the module, which requires updates for users.

There is no vulnerability related to the current code pattern, but future expansions of the project can easily convert this implicit check into a dangerous mistake or break backward compatibility. A more explicit solution could be to include a signature type inside the signature itself.

Biconomy Labs stated,

We've decided to still go with the current approach without explicitly adding singlechain/multichain mode flag into some userOp data. Usually multichain mode has 65 bytes for ecdsa signature over the merkle root + some additional info (validUntil, validAfter, merkleRoot, merkleProof) so it will never be 65 bytes, but always more.