feat(op-deployer): add prepare command to predict L1 addresses by 0xiamflux · Pull Request #21560 · ethereum-optimism/optimism

0xiamflux · 2026-06-24T22:43:15Z

Summary

Adds the prepare command to op-deployer. prepare predicts a chain's L1 contract addresses without broadcasting anything.

What it does

For each chain in the intent, prepare:

Reads intent.toml and state.json from the workdir.
Forks the live L1 (--l1-rpc-url) and dry-runs OPCM.deploy() through the DeployOPChain script, using a NoopBroadcaster so nothing is written to L1.
Records the predicted addresses into state.json.

The dry-run runs as the address derived from --private-key. Predicted addresses are deterministic in the sender and salt mixer, so the prediction matches the real deployment.

State changes

ChainState gains a Deployed bool to distinguish predicted addresses (prepare) from broadcast addresses (apply/continue). shouldDeployOPChain and contract verification now skip predicted-only chains, so running apply over a prepared state deploys the chain rather than treating the prediction as finished.

Test Plan

Test config validation rejects a missing private key, a malformed private key, and a missing L1 RPC URL.
Test the prediction input holds the correct values derived from the state.
Test prepare fails when the intent is missing the OPCM address or superchain config proxy.
Test predicted addresses are updated in the state with the flag Deployed=false.

Closes #20908

…PChain to check the Deployed flag

…deployments.

to false

0xOneTony · 2026-07-03T14:23:58Z

+// predictChains predicts the L1 addresses for each undeployed chain in the intent
+// and records them as not deployed. Chains that have been deployed are skipped so a


can we have more than 1 chain defined in the intent?

Yes, that's possible.

0xOneTony · 2026-07-03T16:48:07Z

 		},
