PREP (Provably Rootless EIP-7702 Proxy) Method Deep Dive

advanced

eip-7702smart accountsPREPcryptographyNick's methodBiconomy

With EIP-7702 looming on the horizon, developers building on Ethereum are excited to get a slew of new features when working with EOA accounts. There is still a lot of confusion around how EIP-7702 will be implemented in practice. One feature provided by EIP-7702, which hasn’t gotten nearly enough attention is the ability to create new Ethereum accounts using Nick’s method. First mentioned by Ethereum’s Dror Tirosh, it inspired a small R&D team at Biconomy to build a completely new account standard around it.

We call them “PREP” accounts as they’re accounts deployed through setting an EIP-7702 delegation (proxy) which can prove that the private key associated with their address is not known to anyone. This has major implications for:

  • Deploying new smart accounts
  • Blending the tooling and interactions for EOAs and smart accounts (the biggest stated goal of EIP-7702)

What we’ve been able to achieve:

  • Up to 80% reduction in deployment costs for smart accounts
  • Proving that the account owner doesn’t know the Private Key associated with the EIP-7702 authorization - enabling Resource Locks, Time-Locks and Multi-Sigs to work with EIP-7702
  • Potential to build a portable smart account, where the user can migrate the account between multiple wallets with a seed phrase or a similar method

Goals

We see this method as being a potential candidate to become the default way of creating new EVM accounts in the future as it combines all the best characteristics of EOA and Smart Accounts.

Beyond this, using this method makes it relatively easy for teams to develop universal tooling which works with accounts which were upgraded from EOAs and with new PREP Accounts! The goal would be to standardize a lot of what’s written here into an EIP and work with smart account and wallet providers to enable a better accounts standard for Ethereum and EVM chains.

As such, we don’t see the PREP standard as outlined here to be the final form of this proposal - we see it as being the first step towards a new account system implemented by wallets, users and developer tooling.

Until such a goal is achieved, however, Biconomy will be launching PREP support natively in the new version of the Nexus smart account and our execution environments (ERC-4337 and MEE).

Nick’s Method

As nicely explained in various resources, Nick’s method - envisioned by Vitalik Buterin and first implemented by Nick Johnson - enables “Keyless Execution”. In short, Nick’s method works by exploiting the fact that the from (sender) parameter of an EVM transaction can be cryptographically recovered from the rest of the parameters of the transaction.

This means that a developer can encode any EVM transaction, for example “send 5 ETH to 0xabcd…000” and - instead of signing that transaction with a private key - randomly generate the r, s and v values of the transaction signature.

The developer can then use ecrecover to learn the address for which this signature is valid. If they then send 5 ETH + gas needed for execution to that address and broadcast that encoded transaction - the transaction will be successfully executed! From the perspective of the EVM chain, it’s a validly signed transaction.

The great thing about this is that it enables developers to execute transactions from accounts for which they don’t know the private key.

EIP-7702

EIP-7702 introduces the ability to delegate the control over some EOA to a contract deployed on chain. This is usually done by deploying a singleton contract and using EIP-7702 to make the EOA address a proxy for that contract. The blockchain essentially acts as if the code of the contract has been deployed on the EOA address.

In order to set the EIP-7702 delegation, a user needs to sign an authorization message in the following format with their private key:

const message = keccak(
    concat(MAGIC, rlp([chain_id, address, nonce]))
)

Where:

  • MAGIC is the constant 0x05 which is concatenated to all EIP-7702 messages
  • chain_id is the id of the chain on which the authorization is done or 0 if the message should be valid for all chains
  • address is a 20-byte address of the singleton contract to which we’re delegating to
  • nonce is the current nonce of the signing account

This message and its associated signature (the r, s and y_parity values) is then sent to the chain in the authorizations field of a new type of transaction introduced with EIP-7702. EVM verifies the authorization and delegates the EOA to the target smart contract address - giving it all the functionalities of that contract!

If the target contract is a Smart Account which has an execute function - this means that Bundlers/Relayers/Solvers can post instructions signed by the user on behalf of that user.

This enables:

  • Gas sponsorships (paying for the user’s gas)
  • Allowing users to pay for gas with ERC-20 tokens
  • Execute multiple transactions with a single signature (e.g. ERC-20 approve + execute)
  • Many advanced features like multichain execution, intents, scheduled transactions, session key automation, passkey signatures, and more

EIP-7702 Limitations

