Back to Overview

The Real Minimal Proxy - Powered by EIP-7702

August 7, 2025

For years, developers have relied on EIP-1167 minimal proxies to cut gas costs during contract deployments, which became the industry benchmark. Still, they require 45 bytes of runtime code and a factory contract for atomic deployment and initialization.

‍

In this blog article, we present a new approach that pushes past those established limits, using a powerful feature in the new EIP-7702 to render the traditional proxy factory obsolete. We'll demonstrate a technique for keyless, direct-to-address deployment that not only shrinks the proxy bytecode by nearly 50% but also streamlines the entire process into a single atomic transaction, saving gas and eliminating factory overhead.

‍

EIP-7702 in a Nutshell

EIP-7702 introduces a new transaction type 0x04 ("set code") that lets any Externally Owned Account (EOA) set or replace a delegation by presenting an off-chain signature over an authorization tuple. Once the transaction is mined the EOA (so-called authority) behaves like a smart contract. The spec defines:

auth_hash = keccak256( 0x05 || rlp(chainId, targetAddress, nonce) )

With some validations, most importantly, if the signature tuple (v, r, s) is valid for that auth_hash, the client sets the code of authority to be:

(0xef0100 || targetAddress)

This is a delegation designation.

So in short, EIP-7702 lets us deploy protocol-enabled proxies for EOAs. Can we use those as minimal smart contract proxies also?

EIP-7702 for proxies?

Minimal-proxy patterns (EIP-1167) are loved for their gas savings, yet they still have a 45-byte runtime code and rely on a factory contract to deploy and initialize. Swapping in EIP-7702 feels like a magic bullet: 23 bytes of delegate-proxy code and a single batched transaction, but two hurdles appear immediately:

  • We don't know the private key for the future proxy address, so how can we sign an authorization?
  • A naive attempt to shove the EIP-7702 proxy bytecode straight into a new contract blows up on opcode 0xEF (INVALID) during deployment (see EIP-3541).

Nevertheless, private key ownership is not mandatory to produce a valid signature.

Keyless Deployment

This is not the first time when the idea of keyless deployment is used, see The DAO Edge Cases and the deployment of EIP-1820 and EIP-4788. By reverse engineering a valid signature, we obtain a single-use synthetic address, which is cryptographically bound to the transaction input data (the authorization tuple in our case).

To understand why keyless deployment is possible, we first need to understand how ecrecover works. ecrecover is what the execution layer uses to find the signer of a transaction based on the signature. So, ecrecover gives us the signer's address given the transaction. How can it do that?

$$P_A=r^{-1}[s*K-m*G]$$

where:

  • $G$: group generator
  • $Q$: group order
  • $P$: modulus
  • $m$: hash of the message
  • $k$: random nonce
  • $K$: (commitment) corresponding point $K=kG=(x,y)$
  • $r$: $x \pmod Q$
  • $d_A$: user's private key
  • $P_A$: user's public key $P_A=d_A \cdot G$ = $(P_{A_x}, P_{A_y})$

‍

If we fix $s$ and the parity $v$ to constant values and keep trying different $r$, we can get a valid point $P'_A$ if $r$ corresponds to a valid point $K'$ on the Secp256-k1 Curve. Note that there is nearly a 100% ($Q/P$) probability of success.

Below is an python implementation for keyless deployment:

  • We set $s = \texttt{SEED}$ + $\texttt{random.getrandbits(128)}$ so every invocation starts from a fresh slice of the signature space and avoids mining the same proxy address across two runs with the same implementation address.
  • $r$ begins at $\texttt{SEED}$ and is incremented linearly until ecrecover yields a valid public key; the corresponding address becomes our authority (proxy).
SEED = 0x7702770277027702770277027702770277027702770277027702770277027702

# msg_hash = keccak256( 0x05 || rlp(chainId, targetAddress, 0) )
def mine_sig(msg_hash: bytes):
    attempts = 0
    r = SEED
    s = SEED + random.getrandbits(128)
    authority = 0
    v = 0

    while True:
        attempts += 1

        try:
            sig = keys.Signature(vrs=(v, r, s))
            pub_key = sig.recover_public_key_from_msg_hash(msg_hash)
            authority = pub_key.to_checksum_address()
            break

        except Exception:
            r += 1

            continue

    return authority, r, s, v

Note the authority (the to-be-deployed proxy) is a new account hence its nonce would be 0. And the recovered public key and hence the authority address (proxy) is deterministic from the authorization tuple if the SEED is fixed.

