Integrating EIP-7702 with Hardware Wallets

2025 May 09 See all posts


Integrating EIP-7702 with Hardware Wallets

pektra

(Pectra adding support for Hardware Wallets)

Introduction

We've illustrated in a previous blog post how Hardware Wallet vendors could use EIP-7702 quickly and efficiently. We'll now take a different perspective and see how a wallet vendor could integrate a Hardware Wallet supporting EIP-7702 today.

Support scope and data flow is different from one vendor to another, but they'll be offering the same functionalities from a high level point of view : signing an EIP-7702 authorization tuple and a type 4 transaction. It's expected that delegate addresses will be filtered for security purposes.

We'll be looking at 3 Hardware Wallet vendors : Keystone, Ledger and Trezor.

Note that at the moment EIP-7702 is only officially supported for Ledger devices. Data parameters and flow for other vendors may change as the Pull Requests evolve.

Ledger support

Overview

EIP-7702 support is officially available for all Ledger devices (X, S+, Stax, Flex) but the Nano S. It could be easily backported if desired.

The Ethereum application running on devices is available at https://github.com/LedgerHQ/app-ethereum.

EIP-7702 authorization tuple signing flow

The following parameters are provided when signing an EIP-7702 authorization tuple :

The device verifies that the delegate is in the application whitelist, displays all parameters related to the authorization tuple, asks the user for confirmation and returns the authorization tuple signature (v, r, s fields)

TX type 4 signing flow

The device expects an unsigned Type 4 transaction containing an authorization list. After confirmation of the different transaction elements the device returns the transaction signature (v, r, s fields). The authorization list is not displayed to the user.

I/O documentation

The parameters for the SIGN EIP-7702 AUTHORIZATION command are described in https://github.com/LedgerHQ/app-ethereum/blob/develop/doc/ethapp.adoc#sign-eip-7702-authorization.

The AUTH_7702 structure uses a DER (Distinguished Encoding Rules) TLV (Tag/Length/Value) encoding which can be summarized as follows for this use case :

The DER encoding of an integer smaller than 0x7F is the integer.

The DER encoding of an integer greater than 0x7F is 0x8X where X is the number of bytes of the smallest representation of the integer, followed by the smallest representation of the integer in big endian notation. For example 0x80 will be DER encoded as 0x81 0x80.

A DER TLV is encoded as the DER encoding of the tag, concatenated with the DER encoding of the length, followed by the value.

Building the device application

You'll need to rebuild the application if you're testing an EIP-7702 delegate that isn't in the whitelist for the current version loaded by Ledger Live.

The device application can be rebuilt and side loaded on any device following the instructions given on https://github.com/LedgerHQ/app-ethereum/blob/develop/README.md - it's recommended to use a Linux system and Docker from the CLI.

If you're not comfortable with running Docker in privileged mode, you can remove it, use the container to build the application then load it from your OS.

To test a new delegate address you can either add it to the whitelist or remove the HAVE_EIP7702_WHITELIST feature from the Makefile.

Integrating the client

EIP-7702 support will be ultimately integrated into Ledger new client architecture, the Device Management Kit - it's recommended for all integrators to switch to this client to support all clear signing features.

In the meantime for a faster integration you can use the former client, ledgerhq/hw-app-eth.

The client will need to be modified to add support for the SIGN EIP-7702 AUTHORIZATION command.

You can get some inspiration from this sample Python script.

Keystone support

Overview

EIP-7702 support is avaiable in PR #1727 for the firmware and PR #112 for the SDK.

EIP-7702 authorization tuple signing flow

The EIP-7702 authorization tuple is RLP encoded without the y_parity, r, s fields, along with the path to the key signing the authorization, into a QR code that can be scanned by the device. When scanned, the device displays all parameters related to the authorization tuple, asks the user for confirmation and returns the authorization tuple signature (y_parity, r, s fields) as a QR code that can be scanned by the client.

TX type 4 signing flow

The device expects an unsigned Type 4 transaction containing an authorization list encoded into a dedicated animated QR code, along with a path to the key signing this transaction. After confirmation of the different transaction elements the device returns the transaction signature (y_parity, r, s fields) as a QR code that can be scanned by the client. The authorization list is not displayed to the user.

I/O documentation

You can reuse the following code sample to generate the content of the QR code to sign an EIP-7702 authorization tuple with some modifications :

The response encoded as an EthSignature UR can be decoded with the following code sample.

Building the device application

There's no official way to run a modified firmware on your device. If you're running a version with an older firmware (version 1.2.2 or 1.2.4) you might be able to use an exploit to do it nonetheless - see ks3-devkit.

In that case, you can build the auth_7702 branch as described in the README.md.

After building, you can sign the firmware with signFirmware.py or signFirmwareOta2.py if you updated the bootloader with firmware 2.0.4 - using the private key associated to the public key you injected earlier with setUpdateKey.py.

You can then load the firmware either with uploadFirmware.py, or rename it keystone3.bin and put it on a SD card or use the Recovery Mode.

Integrating the client

You can refer to the web SDK demonstration or the USB SDK - you'll need to support a new DataType as described in the I/O chapter.

Trezor support

Overview

EIP-7702 support is avaiable in PR #4945 for the firmware for Trezor T, Trezor Safe 3 and Trezor Safe 5.

EIP-7702 authorization tuple signing flow

New Protocol Buffers messages EthereumSignAuth7702 and EthereumAuth7702Signature are introduced to support EIP-7702 authorization tuple signing.

When receiving an EthereumSignAuth7702 message, the device will display the delegate, nonce and chain_id, asks the user for confirmation and returns the authorization tuple signature as an EthereumAuth7702Signature message in signature_v, signature_r and signature_s.

TX type 4 signing flow

A new Protocol Buffers message EthereumSignedAuth7702 is introduced in the EthereumSignTx message to add the EIP-7702 authorization list, containing all elements of the authentication tuple (chain_id, delegate, nonce, signature_v, signature_r, signature_s)

When receiving an EthereumSignTx message containing an EthereumSignedAuth7702, the device will handle it as a Type 4 transaction. After confirmation of the different transaction elements the device returns the transaction signature in a EthereumTxRequest message (signature_v, signature_r, signature_s). The authorization list is not displayed to the user.

I/O documentation

I/O parameters are self described by the Protocol Buffers messages.

Building the device application

Follow the documentation to build the firmware and load it on a device. Note that this operation turns definitely the device into a developer unit for Trezor Safe 3 and 5.

Integrating the client

You can use the modified Protocol Buffer definitions with your existing client.

You can also directly try the EIP-7702 functionalities from the CLI with trezorctl eth sign-auth-7702 and trezorctl eth sign-tx with the --auth-list parameter.