Add ERC: Permissionless CREATE2 Factory #1052

rmeissner · 2025-05-23T08:14:17Z

No description provided.

eip-review-bot · 2025-05-23T08:14:45Z

File `ERCS/erc-7955.md`

Requires 1 more reviewers from @g11tech, @SamWilsn, @xinbenlv

ERCS/erc-permissionless_create2_factory.md

github-actions · 2025-06-20T10:29:36Z

The commit 558f3d6 (as a parent of e8f0ce2) contains errors.
Please inspect the Run Summary for details.

SamWilsn · 2025-07-15T16:21:59Z

ERCS/erc-7955.md

+---
+eip: 7955
+title: Permissionless CREATE2 Factory
+description: A permissionless method for the cross-chain deployment of a universal CREATE2 factory.


Your description is mostly just restating your title in more words. I think the only new information introduced here is that it's "cross-chain". You should use your description to elaborate on the ideas introduced in your title, not just restating them.

SamWilsn · 2025-07-15T16:23:38Z

ERCS/erc-7955.md

+
+#### 1. Nick's Method
+
+Use Nick's method to randomly generate a signature for a transaction **without** [EIP-155](./eip-155.md) replay protection that deploys the CREATE2 factory. Nick's method ensures that there is no known private key for an account that deploys the CREATE2 factory, meaning that the resulting contract will have a deterministic address and code on all chains. This strategy is used by the _Deterministic Deployment Proxy_ (`Arachnid/deterministic-deployment-proxy`), one of the most widely used CREATE2 factory contracts.


Deterministic Deployment Proxy (Arachnid/deterministic-deployment-proxy)

This is an external link and must be removed.

Do you mean the reference to the GitHub repository? This was intended to be rendered as:

<i>Deterministic Deployment Proxy</i> (<code>Arachnid/deterministic-deployment-proxy</code>)

And should just be plain text with no link. If this is also forbidden, I can remove it (and it also appears in a few other places when referencing safe-global/safe-singleton-factory for example).

SamWilsn · 2025-07-15T16:24:25Z

ERCS/erc-7955.md

+
+- It does not work on chains that only accept EIP-155 replay-protected transactions.
+- It is sensitive to changes in gas parameters on the target chain since the gas price and limit in the deployment transaction is sealed, and a new one cannot be signed without a private key.
+- Reverts due to alternative gas schedules make the CREATE2 factory no longer deployable.


The tense here is off, but I'm not sure how you intend it to be read. Perhaps:

Suggested change

- Reverts due to alternative gas schedules make the CREATE2 factory no longer deployable.

- Reverts due to alternative gas schedules making the CREATE2 factory no longer deployable.

I meant "reverts" as a noun (so "the reverts ... make"), maybe just some missing punctuation:

Suggested change

- Reverts due to alternative gas schedules make the CREATE2 factory no longer deployable.

- Reverts, due to alternative gas schedules, make the CREATE2 factory no longer deployable.

Does that make it clearer?

SamWilsn · 2025-07-15T16:24:58Z

ERCS/erc-7955.md

+
+#### 2. Secret Private Key
+
+Keep a carefully guarded secret key and use it to sign transactions to deploy CREATE2 factory contracts. The resulting contract will have a deterministic address and code on all chains where the first transaction of the deployer account is a CREATE2 factory deployment, which can be verified post-deployment to ensure trustlessness. Additionally, this method does not have the same gas sensitivity downsides as Nick's method, as the private key can sign a creation transaction with appropriate gas parameters at the time of execution. This is the strategy used by the _Safe Singleton Factory_ (`safe-global/safe-singleton-factory`) and _CreateX_ (`pcaversaccio/createx`).


Similar external links. Please remove them.

SamWilsn · 2025-07-15T16:27:06Z

ERCS/erc-7955.md

+The _bootstrap contract_ MAY implement additional features such as:
+
+- Abort early if either _CREATE2 factory contract_ is already deployed or the _deployer_ is not correctly delegated to.
+  - This can help mitigate gas griefing from the previously described front-running issue.


Oops, nice catch. The issue is described below and not above. Will fix.

SamWilsn · 2025-07-15T16:29:57Z

ERCS/erc-7955.md

+
+One issue with this method is that because the `DEPLOYER_PRIVATE_KEY` is public, anyone can sign alternative delegations or transactions and front-run a legitimate CREATE2 factory deployment. We consider this to not be a serious issue however, as:
+
+1. Doing so does not prevent future deployments - meaning that an attacker can only delay the deployment of the CREATE2 factory with a sustained attack at a gas cost to the attacker.


I don't believe the account paying for the gas of a 7702 transaction has to be the same account as the one being delegated. You never have to put funds into DEPLOYER_ADDRESS to execute the code contained within it.

I don't believe the account paying for the gas of a 7702 transaction has to be the same account as the one being delegated.

Correct.

You never have to put funds into DEPLOYER_ADDRESS to execute the code contained within it.