The setCode transaction allows the inclusion of multiple authorization tuples. Hence a batch of proxies can be deployed in one transaction.

In summary, the following steps are needed to deploy an EIP-7702 proxy:

  1. Deploy your implementation contract as before.
  2. Reverse engineer a valid signature from the desired authorization tuple.
  3. Submit a setCode transaction containing the authorization tuple. To initialize it in the same transaction, $\texttt{tx.to}$ should be set to the synthetic address and a call to $\texttt{initialize()}$ should be embedded in the $\texttt{tx.data}$.

Impact

The EIP-7702 proxy comes with the benefits of:

  1. Less bytecode: 23 bytes of EIP-7702 v.s. 45 bytes of EIP-1167, nearly 50% reduction in size.
  2. Factory-less: Less overhead of factory development and audit.
  3. Cheaper Deployment: Our example Deployment (see below) shows a 18% (95,654 v.s. 116,357) reduction in gas used.
  4. Cheaper Calls: Each call to the proxy is cheaper as the remaining overhead of the EIP-1167 is eliminated. The gas difference depends on the call arguments, in our example it was 2,669 gas per call.

Security Caveats

Cross-chain Replay

Setting $\texttt{chainId == 0}$ effectively disables replay-protection. The identical authorization tuple can be broadcast on any network, spawning the same proxy address everywhere, but each instance can be initialized with different parameters, handing over control to whoever front-runs first on that chain.

Front Running and Deployment Validation

If function $\texttt{initialize()}$ is permissionless, deployment and initialization should be bundled in the same setCode transaction. Splitting them opens a race window where the freshly deployed proxy sits permissionless and may be hijacked.

However, bundling them does not prevent front-running. An observer can copy your mined signature $\texttt{(v,r,s)}$ once it reaches the mempool and front-run with their own setCode transaction with modified calldata. For instance, a permissioned contract meant for Owner A can be deployed first by an attacker who swaps in Owner B, irrevocably stealing the address.

Hence deployment validation is essential to ensure the EIP-7702 proxy is deployed as expected.

Address Collision

EIP-7702 modifies the restriction of EIP-3607 (transactions from an account with code must be rejected) for a valid delegation indicator.

Hence, theoretically a private key for the EIP-7702 proxy could be found, allowing an attacker to make transactions in the name of the proxy. This has two potential consequences:

  1. A malicious deployer might pretend to perform a "keyless" deployment, even though they have previously created a collision between the EIP-7702 proxy address and an EOA controlled by a private key. This allows them to take over later. This requires an estimated $2^{80}$ computing operations.
  2. An attacker could try to find the private key for a proper "keyless" deployment. However, this should be as hard as finding the private key for any other EOA address, and hence infeasible without a quantum computer.

Conclusion

EIP-7702 makes it possible to deploy a "real" minimal proxy with a simple setCode transaction. Deployment and initialization can be achieved in a single atomic transaction. Comparing to the previously "minimal" EIP-1167:

EIP-1167 Proxy

  • 🧱 Requires factory
  • 📦 Larger bytecode size
  • ⛽️ Higher deployment gas
  • 💸 More expensive to call

EIP-7702 Proxy

  • 🚫 No factory required
  • 🪶 Smaller bytecode
  • 💨 Cheaper to deploy
  • ⚡️ Lower call cost

‍

However, when comparing security, the new approach is worse:

  • Front-running the initialization is a bigger problem than it would be in most factory-deployed EIP-1167 proxies. As a defense, if the implementation contract is aware, it can add application-specific front-running protection. Furthermore, as recently discovered, there are also "traditional" proxies that suffer from initialization front-running.
  • There is the looming problem a malicious deployment using an address collision (which becomes more relevant as computing power grows) allowing someone to take over a seemingly secure proxy. Standardization of the deployment process could add additional security.

Reproduce It Yourself

Example repository: https://github.com/ChainSecurity/real-minimal-proxy/

‍Happy hacking!

About us

‍Ready for a sanity-check on your 7702 rollout?

We have already audited many account-abstraction stacks (our wallet & AA audit reports), and we built the open-source Deployment Validation tool.

If you have questions, don’t hesitate to reach out to contact@chainsecurity.com for general requests including requests for audits, and for questions about this or other vulnerabilities. Also, visit us at chainsecurity.com.

‍

‍

external-link