While EIP-7702 is poised to drastically improve the user experience of Ethereum and EVM, there are certain notable and widely adopted functionalities provided by Smart Accounts today which are not available with EIP-7702 delegated accounts.

These limitations stem from the fact that the user still has an EOA which acts as a root signer for all actions - which can override all limitations set by the smart account. This has the implication that the user:

  • Can’t have multi-sig accounts (since the EOA can override all signers)
  • Can’t have time-locked account functionalities (since the EOA can execute faster than time-lock)
  • Can’t have some very popular cross-chain/interop functionalities, such as resource locks (since the EOA can sign a transaction which frontruns the source chain claim process used by resource locks)

Overriding smart accounts with EOA can be done in two ways:

  1. Primary method: Leveraging the fact that the EOA can sign a transaction which re-delegates the EOA to another account or completely removes the delegation from the EOA. There are some attempts to mitigate this - notably ERC-7851 (enabling the deactivation of the EOA).

  2. Secondary method: Some very commonly used tokens use off-chain signing to move funds around - most notably with the usage of ERC20Permit (ERC-2612). This means the user doesn’t even have to un-delegate the account.

Nick’s Method + EIP-7702

Now we come to the core of this article - what if we could deploy an account for which we don’t know the private key, by combining Nick’s method and EIP-7702 authorizations? Then, since we don’t know the private key - we could never override the smart account delegation and we could never sign an ERC20Permit or a Permit2 message to move some tokens to another address.

This is similar to a normal CREATE2 account deployment with some unique benefits which only Nick’s can offer.

Turns out, we can! Since the EIP-7702 authorization looks like this:

[chain_id, address, nonce, y_parity, r, s]

Where the r, s and y_parity parameters are fetched from signing the EIP-7702 authorization message. What we can do then is run the authorization process in reverse!

i. Generate a valid EIP-7702 message

First generate a valid EIP-7702 authorization message hash with the following values:

  • chain_id = 0 to have the message be valid on all chains
  • smart_account_address to be the address of the smart account singleton contract
  • nonce = 0 since this will be a newly deployed account
const messageHash = keccak256(
    concat([
        MAGIC_PREFIX, 
        rlp([
            0, //chainId
            smart_account_address,
            0 //nonce
        ])
    ])
)

ii. Generate a random signature

After you have encoded the EIP-7702 authorization message, generate a random ECDSA signature by generating random r and s values.

Notes:

  • Make sure that the s value is smaller than secp256k1n/2 (as per EIP-2)
  • Every recoverable pair of r and s recovers two valid addresses (as the elliptic curve is symmetric). This is represented by the v value. Since we don’t care about the private key, we can use whichever v value we want (27 or 28)
const r = randomBytes(32)
const s = randomBytes(32) // make sure the value is smaller than secp256k1n/2
const v = randomSelect(27, 28) // we don't care about the v value

iii. Recover the signer address

Now we can recover the address for which this is a valid signature. We will not know the private key of that address!

const signature = concat([r, s, v]) 
const recoveredAddress = recoverAddress(messageHash, signature)

iv. Generate an EIP-7702 authorization tuple

Now that we have successfully recovered an address from a signature, we can generate the EIP-7702 authorization tuple:

// Fields must match the fields used in the `messageHash` in step i.
const authorization = {
    chain_id: 0, // chainId zero means the message is valid on all chains
    address: smart_account_address, // address of the smart account singleton
    nonce: 0, // it's a never used account so the nonce can be 0
    y_parity: v, // y_parity is a different name for the v param
    r: r, // randomly generated r from step ii.
    s: s, // randomly generated s from step ii.
}

v. Post the transaction onchain

By posting an EIP-7702 transaction type with this authorization as one of the authorizations in its authorizations array - you will have successfully delegated the recoveredAddress to the smart_contract_address! This means that the recoveredAddress is now a fully fledged smart account!

vi. Initialize the smart account

After we have delegated the recoveredAddress to our desired smart account implementation, we must initialize the smart account. This usually means setting the owner(s) of the account and the signing scheme for the account. This can be one or more EOA signers, or a Passkey signer or an MPC signer, etc. The initialization part wholly depends on the implementation of the smart account itself.

Nick’s + EIP-7702 Core Benefits

Combining Nick’s and EIP-7702 comes with a lot of benefits even before we add the PREP specific functionalities.

Up to 90% Gas Savings

One big benefit of using Nick’s method together with EIP-7702 authorizations is that the cost of deploying a smart account drops from ~150k gas down to ~70k gas for a general-purpose case!

