About signature verification by smart contract wallets (1271, 1654, 2126)

The need for smart contract wallet to be able to recognise signature as been identified a long time ago. Verification of EOA’s signature using ecrecover is now very common, as is allows protocole to partially move offchain, reduce gas cost, and increase scalability.

Smart contract based wallet, like Argent and Gnosis can very rarely interact with such systems.

Many proposal, with various names, have been drafted. The ERC1271/1654 family proposed a isValidSignature function, with various arguments, that would allow a smart contract to recognise signature made by its owners. THe most common variants are

isValidSignature(bytes data, bytes signature) returns (bytes4)
isValidSignature(bytes32 hash, bytes signature) returns (bytes4)

With various assumption about how the hash or data should be processed

There function are expected to return their own selector has a “magic value”.
The second option is less generic, but IMO is a better fit considering the bytes32 format correspond to ecrecover's supported format, and is standardised through ERC191 and ERC712

These 2 ERCs have been in draft for way to long!

More recently, @pedrouid proposed ERC2126, which (while I did not agree with the overall design) had the benefit to try and have things moving again. Unforunatelly, the corresponding PR was close due to inactivity so the ERC never made it EIP repo.

Argent implements (bytes32, bytes), Gnosis implements a version of (bytes,bytes) where the data is expected to signed using an ERC712 structure. I do believe that it is high time we move a proposal to final call, as having the various proposal stuck in “draft” prevents adoption.

I’d love to have the community opinion on that subject. Particularly that of ERC1271 & 1654 authors, and that of Wallet developpers.

@pedrouid @PhABC @frangio @shrugs @abandeali1 @izqui @catageek @pazams


Happy to make a PR to set ERC-1271 to final call again, with the isValidSignature(bytes32 hash, bytes signature) returns (bytes4) version. Need to look back as to why the last attempt never made it through.


the whole debate bytes32 vs bytes was an unfortunate event IMO to the specification of ERC-1271

there was a period of time that all smart contract wallets used bytes yet they all verified data differently

hence why bytes32 is the preferred interface since it guarantees that ecrecover behaves equally on all smart contracts

the second advantage was that using bytes 32 consolidate the differences of ERC-1654

therefore both standards now share the same validation and ERC-1654 is an extension of ERC-1271

given these developments I saw no benefit of pursuing ERC-2126 since the mine issue was solvable by using bytes32 for ERC-1271