[Discussion] Anonymous multi-sig wallet with Semaphore Modules

Proposals Phase 0: Discussion
1

Authors: Jimmy Chu

Created: 2025-04-04

Abstract

Discuss the community need and feasibility of developing anonymous multi-sig wallet using Semaphore.

Proposal types

SEP ORBA type

Proposal details

Hi SAFE community, I would like to showcase a PoC I recently made and want to get the feedback from you in the forum here if it has any merit to bring some of the project features into SAFE wallet as a plugin. If yes, then we will draft up a proposal and proceed further.

Purpose and Background

Semaphore is a protocol that allow a user to prove their group membership and send signals, such as votes or endorsements, without revealing their original identity using zk proof. Furthermore, Semaphore checks that a member only send one signal on a given scope within the group. This is a project developed and maintained by Privacy and Scaling Exploration team.

So if we have use a transaction hash as the scope, a signal from a member can be seen as an approval (signature) for the transaction. When enough signals have been made, the transaction is approved and can be executed.

I recently completed such a PoC on integrating Semaphore as two smart account modules (a validator module and executor module) and could make a smart account behaves as an anonymous multi-sig wallet.

Effects and Impact Analysis

The benefit of such multi-sig account is giving additional privacy to the account members and prevent them from being targeted by hackers or social attacks (think about the multi-sig whale accounts). We still need one EOA as the owner of the smart account and that could be a totally new EOA.

With the proposal passed and the implementation completed there will be a new plugin users could choose to install in their SAFE wallet. With the plugin and extended UI (see below for discussion), they can sign a transaction using a Semaphore identity.

The risks is that users have an additional Semaphore identity/private key need to take care of.

We can then measure the impact by number of accounts that install this plugin and use it to sign transactions.

Implementation

Does the implementation of the proposal require new code? How is the security of the code ensured? How is the implementation of the proposal carried out?

Own implementation but with funding (how much % to implementation)

The implementation will need new code with funding support from SAFE dao. Both I and PSE team will be involved in the development work.

Open Questions

I would like to get the feedback from you, particularly on the following:

  1. Is this something SAFE wallet community also feel valuable and something that could make into a formal proposal to support its development?

  2. I am not sure if an ERC7579 Executor module is something SAFE allows as it may grant too much power on what a module can do in a SAFE wallet. Is there restriction on what an executor module can (or cannot) do in a SAFE wallet?

  3. As shown in the demo video, we use a Semaphore identity to “sign” a tx. Is there a way to extend the SAFE wallet UI to perform the signing? Or a way to bring our own UI and integrate it in Safe wallet UI?

Copyright

Copyright and related rights waived via CC0.

2 Likes
2

Welcome to the forum, @jimmychu0807! This is very interesting work, thank you for sharing it with us.

What do you think the main use cases of this solution will be? I see that an EOA can deterministically generate a semaphore identity. I assume an EOA can also generate multiple deterministic identities if needed (by using a salt)?

What happens when multiple EOAs want to be involved - can there only be a single admin when a semaphore group is created using their identities? I’m thinking about the case when an m by n safe wants to set up an m by n semaphore safe.

3

What do you think the main use cases of this solution will be?

Right now we can query on-chain to see who are member EOAs of a multi-sig account. I think the main use case here would be if members of a multi-sig account want to hide their member EOAs from the public. With Semaphore modules, members are signing not with a wallet account but Semaphore identities. And there is no traces from on-chain footprints which Semaphore identity is associated to a wallet account.

This provides additional privacy to the members (thinking of a whale multi-sig account here). As member accounts are not publicly known/queryable, one benefit is they could be shielded from being socially targeted by hackers and scammers.

I see that an EOA can deterministically generate a semaphore identity. I assume an EOA can also generate multiple deterministic identities if needed (by using a salt)?

A semaphore identity can be generated randomly with no influence from the EOA address (the first tab in the demo app).

Screenshot 2025-04-05 at 13.58.51
Screenshot 2025-04-05 at 13.58.51761Ă—379 31.3 KB

But the smart account address is indeed deterministically determined by (wallet account, salt nonce) pair, in the second tab of the demo app.

screenshot-02

What happens when multiple EOAs want to be involved - can there only be a single admin when a semaphore group is created using their identities? I’m thinking about the case when an m by n safe wants to set up an m by n semaphore safe.

There are two ways. The first way is other member EOAs have sent their Semaphore identity commitments to the owner. Then the owner adds them in as members upon the module installation. The demo app is showing all identities generated by a single user to be added in a module for the sake of easy demonstration. In reality the identities will be generated by other EOA members and sent to the owner before module installation.

screenshot-03

The second way is to make on-chain calls of addMember(), removeMember(), and setThreshold() on managing EOA member Semaphore identities & threshold by those who have been initially added as members.

To call these functions, it would just like making a balance transfer, initiating the call with appropriate (target address, func selector, calldata param, value) set, then getting enough valid semaphore identities zk-proofs verified on-chain, and finally have it executed.

This is not done in the demo app UI. But the module is versatile enough to make any on-chain calls. So it is indeed a m-of-n multi-sig wallet.

4

Got it, thanks for the reply

5

Hi! Andy here from the Semaphore/PSE team.

Super supportive of this idea. I think shielding onchain identity and decoupling from public signers list is key to prevent or minimize social targeting.

This is a step in the right direction to give users the ability to better protect and keep their privacy onchain.

6

For the end user, will the experience be very different from something like https://www.fluidkey.com/?

7

@amanwithwings, I have a look at Fluidkey. In a sense it is similar to Fluidkey that it generates a new keypair (Semaphore Identity) so from the on-chain footprints it cannot link back to the actual EOA users. Unlike Fluidkey, Semaphore Identity can only be used for “signing” transactions and not be used to send/receive fund as it is not an EVM address.

I quote “signing” here because of the following technical point. When a member initiate/sign a transaction, what is submitted on-chain is a zero-knowledge proof, and if verified, showing:

  1. The semaphore identity belong to one of the group members of the wallet.
  2. The member identity hasn’t signed on this transaction before.

AND there is no way from the proof to know which member identity send the proof (unless there is only one member identity in the wallet). As the bundler is submitting the transaction, the actual tx sender is shielded from being known, except by the bundler. This may or may not be an advantage depending on the use cases.

I think the UI of fluidkey is very neat and we would also want to build something on par of that.

1 Like
8

@amanwithwings would also like to check with you, at the discussion phase, what indication are we looking for if we should promote this into next stage. Should I participate in upcoming community calls, introduce the idea, and get X number of buy in, etc? Let me know any effort on my side that could help facilitate this discussion into the next stage. Thank you.

9

Big fan of this proposal. Would definitely support it.

Also tagging @colinnielsen here as he previously made a project (DarkSafe) with similar goals but quite a different implementation.

3 Likes
10

Hey @jimmychu0807, since OBRA Wave 2 (SafeDAO’s grant program) is expected to go live soon, it is probably best to process this request through it.

1 Like
11

I see. Sure. Look forward to apply in OBRA Wave 2 program.

2 Likes