> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rhinestone.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# EIP-7702

> Configure an EOA to use Rhinestone smart account capabilities at its existing address.

EIP-7702 delegates an EOA to smart account code while preserving its address and history. Configure it when your signer supports EIP-7702 authorizations and you need modules, session keys, or sponsored execution without moving assets to a new address.

See [EIP-7702 account setup](/wallets/custom-signer/account-setup/account-types-and-providers/eip-7702) for the protocol model and tradeoffs.

## Configure the account

Pass the same viem account as the ECDSA owner and as `eoa`. The account must implement `signAuthorization` in addition to the normal message and typed-data signing methods.

```ts theme={null}
import { RhinestoneSDK } from '@rhinestone/sdk'
import { privateKeyToAccount } from 'viem/accounts'
import type { Hex } from 'viem'

const eoa = privateKeyToAccount(process.env.PRIVATE_KEY as Hex)

const rhinestone = new RhinestoneSDK({
  auth: {
    mode: 'apiKey',
    apiKey: process.env.RHINESTONE_API_KEY!,
  },
})

const account = await rhinestone.createAccount({
  owners: {
    type: 'ecdsa',
    accounts: [eoa],
  },
  eoa,
})
```

This example runs server-side. For an embedded signer in a browser, configure short-lived JWTs as described in [security](/wallets/custom-signer/integration/security). The `eoa` account object passed to `createAccount` must itself implement `signAuthorization`; access to an authorization method elsewhere on the provider is not enough.

<Warning>
  `walletClientToAccount` does not copy `signAuthorization` in SDK 2.16.1. Do not use that adapter for EIP-7702. Use a provider-supplied viem account that implements authorization signing, or build a custom viem account adapter that delegates `signAuthorization` to the provider's supported method.
</Warning>

## Sign the required data

EIP-7702 adds two signing steps to the normal intent flow:

<Steps>
  <Step title="Sign the account initialization">
    ```ts theme={null}
    const eip7702InitSignature = await account.signEip7702InitData()
    ```

    The signature is valid across supported EVM chains. Cache it for this account configuration and include it whenever you prepare a transaction, because the account may not yet be initialized on every chain.
  </Step>

  <Step title="Prepare and sign the intent">
    ```ts theme={null}
    const prepared = await account.prepareTransaction({
      ...transaction,
      eip7702InitSignature,
    })
    const signed = await account.signTransaction(prepared)
    ```

    Here, `transaction` is the same transaction input you would use for another Rhinestone account type.
  </Step>

  <Step title="Sign and submit the authorizations">
    ```ts theme={null}
    const authorizations = await account.signAuthorizations(prepared)
    const result = await account.submitTransaction(signed, { authorizations })
    ```

    Use the options object shown above. Passing authorizations as a positional argument is a 1.x API and is not supported in 2.x.
  </Step>
</Steps>

## Limitations

* The EOA remains a root authority. Compromise or loss of its key cannot be repaired by rotating only a module owner.
* Do not treat a module threshold as removing the EOA's authority.
* Wallet support varies. Use EIP-7702 only when the signer exposes authorization signing and allows the intended delegation.

For fee sponsorship configuration, follow [sponsorship setup](/transactions/sponsorship/set-up) rather than embedding sponsorship credentials in the client.