One of the few disadvantages smart contract wallets (Safes) have over EOAs is that they are tight to a specific network. While it is (in some cases) possible to create the same address on another network it will still be 2 completely independent Safes. After updates/ changing the owner structure those Safes can have nothing to do with each other.
I am making here a proposal that would allow a Safe on Network A to control/ receive assets on any other chain that is connected via an “AMB bridge” (arbitrary message bridge, a bridge that is generalized enough to send arbitrary messages from 2 accounts on 2 chains to each other). For each other chain, a (counterfactual) Safe address can be calculated that is based on:
safe address on source chain, source chain ID, target chain ID, bridge contract. (alternatively the bridge contract alone could contain information about source and target chain)
In this proposal the “executeTx” function of the Safe would get an additional field: chainID (or bridge contract). However - the idea to have deterministic representations on other chains that are controlled by a Safe on a source chain is also possible without this.
In the given example one could send tokens on chain ID100 to the Safe on Chain ID 1 by sending the tokens to the counterfactual address (0x002 on ID 100) even though this contract does not yet exist.
Note further - 0x002 could be set up in a way that it can be exclusively controlled by 0x001 via the bridge. However - 0x001 could also set something like a session key that would be allowed to do transactions directly.
I recently did the whole process of creating Safes for 1Hive Gardens on 3 other networks with the same address as our home Safe on Gnosis Chain… not a friendly experience and like you said they aren’t actually related to each other in way.
Being able to bridge tokens between networks through our home safe would be awesome.
Separately but related, it’d help if there was an easy interface for setting up your Safe on multiple networks with the same address - even if they couldn’t be controlled by the safe on the home network… just to simplify holding tokens on multiple networks.
Framing this differently EOAs got people used to tightly coupled signing and address. Contract wallets gets rid of this coupling.
Whilst still possible to have a contract wallet at the same address per network via create2 deployment, and to have the same verification logic shared between them, it is now a choice.
Eg one can choose looser restrictions on L2 wallets than L1.
“After updates/ changing the owner structure those Safes can have nothing to do with each other.”, I agree that if an owner gives away ownership of their contract wallet on one rollup and not another, this is not an ideal configuration for a user to create.
I feel that using multiple contract wallets on different chains needs an overarching manager tying them together. Perhaps wallet apps do this for users, implementing transfers on different chains (txs signed per chain id).
The benefits that the proposed Safe Grant Program tends to bring are some good ideas that would enhance SAFE ecosystem in general
I hope we could see this improvement in the nearest future
However, I would like to share that it is still possible to have same Ethereum SAFE address on multiple chains (this is for those who are not aware)
Short story:
Some mistakenly sent L2 and/or other side chains’ tokens to their Ethereum SAFE and that prompted the Safe team to bring up a recovery plan and that led to using same Ethereum SAFE address to create Safe on L2 and/or other side chains
It is ONLY presently possible to deploy Ethereum SAFE address on other L2s and/or side chains (i.e used same address on Ethereum safe to create Safe on other chains)
…but it is NOT presently possible to use SAFE address on L2 and side chains to create Safe on Ethereum or fellow L2 and/or side chains
NOTE: This was ONLY recommended for recovery purposes.
L2 or other side chains SAFE created using existing Ethereum SAFE address were not fully supported
Here is a video tutorial that guides on how to deploy Safe on L2 and/or other side chains using existing Ethereum SAFE address
I have used the Safe deployed on other L2s using existing Ethereum SAFE address and the major issues faced are:
Tokens still appears in my SAFE for many minutes after they have actually been sent out (but Refreshing the web page solves this)
Other than Gas Fee tokens like MATIC, XDAI, AETH, OETH, Some other ERC20 tokens doesn’t show deposit history even though they’re well credited to my SAFE
Please note my proposal is different from deploying a Safe with the same address on different networks.
The issue here is, that those are still independent Safes. So if e.g. you change an owner on network A it will not have any effect on network B. In my proposal the idea is that you have a Safe on network A but this Safe controls proxy Safes on all other networks. So if you change the owner structure on network A you in a way change the owner structure on all networks. Please also note that the addresses on all the different networks will be different.
The downside of this approach is that it will be dependent on the existence (and the security) of a bridge between two networks.
Multi-network Safes are an important feature to move this ecosystem to the next level for individuals and organizations. I’m glad to this is a focus.
Would it be possible to build a Safe that has the same address across networks AND the properties of each Safe can be updated by the mainnet Ethereum network by building this in multiple versions?
Having the same address across networks would be great in terms of UX. This could potentially help users new to layer 2s (L2s) understand and visualize how assets are moving across networks from “one account”, from a UX perspective even though multiple accounts are created across networks.
Features
v1 – Deploy Safes across networks with the same address.
Users would still need to update Safes properties manually across networks.
The UX in the app and documentation would clearly guide users through this.
v2 – Build bridge for mainnet Safe to update properties for Safes across other networks.
The mainnet Safe would automatically update Safes with the same address across networks
I would be interested in more details for this point.
For me personally the primary advantage is that for most users it is less error prone when receiving funds. But besides this specific use case I don’t see that many UX benefits.
From the technical point of view I see many disadvantages in having the same address:
it is not possible on all networks, therefore exceptions to this become even more confusing
same addresses require way more security considerations (replayability, undeployed or uninitialized contracts on new networks, nonce collisions).
it is quite complex (and maybe impossible) to keep Safe configurations in sync across network
A point that @lukas brought up before was that the address concept should be elevated to a higher level. Or if we combine it to the concept proposed by @koeppelmann it would be on the chain where our main Safe is (e.g. Mainnet). On that chain we have a logic to look up the addresses on all other networks. There are already solutions for this (looking at you ENS).
Additionally to this not depending on the same address allows to add support for non-evm networks at some point. I.e. it would be possible to use an AMB to Solana to control a contract on Solana from your Ethereum mainnet Safe.
One point that in my opinion still needs to be improved (and I know that Gnosis is working on this) is the trust model around bridges. Else this is a single point of failure that is controlling quite a lot of accounts.
I’m not sure there’s much value in a Gnosis Safe that simply controls Safes on other networks if they have different addresses, especially if it doesn’t provide a bridge either.
Seem like it’d be more valuable to have an interface that makes it easy to set up your Gnosis Safe on other networks with a matching address and with the same existing settings (not sure if that 2nd part is possible or if you can only match the settings at safe creation).
The bridge apps in Gnosis work nicely already. To me the pain point of different addresses on different networks is bigger than the pain point of needing to approve settings changes on multiple safes at once if you’re on multiple networks.
Thank you for explaining these challenges clearly!
Separate addresses make sense
After learning of these tech and security issues it makes to not have the same address across networks. Even if you can re-use the same address on 8 out of 10 networks, the UX still needs to clearly solve for the 2 other networks as stated above.
The main UX case I’m thinking of is receiving assets and keeping track of multiple wallet addresses for account management purposes. Account management is useful with the current EOA architecture because a user can copy and paste the same address across blockchain explorers and other tools.
ENS linking
Attaching an ENS domain to the mainnet Safe, e.g. adamhurwitz.eth, that is the same “vanity domain” across deployed networks seems like a potentially great UX solution if possible.
E.g.
adamhurwitz.eth is set as the ENS domain for my “main” Ethereum Safe.
I deploy safes to Polygon and Solana.
You send me ETH to adamhurwitz.eth on Polygon
a. You switch your MetaMask to Polygon network
b. You send ETH to adamhurwitz.eth
I understand this is trying to solve the problem where people assume that a Safe like an EOA will have the same address across networks but feels a bit dangerous to then assume all chains will have the same address and this feels like it will have more confusing edge cases and the possibility of more mistakes made.
A silky smooth ux with using create2 in the background could be quite nice though
Side thought: I wonder if there could be a safeReceiveErc20 function that could be added to prevent tokens getting lost , would have some odd ux though with approvals and ui integrations.
One way to improve the workflow would be to use a pull model instead of a push model.
So instead of “transaction on chain A triggers message on chain B”, it’s “transaction on chain B synchronously reads chain A” (eg. through a Merkle proof, or in the future this could be batched with some KZG or SNARK or other scheme)
This still has the same key property: safes live on chains B, C, D… but the validation rules live on chain A, so you only have one copy of the validation rules that needs to be edited, but it has a number of important benefits:
Transactions are faster: there is no asynchronous step required, it’s all one single synchronous transaction on chain B
Avoid spending gas on chain A - really important because I expect many people will want to have the “home” of their safe be ETH layer 1, where gas will be far more expensive
Avoid UX and economic complications of paying for gas on multiple chains
Right - this is undoubtedly a good improvement for the use case in which EOAs are the owner of a Safe. As the Safe also can have contracts as owners (either e.g other Safes or even e.g. a DAO with arbitrary complex decision logic), I think this can not be used in all cases.
For the EAO owner use case the flow would be like:
read owner and threshold from a block on a master chain that is not older than x
if you provide signatures from those owners you can execute from the sub-safe
Would transactions necessarily be faster with a pull model? I’m thinking of situations where chain B is blocked or lagging in making transactions because it has to wait to pull and sync.
It seems the security benefits of a pull model would still be a major advantage. That is making sure each chain has the correct state.
Would transactions necessarily be faster with a pull model? I’m thinking of situations where chain B is blocked or lagging in making transactions because it has to wait to pull and sync.
If you just changed the account owners, then you would have to wait some time for the changes to propagate. But transactions themselves should be instant, as you can always prove a slightly older state (though there would have to be some limit to this, so that key revocations can actually take effect)
It’s also worth noting that theoretically this works not just for EOAs, but also for any pure-function-controlled account, though that would have to be standardized.
Hey guys, I got referred to this problem and wonder if what we’re building at Peanut would help here. I think it would be useful for 1-of-n safes, but I’d like input if it’s helpful in a more general way.
It seems like the main problem is that Safes are not guaranteed to have the same address across chains, and that mishaps like the Wintermute mishap are best avoided.
At Peanut we’re developing the Smart Cheque, an abstraction that lets you e.g. create address-agnostic & chain-agnostic transfers. The way this would work is you create an initial secret-protected deposit on chain A. Then, from chain B, the target gnosis safe initiates a transaction to claim the deposit. This would bridge the funds over Axelar (or another AMB), and they’d then arrive with no possibility of getting the address wrong.
The advantages of this:
can’t get receiving address wrong
Disadvantages:
2 step process (1. create deposit & 2. claim deposit)
if it’s a simple single-secret protected deposit, the person with knowledge of this secret could “steal” the funds - this is problematic for Safes with more than 1-of-n trust assumptions
Thoughts? In principle you could have multi-sig protected deposits, but I wonder how cumbersome that would be.
Lovin’ the general idea of abstracting a single ENS name to an existence on whatever EVM-compatible chains that owner wants to publicly link to that ENS.
But there have been so many ideas & side comments in this thread since January that I am unsure what the latest proposal/consensus is.
Trying to understand why Safe refuses to make deployment of the same address on multiple chains easily available…
While it can potentially have a usecase to have different addresses on different chains, or the logic that deployment on different chains is just optional…
on the other hand it would be VERY beneficial to at least have the option to deploy on the same address on any other EVM chain, which currently is NOT available via graphic UI
Please could you address the security issue you state usually? While the following scenario is definitely possible: “Alice deploys a Safe on Ethereum Mainnet only. Thereafter Bob deploys Safes on multiple chains with the exact same address as Alice Mainnet Safe. An unsuspecting user could now assume, that all of the addresses belong to Alice and therefore sending funds to the wrong person.” Would this example be the risk you guys are talking about? Or is there something else more severe?
And back to the above example: how do other contract wallets manage this issue? e.g. Argent doesn’t even deploy on any other chain than ETH Mainnet & zksync Lite.
The issue with different signing keys on different chains is real, can confirm - we are using Safe for community investments! Anyways, Safe is as well a decent solution as personal vault, here it makes definitely sense to at least have the option to deploy on the same address on multiple chains by default.
(I will add if I remember any)
, would have some odd ux though with approvals and ui integrations.