Also correct. In fact, you should never send funds to DEPLOYER_ADDRESS as anyone can take them.

The front-running issue stems from the fact that an attacker can submit an alternate EIP-7702 transaction (from another address they control) in order to increase the DEPLOYER_ADDRESS's nonce, thereby invaliding the EIP-7702 delegation signature from DEPLOYER_PRIVATE_KEY in a legitimate deployment transaction that is included afterwards.

Just fixes a small inconsistency where we were using `||` and `++` for byte concatenation. Prefer the former.

- Remove duplicate linking to EIP-7702 (only first one should be linked) - Remove trailing whitespace - Fix spelling error

Requires should be _just_ numbers without the `EIP-` or `ERC-` prefix. This causes issues with the generated HTLM and proofer.

Fixed some section titles that weren't titlecased correctly.

In order to not depend on EIP-3855 `PUSH0` opcode, we refactor the factory code to use `RETURNDATASIZE` which is guaranteed to be `0` **except** for when `CREATE2` reverts. With a little bit of moving code around, we also managed to change make the code one byte smaller and fit into a 32-byte word.

The ERC lint does not like additional top level sections, so move the "custom" forwards compatibility section into a subsection of the backwards compatibility

We remove all non-relative links, as the ERC linter does not allow them. This is slightly unfortunate, since they did provide additional context to the ERC, but 🤷. Note that we format GitHub repositories with italicized title and code for them to stand out: ``` _Title_ (`org/repo`) ```

* Edits to ERC This PR implements the suggested edits to the ERC, and adds a new section explaining the rationale why Nick's method cannot be used for generating the EIP-7702 authorization signature (since it was a question on Ethereum magicians). * Some small follow-up edits * Another small edit * Clarify reverts cause. Co-authored-by: Shebin John <[email protected]> --------- Co-authored-by: Shebin John <[email protected]>

The description included a forbidden word, remove it.

nlordell · 2025-07-17T13:08:50Z

First of all, thank you for the detailed review @SamWilsn :). I think I addressed all of your comments, let me know if there is still something left.

TBH, writing a good description is hard 😅 (its like naming things in software development). Anyway, open to more feedback if you have any.

frangio · 2025-08-04T02:08:07Z

ERCS/erc-7955.md

+0x0005: DUP3            # Stack: [32; salt; 0; 32]              | Push 32 to the stack
+0x0006: CALLDATASIZE    # Stack: [msg.data.len; 32; salt; ...]  | Followed by the calldata length
+0x0007: SUB             # Stack: [code.len; salt; 0; 32]        | Compute `msg.data.length - 32`, which is the length of


Is it acceptable for msg.data.length - 32 to potentially overflow?

It would cause the creation transaction to revert with "out of gas" (you would be copying ~2**256 bytes into memory), so it is acceptable IMO.

I saw your implementation in https://ethereum-magicians.org/t/eip-tbd-multi-chain-deterministic-deployment-factory/24998 and think that saturating subtraction is another way to do it. Although, it may cause "silent failures" where incorrectly encoded CREATE2 deployments lead to successful transactions deployments of contracts with empty code; so it violates the "law of least surprise" for me: I would be least surprised if incorrect encoding of parameters causes a revert. There is an argument to be made to make the reverts more explicit i.e. using the REVERT opcode and not rely on the fact that you will run out of gas when trying to copy 1000...000 bytes of calldata into memory, especially given the later will use up all transaction gas, and the former will not.

Yeah I'll give this a think, reverting if sub 32 is probably a better idea.

github-actions bot added c-new s-draft t-erc labels May 23, 2025

eip-review-bot added the e-consensus label May 23, 2025

rmeissner changed the title ~~Create erc.md~~ Multi chain deployment process for a permissionless contract factory May 23, 2025

eip-review-bot added the e-review label May 23, 2025

eip-review-bot changed the title ~~Multi chain deployment process for a permissionless contract factory~~ Add ERC: Permissionless CREATE2 Factory May 23, 2025

rmeissner marked this pull request as ready for review May 23, 2025 08:19

rmeissner requested a review from eip-review-bot as a code owner May 23, 2025 08:19

github-actions bot added the w-ci label May 23, 2025

777668z0 approved these changes May 25, 2025

View reviewed changes

github-actions bot added w-ci and removed w-ci labels May 26, 2025

poojaranjan mentioned this pull request Jun 6, 2025

ERC Blitz | June 10, 2025 ethcatherders/EIPIP#387

Closed

53 tasks

SamWilsn reviewed Jun 16, 2025

View reviewed changes

ERCS/erc-permissionless_create2_factory.md Show resolved Hide resolved

github-actions bot removed the w-ci label Jun 20, 2025

poojaranjan mentioned this pull request Jun 27, 2025

EIP Editing Office Hour Meeting 64 (EIP + ERC ) | July 08, 2025 ethereum/pm#1596

Closed

37 tasks

poojaranjan mentioned this pull request Jul 14, 2025

