[NCR#1 Proposal] Safe Wallet Anonymous Email Management Module

[0xorio]

Summary

Our proposal introduces an innovative approach to anonymous and secure multisig wallet management through email, building upon the Safe Anonymization Module (SAM) developed by our team previously under a SafeDAO grant. Inspired by the concept of the emailwallet.org, which leverages zkMail technology we aim to transfer these ideas to our SAM. Our proposal, allows users to manage their multisig Safe wallets privately via email, combining the simplicity of email communication with the advanced security and privacy of Zero-Knowledge proofs through native and seamless integration with Safe Ecosystem.

Methodology

Our goal is to advance the Safe Anonymization Module by integrating innovative user experience solutions. We believe that implementing the zkEmail concept for managing Safe Wallets represents a breakthrough in secure and private email-based multisig asset management.

This project builds on the ideas behind emailwallet.org, adapting them to the Safe Wallet standard by developing the SAM Module. This plug-in module enables private asset management and transaction execution within Safe via email, offering a seamless integration of zkEmail concept for enhanced security and privacy.

System Components

1. Smart Contract: A compatible module for SAFE Wallet.
2. Circuits: Inspired by the emailwallet architecture, these circuits are ported to Noir, following the design outlined here: zkEmail Circuit Architecture.
3. SMTP Server: The entry point for emails, monitored by the Relayer for incoming messages that trigger blockchain transactions.
4. Relayer: The core service that listens for emails, verifies proofs with the Prover, and writes validated transactions to the blockchain.
5. Prover: A separate service that verifies and generates zk proofs, with the Relayer sending them to the contract when the multisig threshold is met.
6. Database: A PostgreSQL database to store account information and facilitate account checks.
7. Graph Protocol (subgraph): For indexing on-chain data.

User Flow

Setting Up and Connecting the Module

1. Participants in the Safe Wallet connect the SAM module to their wallet.
2. After connecting, participants specify the email addresses that will manage the SAFE Wallet and define the threshold parameters. These details are sent to the Relayer.
3. The Relayer sends a confirmation email to the provided addresses to verify their connection to the SAM Module.
4. Participants respond to the confirmation email, at which point the Relayer generates a cryptographic proof for each email, following the emailwallet and zkEmail frameworks.
5. Once all participants have confirmed and the email proofs are established, the SAM module becomes fully operational.
6. With the module active, participants can begin creating and managing proposals securely through email.

Creating a Proposal

1. A participant in the SAM module can initiate a transaction by sending a simple email command. For example:

   • Send 2.5 ETH to 0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266
   • Execute 0xba7676a8.....

   For this proof of concept, we are focusing on ERC-20 token transfers and smart contract executions.

2. All SAM module participants receive an email with the transaction details and the option to confirm or decline it. They respond with either Confirmed or Declined.

3. When the required number of confirmations is reached, the transaction is automatically executed or canceled based on the responses. Participants are notified via email once the transaction is completed.

4. The proposer can cancel the transaction at any time before the threshold is met by sending a Revoke command with the proposal number.

Technology Stack

• Frontend: React.js / Vite for building the user interface.
• Backend: Python or Rust for server-side logic and processing.
• Blockchain: Ethereum (or EVM compatible) as the underlying blockchain platform.
• ZK Proofs: Noir for creating zero-knowledge circuits.

Timeline and Deliverables

First Month

Phase 1: Planning and Setup - 1 week

• Deliverables:
  • A detailed project plan with clear milestones.
  • Setup of the development environment.
  • Finalized project requirements and technical specifications.

Phase 2: Porting and Development - 3 weeks

• Deliverables:
  • Conversion of Circom circuits to Noir.
  • Development of the SAM Module smart contract.

Second Month

Phase 3: Integration and Testing - 2 weeks

• Deliverables:
  • A user interface for the module creation.
  • Implementation of the Relayer service.
  • A user interface for monitoring module activities.

Phase 4: Deployment and Review - 2 weeks

• Deliverables:
  • Deployment of all system components.
  • Completion of final documentation and user guides.
  • A comprehensive review of the project outcomes with recommendations for future improvements.

Team

Oxorio is a blockchain security firm that specializes in smart contracts, ZK solutions, and security consulting. With a decade of blockchain development and five years in smart contract auditing, our expert team delivers premier security services for projects at any stage of maturity and development.

• Website: https://oxor.io/
• Github: https://github.com/oxor-io
• Email: [email protected]

Team members involved in the project:

• Alexander Mazaletskiy (CV): With over 10 years of experience in blockchain development and auditing, coupled with extensive expertise in ZK proofs, he has led the development and audit of ZK-based cryptographic modules. His work spans the implementation and audit of ZK-Stark, ZK-Snark, Plonk, and Halo algorithms, with a strong focus on enhancing security and privacy in blockchain projects through advanced ZK techniques.
• Alexander Drygin (CV): with over 5 years of experience in blockchain development and auditing and specializing in ZK proofs, he has been pivotal in developing and auditing ZK-focused projects, with key contributions to Tornado Cash, Tornado Nova’s fork Privacy Pools and Safe DAO Anonymous Module, enhancing privacy and security through advanced cryptographic methods.

Our past experience related to Noir:

• Our team was a finalist of ETHGlobal 2023 hackathon with ZKvote application utilizing ZK proofs for cross-chain L2 voting. Awarded a sponsorship prize from Scroll for the utilization of recursive SNARKs in Noir.
• Noir Contracts for the Safe Anonymization Module, developed as part of the SafeDAO grant work.
• MiMC Sponge Noir - this repository contains an implementation of the MiMC Sponge hash function written in Noir, created during the development of the Safe Anonymization Module
• Our articles and research on Noir featured in our blog:
  • Noir Explained: Features and Examples - the introduction article, emphasising its ease of use and advanced features, including recursive proofs and Black Box functions, with practical examples for developers.
  • Using Noir for Building an Anonymization Module - an article describing the development of an anonymization module for SafeDAO using Noir.

Start Date

6 September, 2024

[Savio-Sou]

Hi @0xorio, thanks for submitting the cleanly written proposal; love the idea!

Since the proposal intends to be an extension to SAM, would be great if you could shine more light on the project: is it in progress / completed, is it integrated with Safe, next steps, etc.

[0xorio]

Thank you for your interest in our proposal!

Last year, our team received a grant from SafeDAO to research and develop a Proof of Concept for the Safe Anonymization Module, structured around three key milestones. The successful completion of these milestones led to a functional SAM prototype, with all code openly accessible (see below). Anyone interested can deploy the contracts and connect the module; however, a separate UI, currently available only as a PoC, will also be required. However, we identified some user experience challenges, which inspired us to explore improving the UX by incorporating ideas from emailwallet.org, particularly enabling multisig wallet management via email. In ZKMail we found an opportunity to address two UX issues:

1. Onboarding new users: Simplifying the process for those unfamiliar with blockchain technology or without Ethereum addresses.
2. Anonymizing participants: Enhancing the privacy of signers, which is the core function of the SAM module.

Moving forward, one of our primary objectives is to further develop the current prototype into a more polished, product-ready solution. We aim to collaborate with SafeDAO to secure a place in the Safe Apps catalog. Additionally, we intend to build a developer community around the project, following the best open-source traditions, to enhance the product's performance, functionality, and security.

SAM Milestones and Results Overview:

1. Milestone 1: Research & Circuit Design

• Goal: Identify optimal technologies and strategies for SAM implementation, focusing on ZK-SNARKs, elliptic curves, and usability.
• Result: Research and architecture design.

2. Milestone 2: Backend Development

• Goal: Develop and integrate the ZK-SNARK circuit and SAM smart contracts.
• Result:
  • Circuits Code Repository
  • SAM Smart Contracts Repository

3. Milestone 3: Frontend Development

• Goal: Create a user interface for SAM, integrate it with the backend, and ensure SafeApp compatibility.
• Result:
  • Frontend UI Repository
  • https://safe-sam.netlify.app/ - functional web app prototype which you can connect to any existing Safe Wallet

For more details on the project, its milestones, our development stages, usage instructions and video demonstration please refer to this document.
For more details on the conducted research and architecte of SAM, please refer to this document.

[Savio-Sou]

Congratulations on getting selected for NCR#1: https://github.com/orgs/noir-lang/discussions/5932

Check the announcement for what's next. Let's bring the world ZK!

[Divide-By-0]

Hey folks -- a few notes. Having chatted with the Safe team, it might make sense to focus on these directions:

1. they are switching away from Safe towards 7579 with the release of safe 1.4, so I recommend focusing on those integrations as well, for instance since our current safe signer code with circom/emailwallet is only tested on safe 1.3 and below.
2. many folks still want the primary signer to be a self custody EOA, so our safe signer demo focuses on that kind of transaction flow! we of course support experimentation on primary signers being emails as well, but just a note that it might be less secure to not have any eoas on the wallet.
3. since zk email will have a native safe integration soon, I recommend integrating noir into the https://emailwallet.org backend so that you can piggy back off of our integration work! we will integrate both with the UI and their permissionless SDK :)
4. a module is i think the most insecure way to architect this. the problem with modules is that the primary signers on the safe can remove or override the module at will, so modules should NOT be used for needed multisig signers, or else the owners can just override them. i recommend architecting it closer to the way we build the safe 2fa flow (which you can see in the email-wallet PR history).

[0xorio]

Hey! Thank you very much for your interest in the project and for your comments. Here’s what we think about the suggested directions:

1. We understand the importance of integrating with Safe 1.4 and 7579 in the long run. However, most Safe instances currently run on version 1.3, and even after the release of 1.4, most Safe instances will continue to use version 1.3 and below, which is why within the scope of this proposal, we want to focus on creating a module compatible with current version. That said, we will definitely consider future integrations with 7579 as Safe 1.4 adoption grows.
2. You are right that it might be less secure not to have any EOAs on the wallet. In our vision, the Safe wallet owners will have EOAs for full control over the multisig, while the Safe Anonymous Mail module (SAMM) will be used for routine operations under specific security policies defined in the smart contract:
   

• The multisig has a standard set of EOA owners who have full control over the multisig, including managing the rights of the SAMM module.
• The SAMM module has restrictions on what actions it can perform on behalf of the multisig (security policies). These restrictions are implemented and verified in the smart contract code. For example, the SAMM module cannot change the owners of the Safe multisig or can only call specific smart contracts.
• Thus, the SAMM module is used to conveniently manage routine operations, while the standard set of EOA owners is used to handle critically important tasks.
  Additionally, the presence of EOAs is optional; if a user does not need them in their case, they can choose not to use them and not impose rights restrictions on the SAMM module. This flexibility allows for tailored security setups depending on the user’s case.

3. The main idea of our solution is to enhance privacy for Safe multisig, not just by hiding who is voting, but by also concealing how they vote and the actual content of their votes. Our approach ensuring that both the voter and the content of their vote remain anonymous. It seems that this level of privacy cannot be achieved by simply integrating Noir into the emailwallet backend. However we will still leverage the open-source relayer code from emailwallet for our off-chain relayer infrastructure. Thank you for the incredible work done!
4. We acknowledge that Safe modules can present certain security risks. However, this is the official and recommended method by Safe for extending its functionality. We don’t see this as a problem in our design, as the SAMM module will be limited in its permissions - as said in p.2 it will only handle routine tasks, while EOAs retain control over critical operations. This approach mitigates potential risks by ensuring that the module can’t be misused, offering both convenience and security.

In conclusion, while we are committed to our current architecture for the specific privacy-focused objectives within the scope of this proposal, we greatly appreciate your insights and are open to further exploring improvements in collaboration with your team.

[Divide-By-0]

just by hiding who is voting, but by also concealing how they vote and the actual content of their votes

Ooh this is sweet. I know some folks who did some work here (i.e. send safe tx that could be approval or deny with a hiding and binding commitment, then at execution time open the commitments in zk or after an FHE addition or via a state proof) -- I'm happy to connect you if you send a telegram username :)

[0xorio]

@Savio-Sou, could we add @Divide-By-0 to our Slack channel with all our team for this project?