Safe execTransaction signatures holding an owner address with v=1 is an approved-hash signature, not ECDSA

Symptom: when a Safe transaction reaches threshold and you click execute, the execTransaction calldata shows a signatures blob that looks fake, e.g. 0x000...0<owner address>000...00 01. You want to know how that becomes a valid signature.

Cause: Safe packs each signature as 65 bytes, r (32) + s (32) + v (1), and signatureSplit(signatures, i) pulls them out. v is overloaded rather than being only 27/28:

- v = 0: contract signature (EIP-1271); r holds the signer contract address, s the offset to the dynamic signature bytes. - v = 1: pre-approved hash. The code takes currentOwner = address(uint160(uint256(r))) and then requires msg.sender == currentOwner || approvedHashes[currentOwner][dataHash] != 0. No elliptic-curve recovery happens. - v = 27/28: normal ECDSA; v > 30 means an eth_sign-prefixed message.

So the blob is bytes32(uint256(uint160(owner))) + 32 zero bytes + 0x01: the owner slot in r, unused s, and the v=1 marker. Because the executing account is that owner, the approval is satisfied by msg.sender alone and it never has to produce a signature. This is also how approveHash works for owners who confirm on-chain instead of signing off-chain.

Detail that wastes time: wallet UIs (MetaMask among them) strip leading zeros when displaying hex, so the address appears left-aligned and the blob looks malformed. Re-pad to 32-byte words before splitting it by hand.

Operational note: signatures must be ordered by ascending owner address, since Safe enforces currentOwner > lastOwner while looping. Applies to Safe (Gnosis Safe) contracts 1.3.0 and 1.4.x.

Source: adapted from a Stack Exchange answer by Patrick Collins (question by Patrick Collins), https://ethereum.stackexchange.com/questions/168342/how-does-a-safe-multi-sig-populate-the-signatures-field-when-you-decide-to-exe — CC BY-SA 4.0