bytes
and transmitted to the contract when a transaction should be executed.{(max) 64-bytes signature data}{1-byte signature type}
31 > signature type > 26
v
.{32-bytes r}{32-bytes s}{1-byte v}
r
, s
and v
are the required parts of the ECDSA signature to recover the signer.eth_sign
signaturesignature type > 30
eth_sign
we need to take the parameters r
, s
and v
from calling eth_sign
and set v = v + 4
{32-bytes r}{32-bytes s}{1-byte v}
r
, s
and v
are the required parts of the ECDSA signature to recover the signer. v
will be substracted by 4
to calculate the signature.signature type == 0
{32-bytes signature verifier}{32-bytes data position}{1-byte signature type}
{32-bytes signature length}{bytes signature data}
signMessage
can be used to mark a message as signed on-chain.signature type == 1
{32-bytes hash validator}{32-bytes ignored}{1-byte signature type}
approveHash
. Also if the validator is the sender of transaction that executed the Safe transaction it is not required to use approveHash
to add an entry to the mapping. (This can be seen in the Team Edition tests)0x3
(EOA address) -> bde0b9f486b1960454e326375d0b1680243e031fd4fb3f070d9a3ef9871ccfd5
(r) + 7d1a653cffb6321f889169f08e548684e005f2b0c3a6c06fba4c4a68f5e00624
(s) + 1c
(v)0x1
(EIP-1271 validator contract address) -> 0000000000000000000000000000000000000000000000000000000000000001
(address) + 00000000000000000000000000000000000000000000000000000000000000c3
(dynamic position) + 00
(signature type)bytes
(dynamic part) for verification 00000000000000000000000000000000000000000000000000000000deadbeef
0x2
(Validator address) -> 0000000000000000000000000000000000000000000000000000000000000002
(address) +0000000000000000000000000000000000000000000000000000000000000000
(padding - not used) + 01
(signature type)execTransaction
would therefore be the following: