From df0474d5b1157e377d4cb6cca99408d86f782954 Mon Sep 17 00:00:00 2001 From: avarobinson <45052879+avarobinson@users.noreply.github.com> Date: Fri, 16 Jan 2026 09:15:21 -0800 Subject: [PATCH 1/2] docs: updating 7702 details --- .../transactions/using-eip-7702/index.mdx | 111 +++++++++++------- 1 file changed, 66 insertions(+), 45 deletions(-) diff --git a/fern/wallets/pages/transactions/using-eip-7702/index.mdx b/fern/wallets/pages/transactions/using-eip-7702/index.mdx index 81e68ea0d..208eed92f 100644 --- a/fern/wallets/pages/transactions/using-eip-7702/index.mdx +++ b/fern/wallets/pages/transactions/using-eip-7702/index.mdx @@ -9,9 +9,14 @@ This gives users access to all of the capabilities of Smart Wallets including ga ## How it works -EIP-7702 enables EOAs (Externally Owned Accounts) to delegate control to smart wallets that can execute code directly from their addresses. Users simply sign an authorization -payload to delegate, then their account can function as a smart wallet with access to all of the user's assets. Wallet APIs will prompt the user to sign this authorization -when the delegation is missing on the chain they're interacting with. +EIP-7702 enables EOAs (Externally Owned Accounts) to delegate control to smart wallets that can execute code directly from their addresses. When using Transaction APIs: + +- Transaction APIs detect whether a user must first delegate via EIP-7702 +- If delegation is required, Transaction APIs prepare the correct authorization payload +- Your application prompts the user to sign when required +- We combines the delegation and transaction into a single onchain submission + +Once delegated, the user’s account behaves as a Smart Wallet while keeping the same address and assets. ## Prerequisites @@ -35,66 +40,82 @@ when the delegation is missing on the chain they're interacting with. ## Advanced - - EIP-7702 is particularly useful when you have existing wallets that are being used as EOAs, but want access to smart wallet capabilities while allowing users - to keep their existing address and avoid transferring their assets. With EIP-7702, you can upgrade your users' EOAs directly to a Smart Wallet at their current address. + + When interacting with Wallet APIs, delegation is handled automatically as part of transaction preparation. + + If a user has not yet delegated on the target chain, the API response will include **multiple signature requests**: - See a full list of recommendations [here](https://www.alchemy.com/blog/eip-7702-ethereum-pectra-hardfork#for-developers-that-havent-yet-deployed-their-application). + 1. An **EIP-7702 authorization signature** (for delegation) + 2. An **ERC-4337 user operation signature** (for the transaction itself) + + Your application is responsible for: + - Prompting the user to sign each request + - Returning the signatures to Alchemy + + We combine these signatures into a single UserOperation and submits it to the bundler. + After delegation is completed, future requests only require a user operation signature. - - The EIP-7702 capability works with the prepare calls function in a similar way to its usage in send calls. - However, you are required to handle the authorization signature request in your code's logic. + + When delegation is required, Wallet APIs return a **Prepared EIP-7702 Authorization** object. - When a delegation is required the response to prepare calls will return an array of signature requests: + This includes: + - The delegation contract address + - A nonce + - The chain ID + - A `signatureRequest` describing how the authorization must be signed - 1. An authorization signature request - 2. A user operation signature request + The authorization signature is **not** a `personal_sign` or `eth_sign` payload. + It must be signed as an EIP-7702 authorization. - Both of these requests need to be signed and included in the `sendPreparedCalls` request. `sendPreparedCalls` takes - an array of signed calls for this purpose. These signatures are combined into a single transaction that is relayed onchain. - Once the delegation is signed, as long as the user doesn't delegate to another account, subsequent requests will only - contain the user operation signature request. + For production usage, we recommend: + - Verifying the delegation address is trusted + - Using a dedicated EIP-7702 signing utility to compute the hash to sign - Signing an authorization signature request requires logic specific to the wallet being used. Examples: + Examples of signing utilities: + - [Viem](https://viem.sh/docs/eip7702/signAuthorization) + - [Cast](https://getfoundry.sh/cast/reference/wallet/sign-auth/) + - * [Viem](https://viem.sh/docs/eip7702/signAuthorization) - * [Cast](https://getfoundry.sh/cast/reference/wallet/sign-auth/) + + You do not need to send a dummy or no-op transaction to perform delegation. - - Most external wallet implementations, including browser wallets, will block - requests to sign authorizations. This is done for security reasons. To use - EIP-7702 ensure that your user's wallets support signing authorizations. - + If a user needs to upgrade to a Smart Wallet: + - Call `wallet_prepareCalls` with your intended calls (or an empty call set) + - Wallet APIs detect that delegation is required + - The response includes the required authorization and user operation signature requests - - - See the [`usePrepareCalls` react - hook](/wallets/reference/account-kit/react/hooks/usePrepareCalls) - + We handle combining delegation with the user operation automatically. + + + + Some wallets restrict or block signing EIP-7702 authorizations for security reasons. + + In particular: + - MetaMask only allows delegation to its own contract via its UI + - MetaMask does not support signing arbitrary EIP-7702 authorization payloads - - See the [`prepareCalls` SDK - reference](/wallets/reference/account-kit/wallet-client/functions/prepareCalls) - + For MetaMask users, you may need to rely on wallet-native features such as + ERC-5792 batching instead of direct EIP-7702 delegation flows. - - See the [`wallet_prepareCalls` API - reference](/wallets/api/smart-wallets/wallet-api-endpoints/wallet-api-endpoints/wallet-prepare-calls) - - + Ensure your users’ wallets support EIP-7702 authorization signing before enabling this flow. The `eip7702Auth` capability supports the interface defined in [ERC-7902](https://eips.ethereum.org/EIPS/eip-7902). - However, it currently only supports a single delegation address: `0x69007702764179f14F51cdce752f4f775d74E139`. All other addresses will be rejected. - It's recommended to use `eip7702Auth: true` to avoid the extra complexity. - Once your account is delegated, it will remain delegated until the delegation is replaced or removed. We currently only support relaying delegations - for Modular Account v2. If you wish to replace or remove this delegation, you'll need to relay the delegation yourself or use a third party service. - Viem has a guide for this [here](https://viem.sh/docs/eip7702/contract-writes). + Currently, Wallet APIs only support delegation to the following contract: + `0x69007702764179f14F51cdce752f4f775d74E139` + + All other delegation addresses will be rejected. + To simplify usage, it is recommended to use `eip7702Auth: true`. + + Once delegated, an account remains delegated until the delegation is replaced or removed. + Wallet APIs currently only support relaying delegations for Modular Account v2. - To reset an account back to a pure EOA with no delegation, delegate the account to `0x0000000000000000000000000000000000000000` as defined in [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702#behavior). + To reset an account back to a pure EOA, delegate to + `0x0000000000000000000000000000000000000000` + as defined in [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702#behavior). From c23f85220ca3be8b52c89292db9bf204b918ec47 Mon Sep 17 00:00:00 2001 From: jakehobbs Date: Thu, 22 Jan 2026 15:19:35 -0800 Subject: [PATCH 2/2] docs: 7702 tweaks --- .../transactions/using-eip-7702/index.mdx | 53 ++++++++++--------- 1 file changed, 28 insertions(+), 25 deletions(-) diff --git a/fern/wallets/pages/transactions/using-eip-7702/index.mdx b/fern/wallets/pages/transactions/using-eip-7702/index.mdx index 208eed92f..f6d2b2be5 100644 --- a/fern/wallets/pages/transactions/using-eip-7702/index.mdx +++ b/fern/wallets/pages/transactions/using-eip-7702/index.mdx @@ -9,12 +9,12 @@ This gives users access to all of the capabilities of Smart Wallets including ga ## How it works -EIP-7702 enables EOAs (Externally Owned Accounts) to delegate control to smart wallets that can execute code directly from their addresses. When using Transaction APIs: +EIP-7702 enables EOAs (Externally Owned Accounts) to delegate control to Smart Wallets that can execute code directly from their addresses. When using Transaction APIs: -- Transaction APIs detect whether a user must first delegate via EIP-7702 -- If delegation is required, Transaction APIs prepare the correct authorization payload -- Your application prompts the user to sign when required -- We combines the delegation and transaction into a single onchain submission +* Transaction APIs detect whether a user must first delegate via EIP-7702 +* If delegation is required, Transaction APIs prepare the correct authorization payload +* Your application prompts the user to sign when required +* We combine the delegation and transaction into a single onchain submission Once delegated, the user’s account behaves as a Smart Wallet while keeping the same address and assets. @@ -49,8 +49,9 @@ Once delegated, the user’s account behaves as a Smart Wallet while keeping the 2. An **ERC-4337 user operation signature** (for the transaction itself) Your application is responsible for: - - Prompting the user to sign each request - - Returning the signatures to Alchemy + + * Prompting the user to sign each request + * Returning the signatures to Alchemy We combine these signatures into a single UserOperation and submits it to the bundler. After delegation is completed, future requests only require a user operation signature. @@ -60,30 +61,32 @@ Once delegated, the user’s account behaves as a Smart Wallet while keeping the When delegation is required, Wallet APIs return a **Prepared EIP-7702 Authorization** object. This includes: - - The delegation contract address - - A nonce - - The chain ID - - A `signatureRequest` describing how the authorization must be signed - The authorization signature is **not** a `personal_sign` or `eth_sign` payload. - It must be signed as an EIP-7702 authorization. + * The delegation contract address + * A nonce + * The chain ID + * A `signatureRequest` describing how the authorization must be signed + + For quick testing purposes, you can simply use `eth_sign` to sign the `signatureRequest.rawPayload`. For production usage, we recommend: - - Verifying the delegation address is trusted - - Using a dedicated EIP-7702 signing utility to compute the hash to sign - Examples of signing utilities: - - [Viem](https://viem.sh/docs/eip7702/signAuthorization) - - [Cast](https://getfoundry.sh/cast/reference/wallet/sign-auth/) + * Verifying the delegation address is trusted + * Using a dedicated EIP-7702 signing utility to compute the hash to sign + + Example of signing utility: + + * [Viem](https://viem.sh/docs/eip7702/signAuthorization) You do not need to send a dummy or no-op transaction to perform delegation. If a user needs to upgrade to a Smart Wallet: - - Call `wallet_prepareCalls` with your intended calls (or an empty call set) - - Wallet APIs detect that delegation is required - - The response includes the required authorization and user operation signature requests + + * Call `wallet_prepareCalls` with your intended calls (or an empty call set) + * Wallet APIs detect that delegation is required + * The response includes the required authorization and user operation signature requests We handle combining delegation with the user operation automatically. @@ -92,8 +95,9 @@ Once delegated, the user’s account behaves as a Smart Wallet while keeping the Some wallets restrict or block signing EIP-7702 authorizations for security reasons. In particular: - - MetaMask only allows delegation to its own contract via its UI - - MetaMask does not support signing arbitrary EIP-7702 authorization payloads + + * MetaMask only allows delegation to its own contract via its UI + * MetaMask does not support signing arbitrary EIP-7702 authorization payloads For MetaMask users, you may need to rely on wallet-native features such as ERC-5792 batching instead of direct EIP-7702 delegation flows. @@ -105,13 +109,12 @@ Once delegated, the user’s account behaves as a Smart Wallet while keeping the The `eip7702Auth` capability supports the interface defined in [ERC-7902](https://eips.ethereum.org/EIPS/eip-7902). Currently, Wallet APIs only support delegation to the following contract: - `0x69007702764179f14F51cdce752f4f775d74E139` + `0x69007702764179f14F51cdce752f4f775d74E139` (Modular Account v2) All other delegation addresses will be rejected. To simplify usage, it is recommended to use `eip7702Auth: true`. Once delegated, an account remains delegated until the delegation is replaced or removed. - Wallet APIs currently only support relaying delegations for Modular Account v2. To reset an account back to a pure EOA, delegate to `0x0000000000000000000000000000000000000000`