How can a Safe hold asset on multiple chains?

@wagame.eth, Richard Meissner, Safe co-founder, outlines some of the challenges here.

1 Like

I fully support the idea of a unified address across all the chains.

I was doing some resaerch previously:

BUT

Ultimately I do not know what is the best way.

I’m just signaling that SAME ADDRESS ON ALL THE NETWORKS would be super awesome, practical, much better for all the users.

In an ideal world I agree that having the same adress across all protocols would be great.

Given the technical constraints on some protocols, the next best solution seems to be to have a universal identifier like an ENS domain connecting 1 Safe account across many chains.

Basic questiion: which networks?

The non-EVM networks… Will they gain popularity? What are they? Is it just about EVM-compatibility or some other issues with the same addresses?

(I should probably read in detail the entire thread)

EVM-compatibility is a shelling point

My efforts to deploy same Safe and same contract on all chains: Deploying smart contract using CREATE2, bytecode, salt - getting different addresses on different chains? - Ethereum Stack Exchange

A bit of hassle.

Simple, naive solution

If you can explain in 1 plain sentence it is “easy enough to try”

Whenever you deploy a Safe, it deploys the same on all supported networks.

Something like this:

Me advising others about Gitcoin grant

Copy-paste from another forum, not everyone is Web3 native:

I’m keen to understand more, specifically which networks are not supported.


I understand better now:

I still would like to understand which networks are not compatible with CREATE2, different addresses and whether it would be UI / UX improvement.

I’m keen to understand more, specifically which networks are not supported.

The most prominent example is zkSync, but any type 3 or type 4 evm would pose this issue (see types of evms).

But even type 2 and 2.5 can pose these issues as the Safe singleton makes assumption about gas usage. We will remove this code, but this does not guarantee that the same singleton will be used on all chains.

A couple examples of this are for example BSC where some eips are not implemented (specifically EIP-2929 and 2930). Also on Ethereum Mainnet verbose event emission (which is used on the low gas networks to keep track of all interactions) is quite expensive.

As rollups come with the idea with being application specific it is a bold assumption to assume that all networks will work 100% the same (so type 1 evm).

whether it would be UI / UX improvement.

That being said having the same address on multiple chains is not only a technical challenge (actually this is probably the easier challenge), but a UX challenge. As the state of these Safes is separate you will experience state drift. Just because you own a Safe on one network you might not own it on another network, as owners change and different modules might be enabled.

This is what the proposal made here is addressing. How can we setup a system that works cross chain, where the user actually only has to know 1 address (the mainnet address and/or ens address). The rest would happen automatically.

Maybe to note: The proposal is not explicitly excluding deploying Safes on the same address on multiple networks, BUT it does not make the assumption that it is possible, because we believe a solution that works without this assumption is necessary.

5 Likes

For me this is a different discussion. This thread is less about how do we implement an interface for this and rather how would this look on the low level technical layer (i.e. contract level).

I agree a lot of things can be done on the interface level, but I would move this to a separate discussion.

1 Like

How do you get the block data? I know you can reconstruct it for a L2, but for other L1s you need a bridge anyway, right?

Hey @koeppelman, inspired by your proposal we have implemented a multi-chain aa wallet demo here. Where you can use one guardian to create an account on Mumbai or scroll and change your guardian, but still able to create a same address with the new guardian on another chain. Also when you change your guardian, the guardian info is changed simultaneously on both chain. You can find more design detail at there
We use layerzero as message bridge here. The same setting should also work on safe’s account too.

Should out to your proposal here! Let me know if there’s any feedback on our demo

1 Like

I created open info on Safe multichain account strategies. I’m happy to share write access for those who want to contribute.

1 Like

Hi everyone, I made a PoC of the push & pull flow. It is based on Hashi, an EVM hash oracle aggregator from Gnosis Chain.
In push flow, the main Safe on Goerli has to initiate a message with encoded function data (contract and function to call on destination chain) and call the message dispatching contract on source chain (Yaho). Hash of the message will be relayed to Gnosis Chain and stored in adapter contract. The counterfactual Safe or any account with message ID and original message can claim the message by calling Yaru, the message dispatching contract on the destination chain. Message will be executed by Hashi Module on behalf of counterfactual Safe.

In pull flow, the owner from the main Safe can initiate a message for a counterfactual Safe on behalf of the main Safe, by providing Merkle Proof of owners in the main Safe to an off-chain verifier. Owner on main Safe calls eth_getProof to get Merkle Proof of its existence in owner lists. Besides, the block hash of the corresponding block on Goerli is obtained from Shoyubashi (one of the contracts from Hashi). These two data are sent to an off-chain verifier to verify the proof. The merkle proof is verified by reconstructing the Merkle trie with storageProof and comparing the value of the node.

Information and video demo can be found in this blog post.

3 Likes

Another example from EthGlobal Paris that implemented a similar model to the “pull” model: sunflower | ETHGlobal

Accomplished through a zkp on the state proof (Axiom) + Optimism’s native L1 blockhash precompile (analogous to Hashi).

2 Likes

Thank you for sharing your and Gnosis’ Hashi prototype here @zeng!

I’d love your feedback, time permitting, if there are specific opportunities for builders to research, test, build on top, etc. with Hashi. Safe’s first wave 1 applications of its grants program are closing on Sep 6th. Wave 1 is focusing on allocating up to $50k in grants for teams to contribute to the ecosystem for 3.5 month planned projects. For example, there is a proposal, Multichain Safe App, looking to build multinetwork Safes with Wormhole’s bridging technology. I wonder if there is any alignment with Hashi here.

Great sir, i really like this