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.
@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.
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.
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?
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).
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”.
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).