With certain optimizations which assume that the account has a single EOA signer - we can achieve even greater optimizations and bring the cost of deployments down to 30k of gas - an 80%+ reduction in cost!

Same Address on All Chains

Since using Nick’s method with EIP-7702 is a purely cryptographic combo, the user will have the same address on all standard chains!

As Nick’s method with EIP-7702 authorizations uses a purely cryptographic derivation of the user address and as Nick’s method can also be used to deploy the singleton Smart Account implementation contracts - this means that the user will always have the same address on any EVM compatible chain (which has EIP-7702 support) and any future EVM compatible chain!

Limitations of Nick’s + EIP-7702

While combining Nick’s and EIP-7702 is a powerful combo, there are several limitations which we still need to solve:

  1. Frontrunning protection: The smart account which is being initialized needs to be protected from being frontrun. Since the authorization tuples are publicly available in the mempool, a malicious actor could execute the transaction itself and - if the initialization function isn’t properly protected - set itself as the sole signer of the account.

  2. Proving that you don’t know the private key: One of the main reasons we’ve used Nick’s method with EIP-7702 is to have accounts for which no-one knows the private key. However, by default, there is no onchain or offchain method through which anyone could verify that nobody knows the private key. This still prevents Nick’s EIP-7702 method from being used for multi-sigs, resource locks, time-locks, etc.

  3. Initialization signature required: Since EIP-7702 is a way to improve the onchain UX of EVM chains, we need to be cognizant that users want one action == one signature. Since we recover the address from the authorization and then init the smart account through a protected method - this would require user to separately sign the creation of the account.

  4. Non portability: The accounts generated by EIP-7702 + Nick’s are generally not “importable” into wallets. Since most wallets expect a seed phrase to be imported to derive an account, Nick’s generated accounts will not have this capability.

The good news is that, by being clever with reusing the r and s parameters for multiple purposes, we’ve managed to solve for issues 1, 2, and 3!

The Ultimate Solution: Provably Rootless EIP-7702 Proxy (PREP) Accounts

Taking into account all of the benefits of the Nick’s deployment method combined with EIP-7702 - we’ve dedicated an R&D team to work around the limitations of the method and now - we’re happy to say that we’ve solved for all of the issues while retaining all of the benefits!

The solution is elegant, cryptographically sound and already set for release in our latest Biconomy Nexus smart account implementation!

Multichain Front-running Protection & Initialization with Zero Signatures

In order to ensure that the smart account can only be initialized with the initial configuration set out by the user and that no signer can be frontrun, our PREP smart account implementation expects the hash of the initData for the smart account to be contained within the r parameter of the generated signature.

By packing the initData within the r parameter, since changing the r parameter will change the recovered address, we’re making sure that there is only one valid initData for that specific address. This means that, even if it’s intercepted, the frontrunning bot will still only be able to initialize the account with the initial configuration that the user actually wanted.

Additionally, since the r parameter is doing double duty as both the initData container and the regular r parameter - by recovering the address from the message - the user is also permitting the initialization of the account itself - meaning that the user doesn’t need to sign anything to allow the initialization of the account since the authorization itself already contains all the protections.

Proving the User Doesn’t Know the Root Private Key

In order to prove that the user doesn’t know the private key, we’ll use a well known cryptographic trick of replacing most significant bytes of the s param with some magic value. If the s param contains enough fixed bytes, the chance that it was generated from a known private key goes down to being basically impossible.

Replacing 13 most significant bytes of s would require 2^103 operations to find the associated private key, which would take even the most powerful supercomputers available today around three trillion years to complete. The rest of the s parameter would be randomly generated.

During account initialization, the exact r, s, v values which were used to encode the creation of the account would be provided within the initData - the contract would then recover the address, check that the owner set in the initData is the address recovered from those r, s and v params and check that the s param has the magic value prefix.

If those conditions are true, the account would set the rootless flag as true within its storage. Anyone interacting with the account could then verify that the account is actually rootless.

Note: This system is not quantum resistant and in a post-quantum world - the private key could be mined for accounts which use Nick’s method to initialize. However, this vulnerability isn’t specific to this account implementation but to EIP-7702 + Nick’s in general. Since this method leverages the standard, when Ethereum adds quantum resistance, this method should be adapted.

Putting It All Together

By combining the hash of the initData in the r parameter and the magic value prefix in the s value and then using it to recover a signer for an EIP-7702 authorization - we have created the ultimate smart contract account!

