feat: Add Eclipse Testnet v1.3.0 contracts

[hapetherw]

• Relevant issue: [New chain]: Eclipse Testnet #375

[nlordell]

Hmm, some of these contracts appear to be on the wrong address. For example the GnosisSafeL2 is on 0xE51abdf814f8854941b9Fe8e3A4F65CAB4e7A4a8 instead of one of the two canonical addresses.

[hapetherw]

@nlordell Thanks for your prompt comment.
I have included the address 0xE51abdf814f8854941b9Fe8e3A4F65CAB4e7A4a8 in the gnosis_safe_l2.json file.
While my understanding may be incomplete, I would appreciate further clarification regarding the discrepancy between this address and the canonical addresses for GnosisSafeL2 contracts.

[nlordell]

While my understanding may be incomplete, I would appreciate further clarification regarding the discrepancy between this address and the canonical addresses for GnosisSafeL2 contracts.

We use deterministic deployments for the Safe contracts. The contract added to the JSON is on a different address than one of the two canonical addresses (you can find them by looking at the other GnosisSafeL2 addresses in the same file):

• 0x3E5c63644E683549055b9Be8653de26E0B4CD36E
• 0xfb1bffC9d739B8D520DaF37dF666da4C687191EA

This indicates that either:

• The contract was deployed from a different create2 deployer contract
• A different salt was used when deploying
• The bytecode doesn't exactly match the expected GnosisSafeL2 contract.

Seeing as, for example, MultiSend contract ended up on the canonical address, I imagine that this indicates a bytecode mismatch.

[hapetherw]

This indicates that either:

The contract was deployed from a different create2 deployer contract
A different salt was used when deploying
The bytecode doesn't exactly match the expected GnosisSafeL2 contract.

Thanks for your clarification, now i got your point.
Because I used this branch to deploy safe contracts on Eclipse Testnet.
https://github.com/safe-global/safe-smart-account/tree/c36bcab46578a442862d043e12a83fec41143dec
I believe it's likely the main reason, i would like to use the current main branch to redeploy contracts.

[nlordell]

I believe it's likely the main reason, i would like to use the current main branch to redeploy contracts.

You should use the v1.3.0 tag since you are adding addresses for the v1.3.0 deployments. In order to use more recent contracts, you could use the v1.4.1 version and add the addresses to the src/assets/v1.4.1 directory instead.

The contracts on the main branch have non-trivial and unaudited changes, and don't get added to this deployments repository.

[hapetherw]

@nlordell I updated contract addresses using v1.3.0 tag, could you please help to review this?

[nlordell]

Thanks! Looks good over all, just SignMessageLib is still not deployed to the expected address.

[hapetherw]

@nlordell I think deploying the safe singleton factory contract to the Eclipse testnet first, followed by the Safe core contracts.
This ensures all contract addresses match as intended.
safe-global/safe-singleton-factory#366
Could you kindly consider processing this open issue?
Thank you for your time and assistance.

[nlordell]

So, using the Safe singleton factory is the preferred way, but using the “standard” create2 deployer should also work. In fact, all of the other contracts landed on expected addresses with the exception of SignMessageLib which indicates that something is different with that contract specifically.

[hapetherw]

@nlordell Okay, I have redeployed the contract addresses and confirmed that all contract addresses match the expected configurations.

[nlordell]

Thanks, looks great :)

[hapetherw]

@nlordell Any approximate timeframe to publish new release version of the repo including this PR?
After that, i could be able to operate the safe-infrastructure repo on my local end.

[nlordell]

@mmv08 seems to have released this with 1.33 already :)

[hapetherw]

Ok thank you, i am moving on to the next step.