https://docs.google.com/document/d/13SvhxsdQx9LdCOpXKdDNrZ89MSxfF6eSfJA_LflaTeg/edit?usp=sharing
[DRAFT] Create & Manage a Digital Org using a Safe - Espla
Abstract
We would like to create a Safe Module to allow organizations to use a Safe as their membership structure. Essentially enabling membership decisions on proposals to become actions.
The goal is to make it extremely user-friendly to manage funds and make decisions. Almost like a WhatsApp group where the complexities are abstracted away and the focus is on the user outcomes. We will support both traditional accounts (EOA + SCA) and email (operated through an SCA) to allow anyone to get started easily.
Users can start instantly by creating an “Org” and inviting others to become members. This org allows users to discuss, propose and execute transactions on the underlying Safe.
An e-money on/off-ramp can be activated by having the members of an org KYC. Using Monerium’s EURe wrapped in our own token EURes, we can allow users to make a SEPA transfer and manage a EURes balance.
Once the org would like to operate in the traditional system, it can attach a traditional entity and operate it. We will start a registration service for Belgian non-profits (and potentially for-profits) as we are based in Belgium and have experience starting quite a few of them.
The entire system will be a cross-platform app (iOS, Android, macOS, Windows) that operates the Safe (through which any on-chain operation can take place), the Proposal & Voting system, the on/off-ramp, entity registration and other components needed to run the system.
You can find the pitch here: https://espla.org/pitch
Aligned strategy
[Strategy 2] Foster module ecosystem
Funding request
We are requesting USDC 10,000.00 from Safe DAO. This is to develop and audit the module that will operate the Safe.
Upfront funding
The module development will take less than 12 weeks. We are requesting 50% up front in order to start development.
Relation to budget
Total Budget: 3%, Remaining Budget: 200%
Metrics and KPIs
The initiative should be measured against:
- Quality level of the proposed module.
- Ease of use when operating the module through the user interface.
- Security impact of the module on the Safe.
- Amount of orgs created.
- Amount of member Safes created.
- Amount of e-money activations.
- Amount of entity registrations.
Usage of modules: We plan to use the module to run an org for Espla itself. We also plan to work with local entrepreneurs to see how they can use it.
By regularly monitoring these metrics and KPIs, we will be able to assess the performance and impact of our initiative, make data-driven decisions, and ensure that we are meeting the needs and expectations of our users and stakeholders.
Initiative description
Key Features:
-
Abstraction of the Safe: Users don’t need knowledge on how a Safe works
-
User-friendly transaction creation: Transactions are abstracted into proposals
-
User-friendly transaction execution: Transaction executing is abstracted into votes
-
User-friendly confirmation threshold: Execution threshold is abstracted into classic voting thresholds that people already understand (majority, simple majority, unanimity, etc…)
-
-
Account Abstraction: Users don’t need to worry about gas fees
-
Account Flexibility: Use an EOA, Safe or Email to ensure that anyone can use the system
-
Privacy: Users interact with Espla through their own Safes
-
Different Safe for every new member for every Org
-
Emails counterfactually converted into a Safe
-
Allows you to maintain privacy across Orgs
-
-
Partial Offline Usage: The app stores all data locally and synchronizes when needed
- Local SQLite database that can be exported/imported
-
Self-Custody: The Org has full custody over its Safe
-
Linking a Safe to an entity: through statutes provide legally binding authority to Safe signers
Overview
Espla aims to support digital natives by providing an easy way to run a digital organization. Governance and execution are linked in a simple interface where people can create proposals (which can include transactions) and vote to approve them by signing. The signing threshold is used as the decision making threshold (majority, simple majority, etc…). The V1 will aim for simplicity by using a 1 signer = 1 vote system and simple majority.
As a second step we will allow the orgs to request for the creation of a traditional entity that will then be linked to the org. It will also be possible to attach an existing entity to the digital one. This should allow for orgs to enter into traditional agreements off-chain (open a Monerium account, obtain a gnosis pay card, apply for a grant, rent an office space) directly. This also allows the flexibility for traditional organizations to create an org and come on-chain.
The project addresses challenges in establishing a transparent, legally compliant framework that leverages both on-chain and off-chain elements. SafeDAO’s support will allow us to build a hybrid governance tool that could benefit various communities and projects with similar needs.
Current status
Most of the technology described above exists already and just needs to be put together:
- The account abstraction is available through Citizen Wallet, which already provides a Safe module and a bundler to interact with it.
- The counterfactual email Safe was developed as an open source project for ETHGlobal Brussels 2024 by myself (Kevin).
- Many of the app features that are needed already exist in open-source form in Citizen Wallet; those can be referenced and ported over.
- The on/off-ramp service is already provided with Brussels Pay using Monerium, is open-source and can be adapted for our needs.
What doesn’t yet exist is the Safe module that would allow enable a few of the key features that are needed to bring the experience together:
- Signing proposals on-chain (IPFS for the data)
- Account privacy
- Delegation
- E-money status
- Entity registration status
It is this OrgModule that will be developed with the requested funding.
Risks
Regulatory challenges:
-
Risk: Enabling an e-money service requires us to ensure that we limit the service in a way in which we do not fall under PSD2 or need to become an EMI
-
Mitigation: Leaning on Monerium (an EMI) and their EURe (which is registered e-money) to provide the service for IBAN to EURe conversion. Limiting the usage of EURe by wrapping it in EURes in order to not be considered a payment service.
Legal challenges:
-
Risk: Linking a Safe and a legal entity may present some challenges where we may have to limit certain capabilities of the system or adapt the statutes that need to be added to the entity.
-
Mitigation: Our extensive work with non-profits over the years has provided experience and a network that should allow us to find the right model that works. We will need to consult with accountants and lawyers for the parts that we don’t know. I have some people in my network who would be able to help with that.
Partnership challenges:
-
Risk: Providing an entity registration service requires us to partner with a 3rd party who is knowledgeable in both the traditional and blockchain world. Those can be hard to come by.
-
Mitigation: I have a network from university in Belgium, some of which are chartered accountants now with the knowledge to help out with this issue.
Technical challenges:
-
Risk: The main challenge is going to be providing a level of abstraction that makes the user experience better without sacrificing security.
-
Mitigation: An audit of the module will help ensure the proper operation of the module. For the user-friendliness, it will be working a lot with potential users of the system who are not tech savvy and ensuring that the system makes sense to them.
Timeline and milestones
Phase 1: Account privacy (2 weeks)
Milestones:
- Convert an EOA, Safe or Email into a Safe that can sign on the Org’s Safe
Phase 2: Delegation (1 week)
Milestones:
-
Allow a signer to become a delegate
-
Allow a delegate to operate the Safe regardless of execution threshold but be limited to external actions that do not modify the Safe in question
Phase 3: Signing proposals (2 weeks)
Milestones:
-
Allow a proposal (which is saved on IPFS) to be signed by the Safe
-
Allow a proposal to include a transaction which will then execute through the Safe
Phase 4: Status (1 week)
Milestones:
-
Allow the storage of the Org’s e-money status
-
Allow the storage of the Org’s entity registration status
Initiative lead
Espla. We are a Belgian non-profit in the process of being created in order to develop this project.
Espla ASBL/VZW
Rue Washington 44/7, 1050, Ixelles, Belgium.
Team
Kevin Sundar Raj - Entrepreneur, Full-stack Developer, Web3 Developer
Additional support/resources
We are open to expanding the entity creation service in other countries if anyone is interested and can provide a person of contact in that country.
Implementation dependencies
None