It combines the best features of EOAs (same address everywhere, purely cryptographic derivation of the address, potential for portability, same configuration on all chains) with all of the features offered by smart accounts. With a few simple adjustments, we’ve managed to solve all of the issues of Nick’s method deployment.

Not only that, but we’ve also made the deployment of the account up to 80% cheaper than using the CREATE2 method!

On top of it all, since this account uses EIP-7702 to create new accounts - a lot of the tooling (SDKs, bundlers, relayers) can be used both for new PREP accounts and for existing EOAs which were converted through EIP-7702.

Example in pseudocode of setting r, s and v:

// e.g. set '0xABC...000' as the owner of the account
const initData = "0xInitData..." 

// The r parameter is the hash of the initData
const r = hash(initData)

// magic prefix
const magicPrefix = '646d6a0000000'

// s Prefixed with magic value
const s = concat(magicPrefix, randomBytes(19))

// v can be either 27 or 28, it's irrelevant for this method
const v = 27

Biconomy Nexus - The First PREP Account Implementation

The upcoming Nexus 2.0 account from Biconomy will be the first smart account to support the full feature set of PREP. As more chains add EIP-7702 capabilities to their stack, we’re expecting more and more of our clients to use the PREP account stack to leverage all of the new capabilities.

Nexus 2.0 will be audited and production ready (together with the associated PREP tooling) on Day 1 of the Pectra merge on Ethereum mainnet (planned in March ‘25). As soon as EIP-7702 standard is widely adopted, developers can start reaping the benefits of the PREP standard by using Nexus 2.0.

Nexus 2.0 will support:

  • Init block from r parameter
  • Setting the rootless flag by checking the magic value prefix in the init block
  • Lightweight deployments saving up to 80%+ on gas

Conclusion

The Ethereum/EVM developer community has a unique opportunity to set a new standardized account deployment system that combines the best of both EOAs and Smart Contract Accounts.

Extra: Portable Smart Accounts

While portable smart accounts are outside of the scope of this article, it’s important to mention portability in the context of creating a new account type for EVM and Ethereum.

The PREP account standard creates a universal, cryptographically deterministic account standard for Ethereum and EVM blockchains. With a bit of additional work, it has the potential to become the default way in which new accounts are deployed as it inherits most of the benefits of EOAs and all of the benefits of SCAs. And it achieves all of this while only requiring EIP-7702 support from chains.

However, there is one feature which EOA users deeply appreciate which is not available by default with this approach: portability - the ability for users to import their account into different wallets by exporting their private key or seed phrase.

While this is often touted by smart account teams as a negative aspect of blockchains, the user behavior points to a different reality. Many institutional users as well as more sophisticated retail users see the existence of the private key and the seed phrase as a core benefit of blockchains. If we are to work towards wider implementation of the PREP standard, there needs to be a way to enable portability.

For portability to work, wallets need two key features:

Discoverability

A wallet needs to be able to find the address of the account from some piece of information provided by the user. With classic EOA accounts this is done by deriving the address from the private key of the user. The private key, in turn, can be derived from the seed phrase. With PREP accounts, we need a different method - ideally deriving from a private key as well.

Ownership

A wallet needs to be able to take ownership over the account which was imported into it. With EOAs this is simple, as whoever can sign transactions with the private key controls the associated address. With rootless smart accounts this becomes much harder as the account can be owned by a much more complex authorization scheme than a simple private key. The biggest question is how to enable the wallet to “take ownership” of such an account.

Out of the two problems, discoverability is much easier. Since the only thing a PREP account needs to derive its address is the address of the initial smart account implementation and the generated r, s, v parameters - those could easily be provided to the wallet to “discover” the account address. By recovering the address and looking at the s parameters, the wallet could deduce that the account is PREP compliant.

Ownership would need to be solved by allowing the wallet to upgrade the implementation of the PREP wallet to a new implementation. This would be done in a similar way to a wallet putting a new delegation on an EOA which has an existing EIP-7702 delegation from a previous wallet. In order to make these upgrades compatible with things like resource locks - taking ownership over an account could be done with a time delay. Since the PREP account doesn’t have an associated private key, this could be done through a standard method on the account itself, which could be encoded into an EIP!

However, methods for achieving this are beyond the scope of this article and would require broad industry support to achieve. At Biconomy, we’re more than happy to open a conversation with all interested parties on making a portability standard work for PREP accounts and for smart accounts in general.