Meet ERC-7955: No Private Key Required

Our team at Safe Research recently proposed ERC-7955: Permissionless CREATE2 Factory, a novel mechanism for permissionlessly bootstrapping deterministic contract deployments on any Ethereum-compatible chain. It aims to replace the Safe Singleton Factory, which is currently used for Safe contract deployments, and remove a single point of failure from the Safe stack.

The Problem with the Permissioned Safe Singleton Factory

The Safe Singleton Factory is a CREATE2 factory contract that is provided as a public good by the Safe team. This key piece of infrastructure is not only used by the Safe stack, but other projects like the Coinbase Smart Wallet for their contract deployments.

CREATE2 factory contracts are very simple contracts that proxy contract creations with the CREATE2 from externally owned accounts, enabling deterministic deployments. This is a key mechanism that allows contracts to be deployed to the same address across multiple chains. This is an required feature for smart account to allow sharing the same address across multiple chains.

Because the Safe Singleton Factory is permissioned, deploying it to new chains requires a transaction signature from a specific private key. Without a signature from the canonical deployment account, the Safe Singleton Factory cannot be deployed, and therefore the contracts that rely on this CREATE2 factory will not be deployed to their canonical addresses. This is a critical bootstrapping step that can only be done by someone at Safe with access to the deployer private key.

Today's Permissioned Deployment Process

Teams that want to bootstrap deterministic contract deployments on new networks, including the Safe smart account contracts, need to request deployment transaction signatures somehow. The current process requires builders to open a GitHub issue in the Safe Singleton Factory repository and wait for the contract to be deployed. This is far from ideal:

• While we try to make the process as transparent as possible, we cannot always guarantee when the deployment will happen

• Vacations and team availability can delay the process

• It is an error prone process, which can fail because of either human error or software bugs. For example on the Gnosis Chain Chiado Testnet, a gas-estimation bug caused the deployment transaction to be submitted with an insufficient gas limit, and revert. As a result the Safe Singleton Factory can no longer be deployed to Gnosis Chain Chiado Testnet.

Why not use Nick Johnson's CREATE2 Deployment Proxy?

Nick Johnson's CREATE2 deployment proxy is very similar to the Safe Singleton factory. It is arguably the most widely used CREATE2 factory contract out there, deployed to 0x4e59b44847b379578588920cA78FbF26c0B4956C on many, many, many chains. The CREATE2 deployment factory is permissionless as it is deployed using Nick's method: instead of using a private key to sign an Ethereum transaction, a signature is instead randomly generated for a transaction, which implies two things:

1. That there is no known private key for the deployer account (in the case of the CREATE2 deployment proxy, it is 0x3fAB184622Dc19b6109349B94811493BF2a45362)

2. The deployer account can only sign exactly one transaction with a fixed gas limit and gas price, in order for the transaction to be usable on multiple chains, without EIP-155 chain replay protection.

So why not just use Nick Johnson's CREATE2 deployment factory? Around the time of the initial Safe v1.3.0 release, the Safe contracts were deployed with the CREATE2 deployment factory. However, not all chains support transactions without replay protection, and the Safe Singleton Factory was created in order to support those chains. Additionally, the fact that the signed transaction is sealed has some downsides when deploying to some L2s:

• The gas price is fixed, meaning that the transaction may overpay for the contract deployment, or worse it may not be possible to execute if the base gas price is higher than what set in the sealed transaction

• The gas limit is fixed, so for chains with alternative gas schedules (for example L2s that charge additional gas fees depending on the current L1 network fees), the transaction may revert and permanently lose the ability to deploy the CREATE2 deployment proxy

An interesting fun-fact about the Safe v1.3.0 contracts, is that there are two canonical addresses for each contract. For example the core Safe smart account contract is deployed to both 0xd9Db270c1B5E3Bd161E8c8503c55cEABeE709552 and 0x69f4D1788e39c87893C980c06EdF4b7f686e2938. This is because Safe transitioned from Nick Johnson's CREATE2 deployment proxy to the Safe Singleton Factory partway through the v1.3.0 life-cycle. The first network that required the Safe Singleton Factory for v1.3.0 deployments was Celo (although it has since added support for the CREATE2 deployment proxy).

Enter ERC-7955

We proposed ERC-7955 as a permissionless and error-resistant alternative for deploying a CREATE factory on all Ethereum Virtual Machine (EVM) compatible blockchains. It uses EIP-7702 under the hood to deploy a CREATE2 factory to a universal address, without any of the downsides of existing methods:

• Unlike the Safe Singleton Factory, it does not require access to a special account and private key – anyone can deploy it to any EVM compatible chain, as long as it supports both EIP-1014 and EIP-7702

• Unlike Nick Johnson's CREATE2 deployment proxy, it does not use a sealed transaction allowing it to work on chains that enforce EIP-155 replay protection, and adapting to the chains’ current network congestion and fees

• Unlike either method, failed deployments are recoverable: even if the transaction were to revert, the CREATE2 factory can still be deployed in a new transaction

How the Deployment Works

The deployment of the Permissionless CREATE2 Factory is done using an EIP-7702 type 0x04 transaction with a publicly known deployer account delegation to any valid bootstrap implementation:

1. First, a bootstrap contract is deployed; the exact implementation or address to which this contract is deployed does not matter, as long as it has the critical bootstrapping code to deploy the Permissionless CREATE2 Factory that specified in ERC-7955

2. The deployer account signs an EIP-7702 authorisation to the bootstrap contract from step 1; this can be done permissionlessly because the account is publicly known and standardised as part of ERC-7955

3. A transaction is executed, including the authorisation from step 2, calling the deployer account. This results in the execution of the bootstrapping code and creation of the Permissionless CREATE2 Factory contract

This enables an entirely permissionless process for deploying a universal CREATE2 factory contract to a fixed address. We released an ERC-7955 Permissionless CREATE2 Factory deployment tool to make the process more accessible, without any pesky command lines or GitHub issues. It makes use of the network configured by your wallet, and doesn’t require anyone team to “enable” your network in anyway:

For those interested in the nitty-gritty technical details on how it all works, please take a look at ERC-7955. It contains a detailed specification and rationale for the deployment process.

Looking Forward: Deterministic and Permissionless

If you are a chain looking to support teams, or are a builder and want to create new deterministic contract deployments in a fully permissionless way, head over to our ERC-7955 deployment tool to deploy the Permissionless CREATE2 Factory to your chain. The factory contract can be used as a drop-in replacement for the Safe Singleton Factory or Nick Johnson's CREATE2 deployment factory in your projects. Also, feel free to join the Etheureum Magicians discussion and help shape the future of the ERC.

About Safe Research

Safe Research is the applied R&D arm of Safe, dedicated to advancing the self custody stack. Our work is grounded in the cypherpunk principles of security, censorship resistance, and privacy, and we focus on building trustless, user centric infrastructure for smart accounts and wallets.

• Discuss ERC-7955 on Ethereum Magicians

• Learn more about Safe Research

• Read our manifesto

Let’s make Ethereum’s original cypherpunk vision real, one commit at a time.