Feature EIP-7702 docs

.github/styles/config/vocabularies/default/accept.txt

@@ -286,4 +286,6 @@ v1
 viem
 zkLink
 zKyoto
-wei
+wei
+Pectra
+Ithaca

pages/advanced/_meta.json

@@ -29,6 +29,7 @@
   },
   "erc-4337": "ERC-4337",
   "erc-7579": "ERC-7579",
+  "eip-7702" : "EIP-7702",
   "passkeys": "Passkeys",
   "-- Safe CLI": {
     "type": "separator",

pages/advanced/eip-7702/7702-safe.mdx

@@ -0,0 +1,62 @@
+import { Callout } from 'nextra/components'
+
+# Safe and EIP-7702
+
+EIP-7702 does not specify how to initialise the storage of the account but only gives a way to set the code of the account.
+This means that the account will be created with an empty storage, and the user will have to set the storage manually.
+
+Existing Safe contracts cannot be used with EIP-7702, because of following reasons:
+
+1. Delegating to Safe Singleton or the Proxy contract will expose the EOA account to the risk of front-runing during setup.
+2. In its current implementation, the Safe Singleton contract does not let itself to become an owner meaning that after delegating to the Safe Singleton, the EOA account cannot sign Safe transactions and will need to keep another private key to do so.
+
+## Possible approaches
+
+### Modified safe proxy
+
+[SafeEIP7702Proxy](https://github.com/5afe/safe-eip7702/blob/main/safe-eip7702-contracts/contracts/SafeEIP7702Proxy.sol)
+
+This approach uses a derived proxy contract from [Safe Proxy](https://github.com/5afe/safe-eip7702/blob/main/safe-eip7702-contracts/contracts/SafeEIP7702Proxy.sol) with following changes:
+1. The constructor of the `SafeEIP7702Proxy` contract has an additional parameter `setupDataHash` which is the hash of the `setup` function call data. Thus, the address of the proxy contract also depends on the `setupDataHash` and not just the `singleton` contract address.
+Proxy contract uses this hash to verify that the `setup` function parameter values are unchanged during initialised of storage.
+
+2. The proxy implements `setup` function which calls the `setup` function of the `singleton` contract and has additional logic:
+- Set the storage slot 0 that is, the address of the singleton in the EOA storage.
+- Verify that the `setupDataHash` is equal to the hash of the `setup` function call data.
+
+This approach has a gas overhead as a new proxy contract has to be deployed for each EOA account as the setupDataHash will be possibly unique for each user.
+But, using this approach users can use the existing Safe Wallet UI with minor modifications and import the EOA account as a Safe account. 
+
+![diagram-7702-approach-1](../../../assets/diagram-7702-approach-1.png)
+
+Follow the instructions here to use this approach to set code in EOA: https://github.com/5afe/safe-eip7702/tree/main/safe-eip7702-contracts#execute-scripts
+
+### Modified safe singleton
+
+In this approach, a derived version of Safe Singleton aka `SafeEIP7702` overrides the `setup` function and reverts when called. 
+Instead, a new function `setupEIP7702` in the contract has a `signature` parameter. The default owner will be set to the address of the EOA account that is delegating to this Singleton contract with a threshold of 1.
+
+[SafeEIP7702](https://github.com/safe-global/safe-smart-account/blob/feature/eip-7702/contracts/experimental/SafeEIP7702.sol)
+
+Because of no proxy contract in this approach, the storage slot 0 remains unused. Safe Transaction Service and other services that depend on the value at storage slot 0 will not work with this approach.
+
+![diagram-7702-approach-2](../../../assets/diagram-7702-approach-2.png)
+
+### SafeLite
+
+[SafeLite](https://github.com/5afe/safe-eip7702/blob/main/safe-eip7702-contracts/contracts/experimental/SafeLite.sol) is a lite version of Safe and compatible with EIP-7702. The contract does not have a proxy and does not need any initialisation.
+SafeLite supports ERC-4337 and hence can use features such as sponsored transactions, and even batch transactions. SafeLite also supports ERC-1271 for contract-based signatures.
+SafeLite is not compatible with the existing Safe Wallet UI as it does not use the same storage layout as the existing Safe contracts.
+It does not have the features of the existing Safe contracts such as Modules, Fallback Handler, Guards.
+
+![diagram-7702-approach-3](../../../assets/diagram-7702-approach-3.png)
+
+<Callout type='error' emoji='‼️'>
+  All the above approaches are experimental and the contracts are not yet audited. Use them at your own risk.
+</Callout>
+
+## Other resources
+
+- [Demo with SafeEIP7702Proxy](https://github.com/5afe/safe-eip7702/blob/main/README.md#demo-using-ui)
+- [Code walk through](https://www.youtube.com/watch?v=dx4mk6tKHCo)
+- [Slides](https://docs.google.com/presentation/d/12j90QkVx_A-iAZ14mnx6ztsafqqsth3NWZpxp3LV2cQ/edit#slide=id.p)

pages/advanced/eip-7702/_meta.json

@@ -0,0 +1,4 @@
+{
+  "overview": "Overview",
+  "7702-safe": "Safe and EIP-7702"
+}

pages/advanced/eip-7702/overview.mdx

@@ -0,0 +1,42 @@
+# What is EIP-7702?
+
+EIP-7702 is a step towards account abstraction, enabling EOAs (Externally Owned Accounts) to have both code and
+storage. This enhancement allows EOAs to function as smart contract accounts, unlocking new features such as:
+
+- Transaction batching
+- Gas sponsorship
+- Delegated actions: Granting other addresses limited access to act on behalf of the EOA
+
+## Signing Process
+In its current implementation, EIP-7702 requires the EOA to sign a special hash calculated using the following parameters:
+
+- `chain_id`: The identifier of the blockchain network
+- `address`: The account address to which calls will be delegated
+- `nonce`: Current nonce of the account.
+
+
+Setting Code for the EOA
+Once the EOA signs the hash, an authorization list is sent to the EVM node through a new transaction type, the set code
+transaction, introduced in EIP-7702.
+
+The execution client then performs the following checks:
+
+- Verifies the signature.
+- Checks the account's nonce.
+- Confirms the chain ID (`0` or the current chain ID).
+
+If all checks pass, the execution client sets the EOA's code in the format `(0xef0100 ++ address)`.
+
+EIP-7702 is available on devnets and testnets such as Pectra Devnet, Ithaca and, will be enabled on mainnet after the
+Pectra upgrade.
+
+An important consideration that applies for EOAs that have code set is that the private key can be still used to sign
+transactions and even change delegations. Hence, it is important to keep the private key secure even after the
+authorization has been signed.
+
+__Note: This signing method is not compatible with the EIP-712 or EIP-191 standards. Wallet providers must add support
+for this specific signing method.__
+
+## Further reading
+
+- [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702)