In mode libraries, for validateUserOp we encode more data in the signature (includes timestamps and bool that defines whether we do a trigger action or not).
For validateSignatureForOwner we do not use this data, so we do not expect it to be encoded into the signatureData.
This allows reducing calldata size a bit, thus saving some gas for L2's
However, it introduces more friction on the sdk side where we have to decide should we use shortEncoding for a given Stx entry's signature or not.
There's a suggestion of always encode this data into signature, since it is not huge = 2*48 bytes (timestamps) + 1 byte (bool)
This will make smart contracts and sdk code easier by sacrificing a small calldata size optimization.
One should be aware that this optimization only applies to the non-ERC4337 flows (ERC-1271, ERC-7780), which are very rarely used currently.
In mode libraries, for
validateUserOpwe encode more data in the signature (includes timestamps and bool that defines whether we do a trigger action or not).For
validateSignatureForOwnerwe do not use this data, so we do not expect it to be encoded into the signatureData.This allows reducing calldata size a bit, thus saving some gas for L2's
However, it introduces more friction on the sdk side where we have to decide should we use
shortEncodingfor a given Stx entry's signature or not.There's a suggestion of always encode this data into signature, since it is not huge = 2*48 bytes (timestamps) + 1 byte (bool)
This will make smart contracts and sdk code easier by sacrificing a small calldata size optimization.
One should be aware that this optimization only applies to the non-ERC4337 flows (ERC-1271, ERC-7780), which are very rarely used currently.