Add content on EIP-7702

.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,27 @@
+# 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 delegating to Safe Singleton or the Proxy contract will expose the EOA account to the risk of front-runing during setup.
+
+## Possible approaches
+
+- Modified Safe Singleton
+
+[SafeEIP7702](https://github.com/safe-global/safe-smart-account/blob/feature/eip-7702/contracts/experimental/SafeEIP7702.sol)
+
+- Modified Safe Proxy and Safe Singleton
+
+[SafeEIP7702Proxy](https://github.com/5afe/safe-eip7702/blob/main/safe-eip7702-contracts/contracts/SafeEIP7702Proxy.sol)
+
+- SafeLite
+
+[SafeLite](https://github.com/5afe/safe-eip7702/blob/main/safe-eip7702-contracts/contracts/experimental/SafeLite.sol)
+
+### Comparison table
+
+| Feature | SafeEIP7702 | SafeEIP7702Proxy | SafeLite |
+| --- | --- | --- | --- |
+| Existing Wallet UI Compatibility | Partially | Full | Not usable |
+| Gas overhead | Between SafeLite and SafeEIP7702Proxy approach | High as new Proxy has to be deployed for each EOA | Least |

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 EVM node then:
+
+- Verifies the signature.
+- Checks the account's nonce.
+- Confirms the 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)