+		{
+			Name:   "prepare",
+			Usage:  "prepares a chain deployment by generating the genesis artifacts",


should we also mention that prepare should be called after init and that it should not be called with apply?

Yes, passing a prepared state/intent through the apply pipeline can create unsupported scenarios so we check for those to error out clearly on apply. So I think it's worth to callout this in the Usage.

Enforced that here and documented it here

0xOneTony · 2026-07-06T11:29:36Z

+	}
+}
+
+func Prepare(ctx context.Context, cfg PrepareConfig) error {


what happens if someone runs init -> prepare -> apply ? would our state.json be overwritten? maybe we should have some way of preventing apply if we have already called prepare or do you think this is not an issue?

same question but what happens if init -> prepare -> init?

Addressed here by checking for Prepared flag in apply pipeline, we error out if it's there, it's backward compatible as any state missing the flag is assumed to be produced by an older pipeline and defaults to false.

0xOneTony · 2026-07-06T11:35:58Z

+// pinned during the prepare dry-run, keeping the predicted L1 addresses valid
+// across the relevant stages of the permissionless pipeline. A nil L1PredictSenderAddress
+// means no sender was pinned, so any deployer is accepted (older pipeline).
+func (s *State) CheckL1PredictSender(deployer common.Address) error {


i think we should have something similar like we check the sender but for the opcm aswell, basically making sure that we use the same opcm for both prepare to calculate the addresses but also we use the same opcm for the actual deployment (continue)

Addressed here. Similar shape as the deployer's address check.

0xOneTony · 2026-07-06T11:45:54Z

+	intent, err := pipeline.ReadIntent(cfg.Workdir)
+	if err != nil {
+		return fmt.Errorf("failed to read intent: %w", err)
+	}
+
+	st, err := pipeline.ReadState(cfg.Workdir)
+	if err != nil {
+		return fmt.Errorf("failed to read state: %w", err)
+	}
+
+	if len(intent.Chains) == 0 {
+		return fmt.Errorf("intent has no chains to prepare")
+	}


noticed the apply pipeline enforces a few more checks like if the intent is valid, or the state version and chain id. If we end up using similar checks later in continue then maybe we should enforce them from prepare to make sure we can later actually call continue without issues, but wdyt?

Addressed here

Co-authored-by: 0xOneTony <112496816+0xOneTony@users.noreply.github.com>

bitwiseguy · 2026-07-07T20:12:13Z


+	// L1PredictSenderAddress is the address that performed the L1 deploy dry-run.
+	// It is used to verify that the same deployer address is used for the relevant stages of the permissionless pipeline.
+	L1PredictSenderAddress *common.Address `json:"deployerAddress,omitempty"`


This json key is inconsistent. Should we change it to predictSenderAddress to align with predictOpcmAddress below?

Addressed here

bitwiseguy · 2026-07-07T20:46:29Z

+// The OPCM, superchain config and salt mixer are taken from the committed intent
+// and state so the prediction matches the eventual broadcast. Role addresses are set to
+// placeholders since they are not relevant for the prediction.
+func makePredictionInput(intent *state.Intent, st *state.State, chain *state.ChainIntent) (opcm.DeployOPChainInput, error) {


This function duplicates much of makeDCI, and the two have already drifted: gas-limit defaulting here vs. raw thisIntent.GasLimit there, and Opcm/SuperchainConfig sourced from the intent here vs. from state there.

Could you modify the approach by introducing a helper buildDeployOPChainInput(proofParams, roles, opcm, superchainCfg, l2ChainID, saltMixer, gasLimit, chain) that makeDCI, makePredictionInput, and the future continue code all call, with each caller supplying its own roles/OPCM/superchain provenance? I think that would help ensure the prediction and actual deployment stay in-sync

Addressed here

bitwiseguy · 2026-07-07T21:15:52Z

+		GasLimit:          gasLimit,
+
+		DisputeGameType:              proofParams.DisputeGameType,
+		DisputeAbsolutePrestate:      proofParams.DisputeAbsolutePrestate,


Once #21588 lands, DeployOPChainInput will have a required StartingAnchorRoot field, and DeployOPChain.checkInput reverts with "startingAnchorRoot not set" when it's zero. So this code will need to be updated to include that new field.

0xiamflux added 6 commits June 23, 2026 16:37

feat: bootstrap prepare command

0ae8c01

test: minimal config test

e20b2a8

feat: add L1RPC flag for prepare

0000a76

feat: run the DeployOPChain script using a no-op broadcast

9e24fce

feat: save the predicted addresses to the state, update shouldDeployO…

696834e

…PChain to check the Deployed flag

refactor: source proofs params the same for both prediction and real …

7d2e21c

…deployments.

0xiamflux changed the title ~~feat(pcd): Bootstrap prepare command and predict L1 addresses~~ feat(op-deployer): add prepare command to predict L1 addresses Jun 25, 2026

0xCoati reviewed Jun 29, 2026

View reviewed changes

Comment thread op-deployer/pkg/deployer/pipeline/opchain.go Outdated

lumoswiz reviewed Jun 30, 2026

View reviewed changes

Comment thread op-deployer/pkg/deployer/prepare.go

Comment thread op-deployer/pkg/deployer/prepare.go Outdated

Comment thread op-deployer/pkg/deployer/state/state.go Outdated

0xiamflux added 2 commits June 30, 2026 20:55

feat: adds same sender enforcement for prepare pipeline

a4adb3b

feat: ensures a Create2Salt is set in prepare pipeline

12ce696

0xiamflux mentioned this pull request Jul 1, 2026

[PCD] Predict L1 addresses via dry-run #20908

Open

3 tasks

fix: addresses issue where older state files would decode Deployed flag

0155737

to false

lumoswiz reviewed Jul 1, 2026

View reviewed changes

Comment thread op-deployer/pkg/deployer/prepare.go

Comment thread op-deployer/pkg/deployer/pipeline/opchain.go Outdated

0xiamflux added 2 commits July 1, 2026 18:51

fix: use env.Deployer to skip the predict sender check

f33b90b

fix: skips prepare overwriting already deployed chains

d1cbed7

This was referenced Jul 2, 2026

feat(op-deployer): source permissionless deploy inputs from chain state #21610

Draft

feat(op-deployer): commit prestates before chain deploy #21611

Draft

fix: go lint

ff5dc3a

0xiamflux marked this pull request as ready for review July 2, 2026 13:55

0xiamflux requested review from a team as code owners July 2, 2026 13:55

0xOneTony reviewed Jul 6, 2026

View reviewed changes

0xiamflux and others added 5 commits July 6, 2026 13:30

Update op-deployer/pkg/deployer/state/state.go

998b5d7

Co-authored-by: 0xOneTony <112496816+0xOneTony@users.noreply.github.com>

refactor: update usage strings on apply and prepare

9fdcc02

refactor: checks for permissionless deployments in apply pipeline

6007778

refactor: add shared validation in apply and prepare

87ec575

feat: check for pinned OPCM before permissionless deployment

912381a

bitwiseguy reviewed Jul 7, 2026

View reviewed changes

refactor: rename json key to predictSenderAddress

ff6365b

refactor: add shared helper for DCI creation

a7d0950

		// predictChains predicts the L1 addresses for each undeployed chain in the intent
		// and records them as not deployed. Chains that have been deployed are skipped so a

Uh oh!

Conversation

0xiamflux commented Jun 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

What it does

State changes

Test Plan

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

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!

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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

0xiamflux commented Jun 24, 2026 •

edited

Loading