[Discussion] [OBRA] Cross-Chain Signers Synchronization for Multi-sig Wallets

Proposals Phase 0: Discussion
1

[Discussion] Cross-Chain Synchronization for Multi-sig Wallets

Authors:

Created: 2024-08-28

Abstract

This proposal introduces a new approach to creating and managing multi-sig wallets across different Layer 2 (L2) networks, enhancing the user experience. When the configuration of the master wallet on the Ethereum blockchain is changed, the corresponding changes of the owners set are automatically across all dependent wallets on the L2 networks. The update process requires a valid zk-proof to confirm the new signers.

The final solution will include a ready-to-use safe module, along with full-cycle integration into the proving protocol, covering proof building and verification.

Proposal types

Other SEPs

Proposal details

Purpose and Background

This proposal aims to enhance the user experience in managing cross-chain multi-sig accounts. Currently, when users want to change a signer in such a wallet, they must manually create, sign, and approve the same transaction across all blockchains or rollups where the wallet exists. This process requires the presence and action of all signers throughout and incurs gas fees on each blockchain or rollup.

This initiative proposes using a zero-knowledge proof approach to propagate updated signers across all protocols with a single action.

Effects and Impact Analysis

Pros:

  • Provides a reliable synchronization method that improves user experience.
  • Reduces the risk of human error.
  • Advances in the development of omni-chain architecture.
  • Requires less or the same amount of gas.

Cons:

  • Requires an additional module.

Risks:

  • The Modules allowed to modify Owners set have the highest access level to the Safe account, so a proper audit is crucial.
  • Implementation complexities due to the different configurations of the Safes.

Implementation

In the context of the interchain sync, there is a master chain (the preferable options are the Gnosis Chain and the Ethereum Mainnet) and several follower chains (such as Arbitrum, Polygon, and others).

The trustless sync mechanism will consist of several parts:

  • The off-chain indexer of the master chain
  • The off-chain zk-proving part (includes the multi-sig verification circuit)
  • The endpoints on the follower chains

Integration with the Safe contracts

The integration with the Safe contracts will be done through a Safe module that will manage the zk-proof verification and trigger Safe’s OwnerManager to apply the verified changes in the multi-sig configuration.

Open Questions

We can implement the module in three different ways, and each will require a different amount of resources.

  • Separate module

    We can implement our module as a separate app, with its GUI and repository inside our Github org. This is the most resource-demanding option since it requires us to build an additional UI part of the module.

  • A Zodiac module

    The module can be implemented as part of Zodiac library. In that case, it will become a standalone repository in the Gnosisbuild Github org. This approach will allow simple integration with different DAO instruments implemented by Gnosis Guild.

  • A Safe module

    The module can be implemented as part of the Safe Modules repository. This approach will allow integration with Passkeys-based modules in the same repository.

Funding Request

Separate module

$45,000 = $35,000 core functionality + $10,000 UI part

A Zodiac module

$35,000

A Safe module

$35,000

Upfront Funding

Ideally, 100% in order to fund the audit. Can do in installments of 50% as well.

Metrics and KPIs

:compass: We are working on Dune visualization and are going to add it in this section before the start of voting for the proposal

  • Number of manual transactions changing the Owners set on follower networks
  • Number of Successful Account Synchronizations
  • User satisfaction rating
  • Security incidents reported

Timeline and Milestones

Phase I. Proving in testnets

  • 7 weeks: Design and implementation of the threshold multi-sig verification circuit
  • 4 weeks: Implementation of indexers and provers. Provers management CLI development.
  • 2 weeks: Deployment of testnet follower chains verifiers. Integration of verifiers with the testnet Safe contracts.

Phase II. Distributed proving in testnets

:compass: Duration of this phase depends on how the module will be presented to the end users.

  • 3 weeks: Implementation of intermediate verification strategies and fault-tolerance algorithms of proof aggregation.

  • Separate module

    • 4 weeks: UI for the module.

  • A Zodiac module

    • 2 weeks: integration with the Zodiac library

  • A Safe module

    • 2 weeks: integration with the Safe Modules repository

Phase III. Distributed proving in mainnet

The timelines of this phase will depend significantly on the security audit, so for now, we will only describe the intermediate steps.

TBD (est. 5 weeks): Deployment of the mainnet follower chains verifiers and integration of

the verifiers with the mainnet Safe contracts.

Team

Copyright

Copyright and related rights waived via CC0. Code open source with MIT license.

2 Likes
2

Hey @vadimicus, thank you for taking the time to submit this proposal. Your proposal will be evaluated in Season 4 / Sprint 1. For more details on timelines, please check out this post.

Action items: None for now.

1 Like
3

Hi @vadimicus!

Could you elaborate more about potential risks involved? Very curious

4

Sure, thank you for your question!

There are limited risks. In addition to those already mentioned in the proposal (e.g., the modules allowed to modify the owners set have the highest access level to the Safe account, making a proper audit essential; and implementation complexities due to the different Safe configurations), there are general risks associated with ZK, specifically:

  • Risks related to incorrect execution of the setup ceremony
  • Risks stemming from an incorrect choice of security parameters

However, it’s important to note that these are theoretical risks tied to the use of ZK proofs, and they can be fully mitigated through correct implementation of the proving mechanisms.

This will be ensured through thorough audits, which are already part of the proposal’s plan.

In summary, we can mitigate all these risks by adhering to well-established security protocols.

1 Like
5

Thank you for your reply @vadimicus!
Looks reasonable.

Also, another question:
How would you describe a good use case for your solution?

6

Thank you for you questions @nebula

One obvious use case is family offices and funds. Imagine a multi-sig that requires signatures from 7 partners. With the current Safe solution, if you’re working across three different chains, you’d need a total of 21 signatures. Coordinating that, especially across different time zones, can be challenging.

Our solution simplifies this by reducing the number of actions needed—just one signature from each participant. This:

  • Significantly improves the user experience (less coordination needed)
  • Lowers costs by reducing transaction fees.
1 Like
7

Thank you @vadimicus, this makes sense. No more questions from my side yet

8

Hey @vadimicus, I believe our teams could have great synergy. I’m creating a Telegram group to discuss it further.

1 Like
9

Thank you!

Let’s chat!