Transaction signatures

Install dependencies

Create a transaction

The createTransaction method in the Protocol Kit allows the creation of new Safe transactions and returns an instance of the EthSafeTransaction class.

The returned safeTransaction object contains the transaction data (safeTransaction.data) and a map of the owner-signature pairs (safeTransaction.signatures). The structure is similar to the EthSafeMessage class but applied for transactions instead of messages.

We use let to initialize the safeTransaction variable because we will add the signatures later.

Sign the transaction

Once the safeTransaction object is created, we need to collect the signatures from the signers who will sign it.

Following our setup, we will sign a Safe transaction from SAFE_3_4_ADDRESS, the main Safe account in this guide. To do that, we first need to sign the same transaction with its owners: OWNER_1_ADDRESS, OWNER_2_ADDRESS, SAFE_1_1_ADDRESS, and SAFE_2_3_ADDRESS.

ECDSA signature

This applies to OWNER_1_ADDRESS and OWNER_2_ADDRESS accounts, as both are EOAs.

The signTransaction method takes the safeTransaction together with a SigningMethod and adds the new signature to the safeTransaction.signatures map. Depending on the type of message, the SigningMethod can take these values:

• SigningMethod.ETH_SIGN
• SigningMethod.ETH_SIGN_TYPED_DATA_V4

At this point, the safeTransaction object should look like this:

The signatures.data represents a specific signature. The isContractSignature flag set to false indicates that the signature isn't a smart contract signature but an ECDSA signature instead.

An ECDSA signature comprises two 32-byte integers (r, s) and an extra byte for recovery (v), totaling 65 bytes. In hexadecimal string format, each byte is represented by two characters. Hence, a 65-byte Ethereum signature will be 130 characters long. Including the 0x prefix commonly used with signatures, the total character count for such a signature would be 132.

Two more characters are required to represent a byte (8 bits) in hexadecimal. Each hexadecimal character represents four bits. Therefore, two hexadecimal characters (2 x 4 bits) can represent a byte (8 bits).

The final part of the signature, either 1f or 1c, indicates the signature type.

Safe supports the following v values:

• 0: Contract signature.
• 1: Approved hash.
• {27, 28} + 4: Ethereum adjusted ECDSA recovery byte for EIP-191 signed message.

Regarding the EIP-191 signed message, the v value is adjusted to the ECDSA v + 4. If the generated value is 28 and adjusted to 0x1f, the signature verification will fail as it should be 0x20 ('28 + 4 = 32) instead. If v > 30, then the default v (27, 28) was adjusted because of the eth_sign` implementation. This calculation is automatically done by the Safe{Core} SDK.

• Other: Ethereum adjusted ECDSA recovery byte for raw signed hash.

The hexadecimal value 1f equals the decimal number 31. If the decimal value is greater than 30, it indicates (opens in a new tab) that the signature is an eth_sign signature.

The hexadecimal value 1c equals the decimal number 28, indicating that the signature is a typed data signature.

The initial signature should look like this:

0x969308e2abeda61a0c9c41b3c615012f50dd7456ca76ea39a18e3b975abeb67f275b07810dd59fc928f3f9103e52557c1578c7c5c171ffc983afa5306466b1261f:

Smart contract signatures

When signing with a Safe account, the SigningMethod will take the value SigningMethod.SAFE_SIGNATURE.

1/1 Safe account

This applies to the SAFE_1_1_ADDRESS account, another owner of SAFE_3_4_ADDRESS.

We need to connect the Protocol Kit to SAFE_1_1_ADDRESS and the OWNER_3_ADDRESS account (the only owner of SAFE_1_1_ADDRESS) and sign the transaction.

When signing with a child Safe account, we need to specify the parent Safe address to generate the signature based on the version of the contract.

At this point, the transactionSafe1_1 object should look like this:

The signatures.data represents a specific signature. The isContractSignature flag set to false indicates that the signature isn't a smart contract signature but an ECDSA signature instead.

To generate a Safe compatible signature, we use the buildContractSignature method, which takes an array of signatures and returns another signature that can be used with Safe accounts. After that, we add the signature from SAFE_1_1_ADDRESS to our initial transaction.

The signatureSafe1_1 object should look like this:

The isContractSignature flag is now true because signatureSafe1_1 is an EIP-1271 smart contract signature from the SAFE_1_1_ADDRESS account.

The signatureSafe1_1.data signature should look like this:

2/3 Safe account

This applies to the SAFE_2_3_ADDRESS account, another owner of SAFE_3_4_ADDRESS.

We need to connect the Protocol Kit to SAFE_2_3_ADDRESS and the OWNER_4_ADDRESS and OWNER_5_ADDRESS accounts (owners of SAFE_2_3_ADDRESS) and sign the transaction.

At this point, the transactionSafe2_3 object should look like this:

We now have two signatures from the owners, OWNER_4_ADDRESS and OWNER_5_ADDRESS. Following the same process, we can create the contract signature and examine the result.

The signatures.data represents a specific signature. The isContractSignature flag set to false indicates that the signature isn't a smart contract signature but an ECDSA signature instead.

To generate a Safe compatible signature, we use the buildContractSignature method, which takes an array of signatures and returns another signature that can be used with Safe accounts. After that, we add the signature from safe1_1 to our initial transaction.

The signatureSafe2_3 object should look like this:

The table looks very similar to the previous one, but there are two main differences:

• The Signature Length value has doubled because safe2_3 needs two signatures.
• The Signature value is a concatenation of the two regular signatures.

After following all the steps above, the safeTransaction now contains all the signatures from the owners of the Safe.

The safeTransaction object should look like this:

Propose the transaction

To store the transactions and signatures off-chain, we need to call the Safe Transaction Service API - a centralized and open-source service that anyone can deploy and run.

The Safe Transaction Service is used by Safe{Wallet} (opens in a new tab) to store transactions and signatures by default.

To store a new transaction, we need to call the proposeTransaction from the API Kit, passing the Safe address, an object with the transaction, and a signature from one owner.

The transaction is now publicly available in the Safe Transaction Service with the signature of the owner who submitted it.

Confirm the transaction

To add the signatures from the remaining owners, we need to call the confirmTransaction, passing the safeMessageHash and a signature from the owner.

Once a transaction is proposed, it becomes available on Safe{Wallet} (opens in a new tab). However, to execute the transaction, all the confirmations from the owners are needed.

At this point, the transaction stored in the Safe Transaction Service contains all the required signatures from the owners of the Safe.

The getTransaction method returns the transaction with the confirmations property to check all the added signatures.

Safe{Wallet} (opens in a new tab) exposes to its users the list of pending transactions.

Execute the transaction

Connect the Safe and an a signer to the Protocol Kit. Ensure enough funds are available in the owner's account to execute the transaction and cover the gas costs. Once the Protocol Kit is initialized, the executeTransaction method receives and executes the transaction with the required signatures.

At this point, the Safe transaction should be executed on-chain and listed on Safe{Wallet} (opens in a new tab).

The safeTransaction.encodedSignature method returns the signatures concatenated and sorted by the address of the signers. It should look like this: