[OP Stack Deployment] How to change ownership of the Rollup to different address after deployment

[priyanshuthapliyal55]

Did you check the documentation?

• Yes

Did you check for duplicate questions?

• Yes

Issue Description

I have deployed L2 Rollups with a deployer account now after deployment i want to change admin address to a diffrent address after deploying the L2 Rollups is there any way to do that?

Logs

No response

Additional Information

No response

Feedback

No response

[Wazabie]

Hey @priyanshuthapliyal55 what addresses would you like to chance specifically? (e.g GS_BATCHER_PRIVATE_KEY, GS_PROPOSER_PRIVATE_KEY & GS_SEQUENCER_PRIVATE_KEY)

[priyanshuthapliyal55]

Hi @Wazabie if possible i want to change admin addresses like the i deployed contract using a deployer account which i have mentioned in proxyadmin owner , superchain config owner etc in deploy config and please tell me how can i change these addresses as well (Batcher,proposer and sequencer)

[Wazabie]

To rotate the addresses from the OP Stack perspective, you need to redeploy the contracts with different public address values.

• First, generate the new addresses/keys

• Second, update/redeploy ( config.sh with the new keys, initialize and redeploy the L2OutputOracle. Note that you can also go with Deploy.s.sol but it would redeploy all of the contracts. No issues with that, but also not cost efficient.)

• Call initialize function (in L2OutputOracle) to set the new address ­_proposer on L1 (This initialize function can only be set on initial deployment, that's why a redeploy is necessary, specifically for this contract)

• Call setBatcherHash function (in SystemConfig) to update Batcher address on L1

• Call setUnsafeBlockSigner function (in SystemConfig) to update Sequencer address on L1

It is advisable to use multisig/hardware wallet with the above in production.

[priyanshuthapliyal55]

Hi @Wazabie if possible i want to change admin addresses like the i deployed contract using a deployer account which i have mentioned in proxyadmin owner , superchain config owner etc in deploy config and please tell me how can i change these addresses as well (Batcher,proposer and sequencer)

My main goal is changing admin address like guardian , challenger, proxy admin owner and superchain config owner

[Wazabie]

Hi @priyanshuthapliyal55 , all the values you mentioned can be changed by either calling a setter function (if available) or by initializing (hence you'd need to redeploy) the corresponding contract. I am currently going through them. I'll close this discussion I will provide the detailed info in our parallel thread.

[priyanshuthapliyal55]

Hi @priyanshuthapliyal55 , all the values you mentioned can be changed by either calling a setter function (if available) or by initializing (hence you'd need to redeploy) the corresponding contract. I am currently going through them. I'll close this discussion I will provide the detailed info in our parallel thread.

Great 👍

[atenjin]

To rotate the addresses from the OP Stack perspective, you need to redeploy the contracts with different public address values.

• First, generate the new addresses/keys
• Second, update/redeploy ( config.sh with the new keys, initialize and redeploy the L2OutputOracle. Note that you can also go with Deploy.s.sol but it would redeploy all of the contracts. No issues with that, but also not cost efficient.)
• Call initialize function (in L2OutputOracle) to set the new address ­_proposer on L1 (This initialize function can only be set on initial deployment, that's why a redeploy is necessary, specifically for this contract)
• Call setBatcherHash function (in SystemConfig) to update Batcher address on L1
• Call setUnsafeBlockSigner function (in SystemConfig) to update Sequencer address on L1

It is advisable to use multisig/hardware wallet with the above in production.

Hello, from your steps, I have a quesion:
For current op-contract code, the proposer is already a storage, not a const value, so why do I need to redeploy the contract rather than add a modify proposer function then update contract, after update the storage then set back to the old implemented contract?
I think this may be more easier?

Meanwhile in your steps, the proxy contract already inited when first deployed. So it can not be called again even you deploy a new implemented contract. Based on the context I think we are talking about the following choice:

1. decide to use a new proxy contract: I think for production rollup we can not choose this, first how to process the old state root is a problem, second 3rd parity would not receive you change this contract address
2. use the current proxy contract but want to point to the new deployed implmeneted contract and call initialize. Obviously we can not do this, for current proxy contract already call this function before and set the flag, it can not be called again.

Thus, I think the only way is add modify function