Safe Contract v1.4.0

Why not directly v2?

  • Safe Contract v2 include quite some breaking changes
  • Major contract changes are harder to audit
  • Major contract changes are not easily adopted by users and interface
    • Require more user education/ communication
  • Longer time until fully available
    • Prevents integration with upcoming improvements (e.g. EIP-4337)
  • No interface changes

What changes are part of v1.4.0?

A milestone is available to track the currently planned changes for this version on GitHub

Summary of the proposed changes:

Timeline

  • Collect feedback on the proposed changes in the next weeks
  • Start implementing changes in January 2023
  • Prepare audit of changes end of January 2023

Notes

  • The services and sdks should add support for the new version once it has been audited
  • It is not expected that the interfaces start immediately using the new version after the audit
11 Likes

Maybe some additional context:

There was some off-forum discussion if Feature request: Transaction meta data · Issue #331 · safe-global/safe-contracts · GitHub should be included in 1.4.0. The reasoning for not doing so is, that it would require an interface/abi change, which would make the adoption in the services and sdks harder.

1 Like

Seeing the createNetworkSpecificProxy addition.

Are there any plans in v2 or elsewhere to allow the same EOA to create the same deterministic address on all networks via create2?

This is a requirement for what we’re working on. Our users can’t tolerate separate wallet addresses on different EVM chains. Too much mental overhead.

Another question that came up was: “Does this mean there is no v2?”

We will also continue work on a v2, but this is a ways bigger change which needs to be taken way more carefully with more testing. The idea is to be more transparent on changes that are being planned/tested and provide “developer previews” on testnetworks.

The current factory has the createProxyWithNonce method which allows to create a flow where Safes for the same setup (including the owners) create the same address on different networks.

The challenge is that the Proxy Factory is not on the same address on all networks. This is being tackled by Use SafeSingeltonFactory by default for new deployments · Issue #460 · safe-global/safe-contracts · GitHub.

In general it is also possible to use a custom proxy/ proxy factory (e.g. the OpenZepplin Proxies or safe-factories/Safe_1_1_1_Factory.sol at master · 5afe/safe-factories · GitHub) with the Safe singleton.

1 Like

Got it, thank you!

I believe using your own proxies cause the Safe UI to not function correctly though. Maybe this has been resolved.

The challenge is that the Proxy Factory is not on the same address on all networks. This is being tackled by Use SafeSingeltonFactory by default for new deployments · Issue #460 · safe-global/safe-contracts · GitHub.

Any idea when this might be available? Q1 / Q2 2023 or later? We’re planning our 2023 roadmap but absolutely need same address on all chains.

1 Like

@Uxio do you know if this still is true. I know that on some networks we purely look for the Setup event/call and therefore any proxy should work.

After the audit was successful it should be available in our sdks and services (see timeline and notes). Even if our interface will not use it for creation of new Safes they should still be supported for usage.

1 Like

Sounds great, thanks @rimeissner! :pray:

It is fairly easy to do, but in my opinion, doing it leads to more complicated problems:

  1. Security settings sync across chains.
  2. Much bigger migration overhead due to more commitment to this cross-chain account
  3. It’s not always guaranteed that you’ll be able to deploy to the same address, like type 4 zkEVMs (zksync)

I’m curious whether you factored this in for your product and if yes, how you plan to deal with these issues. In my opinion, some mental overhead is way easier than dealing with the above.

1 Like

Where can v2 progress be followed, or even contributed to?
Or is this next in the pipeline?

That’s correct, we don’t force our proxies, you can use any proxy you want as long as it behaves in a compatible way, in that case the only thing missing on our API would be the proxy creation information as we only index our proxy factories.

1 Like

Probably more something to talk about in Safe Contract v2 - #5 by rimeissner

In general v2 is still in the stage of “What do we even need?” … Bigger updates bring quite some questions.

Feedback on proposed changes: I think separating this from V2 makes a lot of sense and getting it in sooner is ideal.

I’d love to help support making these updates in January or writing tests for them. Please add me to any issues I could take @rimeissner

2 Likes

I propose also getting JavaScript-related things in order in 1.4.0: JavaScript tooling overhaul · Issue #464 · safe-global/safe-contracts · GitHub

1 Like

We have generated the same addresses on several networks, but for e.g. Optimism and Avalanche this was not possible. Does it mean that with the v1.4.0 update (ETA?), this problem will be solved and the SafeSingeltonFactory solves this issue?

Is it possible to only launch Safes with the same address on the networks with the same Proxy Factory address, then update to v1.4.0 and then also launch the Safes with this address on the other networks which were not possible before?

For some networks it does (see GitHub - safe-global/safe-singleton-factory for a description why). But some networks require a change to the bytecode (e.g. zkSync) for these this will not solve the issues.

As the Safe contracts are security relevant the focus on making sure that the correct code is used by using a deterministic deployment factory (such as the Safe Singleton Factory) has a very high priority.

Creating Safes with the same address on multiple networks brings quite some UX challenges which in result can lower the overall security of the setup (i.e. Safe configurations that differ between networks or new networks that don’t support the Safe contracts yet).

1 Like

Thanks for the answer.

I also think that the same contract address on different chains is more of a solution for the unfortunate mixture of EOAs and CA with no way to tell them apart.
In our wallet development we originally implemented different EOAs on different networks to improve the privacy level, but had to give it up, once bridging became a thing.
With CA we also had problems that rewards were sent to the address on another chain. Lets hope that CAIPI-2 gets widely adopted and then we don’t have to worry about that issue so much anymore.

I see the current wish for the same addresses more from a usability perspective in a wallet, because right now the widespread use of EOAs makes CA - as Julien Niset says - “Second class citizens”.

I proposed a new issue for the v1.4.0 milestone: Add zksync as a compilation target · Issue #479 · safe-global/safe-contracts · GitHub

To make it clear, this doesn’t mean that Safe will support zksync with 1.4.0, it just provides Safe with such an option in the future.

The previous version couldn’t be compiled for zksync’s zkEVM due to some unsupported solidity properties (like .runtimeCode) and since we’re getting rid of these properties in 1.4.0, it makes sense for Safe to make it possible to target zksync zkEVM (perhaps other upcoming type 4 zkEVMs too).

4 Likes

This does not always work. I have examples of safes that are created with your factory, but they don’t work in the interface.
Maybe you can add an interface that allows you to add a safe to list?