EIP Editing Office Hour Meeting 65 (EIP + ERC ) | July 15, 2025 ethereum/pm#1620

Closed

21 tasks

SamWilsn reviewed Jul 15, 2025

View reviewed changes

rmeissner and others added 9 commits July 16, 2025 08:16

Create erc.md

c1c57b6

Rename erc.md to erc-permissionless_create2_factory.md

015672e

Add discussion link

3301b08

Fix Minor Typo

5c908a0

Just fixes a small inconsistency where we were using `||` and `++` for byte concatenation. Prefer the former.

Fix Heading for 3rd Existing Method

61f5dd8

Add More Context about Using Private Key (#2)

8aa70a9

Minor Edits

463e786

- Remove duplicate linking to EIP-7702 (only first one should be linked) - Remove trailing whitespace - Fix spelling error

Fix Requires Reference

e62c635

Requires should be _just_ numbers without the `EIP-` or `ERC-` prefix. This causes issues with the generated HTLM and proofer.

Title Case Sections

93d28cf

Fixed some section titles that weren't titlecased correctly.

nlordell and others added 5 commits July 16, 2025 08:16

Typos

959e430

Use eip number

e26a448

Fix Section Lint

9c5597a

The ERC lint does not like additional top level sections, so move the "custom" forwards compatibility section into a subsection of the backwards compatibility

nlordell force-pushed the permissionless_factory branch from a16dcd3 to e6cb880 Compare July 16, 2025 06:19

nlordell and others added 2 commits July 17, 2025 15:04

Fix Description

396f1d5

The description included a forbidden word, remove it.

poojaranjan mentioned this pull request Jul 28, 2025

EIP Editing Office Hour Meeting 67 (EIP+ERC), July 29, 2025 ethereum/pm#1633

Closed

frangio reviewed Aug 4, 2025

View reviewed changes

frangio mentioned this pull request Aug 4, 2025

Add EIP: Deterministic Factory Predeploy ethereum/EIPs#10092

Merged

777668z0 approved these changes Aug 4, 2025

View reviewed changes

lightclient approved these changes Aug 11, 2025

View reviewed changes

lightclient closed this Aug 11, 2025

lightclient reopened this Aug 11, 2025

lightclient merged commit c4b846e into ethereum:master Aug 12, 2025
23 checks passed

Cassieminkus1 approved these changes Aug 13, 2025

View reviewed changes

777668z0 approved these changes Aug 13, 2025

View reviewed changes


		#### 1. Nick's Method

		Use Nick's method to randomly generate a signature for a transaction without [EIP-155](./eip-155.md) replay protection that deploys the CREATE2 factory. Nick's method ensures that there is no known private key for an account that deploys the CREATE2 factory, meaning that the resulting contract will have a deterministic address and code on all chains. This strategy is used by the _Deterministic Deployment Proxy_ (`Arachnid/deterministic-deployment-proxy`), one of the most widely used CREATE2 factory contracts.

	- Reverts due to alternative gas schedules make the CREATE2 factory no longer deployable.
	- Reverts due to alternative gas schedules making the CREATE2 factory no longer deployable.

	- Reverts due to alternative gas schedules make the CREATE2 factory no longer deployable.
	- Reverts, due to alternative gas schedules, make the CREATE2 factory no longer deployable.


		#### 2. Secret Private Key

		Keep a carefully guarded secret key and use it to sign transactions to deploy CREATE2 factory contracts. The resulting contract will have a deterministic address and code on all chains where the first transaction of the deployer account is a CREATE2 factory deployment, which can be verified post-deployment to ensure trustlessness. Additionally, this method does not have the same gas sensitivity downsides as Nick's method, as the private key can sign a creation transaction with appropriate gas parameters at the time of execution. This is the strategy used by the _Safe Singleton Factory_ (`safe-global/safe-singleton-factory`) and _CreateX_ (`pcaversaccio/createx`).


		One issue with this method is that because the `DEPLOYER_PRIVATE_KEY` is public, anyone can sign alternative delegations or transactions and front-run a legitimate CREATE2 factory deployment. We consider this to not be a serious issue however, as:

		1. Doing so does not prevent future deployments - meaning that an attacker can only delay the deployment of the CREATE2 factory with a sustained attack at a gas cost to the attacker.

Add ERC: Permissionless CREATE2 Factory #1052

Add ERC: Permissionless CREATE2 Factory #1052

Uh oh!

Conversation

rmeissner commented May 23, 2025

Uh oh!

eip-review-bot commented May 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

File ERCS/erc-7955.md

Uh oh!

Uh oh!

github-actions bot commented Jun 20, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nlordell Jul 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nlordell commented Jul 17, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nlordell Aug 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

eip-review-bot commented May 23, 2025 •

edited

Loading

File `ERCS/erc-7955.md`

nlordell Jul 15, 2025 •

edited

Loading

nlordell Aug 4, 2025 •

edited

Loading