Support EDS development for Safe

Proposals Phase 1: Draft
1

Safe eds proposal

Authors: peersky.eth ( tim@peeramid.xyz )

Created: 2025-03-22

Executive Summary

This proposal seeks SafeDAO’s support to implement the Ethereum Distribution System (EDS), a standardized, secure, and interoperable framework tailored for distributing Safe smart contracts, modules, and associated infrastructure. Currently, the Safe and largely, Ethereum ecosystem lacks a unified distribution channel, leading to fragmentation, hindering developer collaboration, and complicating security verification for end-users.

EDS addresses this by providing on-chain, versioned distributions with verifiable source provenance. The primary goal is to establish this robust foundational infrastructure, thereby enhancing security, improving the developer experience through reusable standards, and fostering a more vibrant and trustworthy module ecosystem. While EDS architecture enables potential future applications for SAFE token utility and revenue generation via its TokenizedDistributor component, the immediate focus is on building this essential public good for the Safe ecosystem.

We request $220,000 USDC (or SAFE equivalent) to fund the development of core EDS contracts adapted for Safe, a Safe Guard Extension, essential on-chain repositories, initial Guard module examples, developer tooling, comprehensive audits, documentation, workshops, and one year of technical support focused on community enablement. This investment aims to significantly improve the security posture and development velocity within the Safe ecosystem.

Abstract

This proposal suggests DAO support for implementing the Ethereum Distribution System (EDS) to establish a trusted, standardized, and secure channel for Safe smart contract and module distribution. Addressing the current lack of unified distribution infrastructure, EDS introduces on-chain, versioned repositories and verifiable package provenance.
By leveraging EDS, the SafeDAO can significantly enhance ecosystem security through immutable, auditable distributions, foster a more interoperable and efficient module ecosystem by providing developers with reusable standards, and lay the groundwork for potential future SAFE token utility applications through EDS’s built-in mechanisms.
This proposal details the integration of EDS, the development of Safe-specific components, and a plan for community enablement, ultimately aiming to strengthen the core infrastructure supporting Safe wallets and modules.

Proposal types

State which proposal type this proposal belongs to.
SEP: Constitutional Proposals
SEP: Governance Proposals
Other SEPs

Proposal details

Background

Currently, the Safe ecosystem lacks an effective, standardized solution for distributing and managing Safe modules, particularly Guards. This absence hinders innovation, makes it difficult for users to discover and trust third-party extensions, and complicates security auditing. Developers often resort to custom factory solutions, increasing fragmentation and redundant effort.

To address this, Peeramid Labs has developed the Ethereum Distribution System (EDS), a generic framework utilizing Distribution and versioned Repository smart contracts. EDS offers a standardized alternative, allowing developers to package and distribute software components securely and efficiently.

Key aspects EDS brings to the Safe ecosystem include:

  • Standardization: Provides common interfaces and SemVer compatible versioning for modules.
  • Security: Enables immutable source code references (aligning with ERC-7744/EIP-7784 concepts) and hooks for runtime security checks and vulnerability management (aligning with ERC-7746). It also allows for linking distributions to verified UI implementations (e.g., IPFS hashes).
  • Efficiency: Reduces redundant development work by providing reusable factory patterns.
  • Flexibility: Supports concepts like TokenizedDistributor for potential monetization models and allows for user-driven upgrade paths (though this proposal focuses on the foundational setup).

This project stems from ongoing research into on-chain solutions for widespread vulnerability threats, as discussed during ETH Taipei 2024.

Smaug - Example Safe Guard Plugin

To demonstrate EDS’s capability in addressing real security needs (like those highlighted by the ByBit attack), we developed the Smaug Guardian plugin. Smaug introduces configurable budget controls (daily, per-block, per-tx, total). Users can explore and instantiate Smaug via EDS at solutions.peeramid.xyz. This serves as a practical example of how EDS can facilitate the distribution of valuable Safe modules.

Purpose

The primary goals of this proposal are ordered by priority:

  1. Establish Secure & Standardized Distribution: Implement the Ethereum Distribution System (EDS) tailored for Safe, creating a robust, reliable, and unified channel for deploying and managing Safe smart contract infrastructure and modules. (Primary Goal)

  2. Enhance On-Chain Security and Transparency: Utilize EDS’s capabilities for on-chain versioning, immutable source code references (per ERC-7744/EIP-7784 concepts), and runtime security hooks (per ERC-7746 concepts) to increase the verifiability and security posture of Safe modules and infrastructure.

  3. Foster Module Ecosystem Growth: Provide developers with a standardized, reusable platform (EDS) for building, packaging, and distributing Safe modules and extensions, lowering barriers to entry and encouraging innovation.

  4. Enable Future Token Utility & Revenue Potential: Implement EDS components, like the TokenizedDistributor, which provide the technical capability for the DAO to explore future initiatives related to SAFE token utility or monetization models for specific distributions, directly supporting ORBA goals.

Proposal

We propose that the SafeDAO support the integration and deployment of the Ethereum Distribution System (EDS) specifically tailored for the Safe ecosystem. This involves developing Safe-specific components, deploying core EDS infrastructure under DAO control, and providing initial support and enablement for the community.

Deliverables:

  • Safe DAO owned EDS Distributor contract: A DAO-controlled contract instance (likely a TokenizedDistributor type) to manage the listing and distribution of approved Safe infrastructure and modules.
  • Safe DAO owned Wallets Repository contract: An EDS-compliant repository contract managed by the DAO for versioned distributions of core Safe wallet contracts.
  • Safe DAO owned Module/UI Repository contract: An EDS-compliant repository linking specific module/wallet versions to verified metadata, potentially including whitelisted user interface (UI) URIs (e.g., IPFS hashes) for enhanced frontend security.
  • Safe Guard Extension: A custom smart contract extension enabling Safe wallets to interact securely with the EDS framework (e.g., for version checks, upgrade facilitation).
  • Initial Safe Guard Examples (3): Development and packaging (as EDS distributions) of three distinct Safe Guard plugins showcasing different protection strategies. These will be licensed to ensure the DAO controls their canonical distribution via the DAO Distributor.
  • Enhanced EDS SDK & Tooling: Improvements to the existing EDS SDK and CLI tools to streamline the process for developers creating and publishing Safe modules via EDS.
  • Comprehensive Documentation & Workshops: Detailed documentation for developers and users, plus at least 5 educational workshops (online or in-person) to facilitate understanding and adoption.
  • Security Audits: Independent security audits for the core EDS contracts being deployed and the three custom Safe Guard examples developed under this proposal.
  • One Year Technical Support & Community Enablement: Dedicated support channel, ongoing maintenance for deliverables, governance support for initial listings, and focused efforts to enable community self-sufficiency.

Effects and Impact Analysis

Benefits:

  • Enhanced Security & Trust:
    • Provides on-chain, verifiable provenance for Safe modules via immutable distributions (ERC-7744/7784 alignment).
    • Enables standardized runtime security checks and vulnerability management hooks (ERC-7746 alignment).
    • Facilitates linking contract versions to verified UI implementations, mitigating UI spoofing risks.
    • Clear on-chain versioning increases transparency and auditability.
  • Improved Efficiency & Standardization:
    • Reduces redundant development effort by providing standard factory patterns and reusable components.
    • Introduces SemVer-compatible versioning for better dependency management.
    • Standardized interfaces promote interoperability between modules and across the ecosystem.
    • Mitigate UI Vulnerabilities (ByBit case): Implementing EDS’s enables to distribute IPFS hashes of interfaces as part of on-chain packaging. DAO & Security providers can attest to UI security in runtime. Such information may be used to create secure browsing user experience.
  • Fostered Ecosystem Growth (Supports ORBA Goal):
    • Lowers the barrier for developers to create, distribute, and gain trust for new Safe modules and Guards.
    • Allows the DAO to curate a repository of high-quality, trusted modules.
    • Improves the composability of Safe infrastructure.
  • Future Potential (Supports ORBA Goal):
    • The TokenizedDistributor component provides the DAO with the option to implement SAFE token utility or monetization for specific distributions in the future.
    • Creates a foundation for a potential decentralized market of security providers offering services via EDS hooks.

Cons & Risks:

  • Complexity: Initial setup and understanding the EDS framework may require specialized expertise for developers and the DAO.
    • Mitigation: Comprehensive documentation, dedicated support, workshops, and developer tooling provided by Peeramid Labs. Phased rollout focusing on core functionality first.
  • Technical Risks: Potential for bugs or vulnerabilities in the EDS contracts or the Safe-specific integrations.
    • Mitigation: Rigorous internal testing, comprehensive external security audits (included in funding), and adherence to security best practices. Emergency security hooks for the DAO council in the Distributor contract.
  • Adoption Risk: Achieving broad adoption by developers and integration into user-facing applications requires effort beyond just building the infrastructure.
    • Mitigation: Focus on excellent developer experience (DX), leverage SafeDAO’s reputation, engage key ecosystem partners early, ensure standards are open and easy to integrate; Promote EDS usage across other Ethereum ecosystem projects to foster industry standard level of adatpion.
  • DAO Operational Overhead: Long-term maintenance of the DAO-controlled Distributor (managing listings, governance) and associated repositories will require ongoing DAO resources and defined processes beyond the initial support year.
    • Mitigation: Design core contracts for robustness. Provide extensive enablement during the support year. Establish clear initial governance guidelines for managing the Distributor.

Alternative Solutions

Developing a bespoke distribution system entirely in-house would be resource-intensive, risk further ecosystem fragmentation, likely offer less functionality than the purpose-built EDS, and might struggle for broader community adoption compared to leveraging an open standard. EDS provides a more efficient, collaborative, and feature-rich path.

Implementation

The core implementation involves deploying the EDS contracts (Distributor, Repositories) under DAO control, developing the Safe Guard Extension, enhancing the necessary tooling, and packaging the initial Guard examples.

High-Level Architecture:

The process will involve iterative development, rigorous testing, security audits, and deployment, followed by community outreach and support as outlined in the Deliverables and Support sections.

Open Questions

  1. Major Version Upgrades: EDS architecture can support user-driven upgrades for major versions via migration scripts, offering flexibility but adding complexity. Is this a high-priority feature for the community initially, or should we focus on simpler upgrade paths first?

We welcome community feedback on this and other aspects to ensure the EDS implementation aligns with the Safe ecosystem’s needs.

Funding Request

To implement EDS for Safe, conduct necessary audits, and provide initial support, Peeramid Labs requests $220,000 USDC (or SAFE equivalent at the time of transfer). This funding is allocated as follows:

  • Safe-Specific Development ($50,000):
    • Custom EDS Safe Guard Extension Development: $10,000 (1 month FTE)
    • Development of Initial Safe Guard Examples (Package of 3): $20,000 (2 months FTE)
    • End-User Interface Portal (Basic interface for Guard installation/discovery): $20,000 (2 months FTE)
  • Core EDS Enhancements & Tooling ($40,000):
    • EDS Smart Contract Development (Finalizing features relevant to Safe): $30,000 (3 months FTE)
    • SDK Improvements & Developer Tooling: $10,000 (1 month FTE)
    • (Note: While enhancing core EDS, this work directly enables the Safe implementation)
    • TBD: We are open to approach other ecosystem projects with proposal to co-sponsor this part of work, given Safe DAO shows preliminarly (snapshot) support for other components of this propoisal.
  • External Security Audits ($80,000):
    • Audits of the 3 developed Safe Guards: $40,000 (Projected cost)
    • Security Audit of EDS Core Functionality (Quote provided by oxorio): $40,000
      • TBD: We are open to approach other ecosystem projects with proposal to co-sponsor this part of work, given Safe DAO shows preliminary (snapshot) support for other components of this propoisal.
  • Support, Education & Enablement ($50,000):
    • Dedicated Support & Maintenance (1 Year): $30,000
    • Workshops, Documentation & Community Enablement: $20,000

Justification:

This funding represents an investment in critical, foundational infrastructure for the Safe ecosystem. It covers the specialized development required to tailor EDS, rigorous security audits essential for user trust, and the initial support needed to ensure successful adoption and community enablement. The requested amount reflects the senior expertise involved and is positioned as a cost-effective approach compared to developing a similar system in-house or via disparate, non-standardized efforts.

Licensing & DAO Control: The three Safe Guard modules developed under this funding will be explicitly licensed to grant the SafeDAO control over their canonical distribution via the DAO-owned EDS Distributor contract. This ensures the DAO fully controls the distribution and any potential monetization strategy for these specific deliverables.

End-User Interface Portal sponsored under this proposal funding & hosted by Peeramid Labs will explicitly list only Guard extensions that, in case of generating revenue, directly share it with Safe DAO with at least 30% share. TBD: If DAO wants to have full revenue of that portal, a hosting and maintenance expenses must be discussed in prior.

About Peeramid Labs

Peeramid Labs is a collective focused on developing tools and infrastructure for decentralized systems, emphasizing trust, transparency, and security. Our team brings relevant, senior-level experience to this proposal:

  • Direct Experience: As founder, my background includes security engineering work at OpenZeppelin, contributing to the security audits and consulting for projects such as Compound, The Sandbox, and the Bank of International Settlements’ Project Mariana. This experience directly informs our rigorous approach to building secure and reliable infrastructure like EDS. My background also includes over 15 years of successful product delivery across various industries (details at https://peersky.xyz).
  • Web3 Contributions: We actively contribute to Ethereum standards (ERC-7746, EIP-7784), identify critical vulnerabilities (example), and develop R&D projects like EDS and Rankify.
  • Philosophy: We believe that web3 requires bold experimentation with foundational, decentralized concepts like EDS to realize its full potential, moving beyond the limitations of centralized models. Our work reflects this commitment to building innovative, user-centric decentralized solutions without VC constraints. We are passionate about collaborating with the SafeDAO to build valuable, secure infrastructure for the ecosystem.

We are members of the Ethereum Enterprise Alliance and contributors to DeFi Risk Assessment Guidelines.

Copyright

Copyright and related rights waived via CC0.

2

Interesting proposal!

With security middleware the challenging part is often the distribution / adoption. Could you share more about what you think is needed to have Safe users effectively adopt the EDS?

Could you elaborate on the similarity / differentiation to module registries like Safe Core Protocol or Rhinestone?

3 Likes
3

Hi @lukas ,

1. Solving adoption

In brief: demand is there; EDS creates a competitive environment for businesses delivering solutions & UX; Snowball effect does rest.

Our assumptions before longer answer :

  • Users just want to have good UX and solving their pain points
    • that crypto is hard and insecure to use, that there are compliance questions etc etc.
  • Users are willing to pay for access to UX that saves them time & solves pain points.

From my personal experience, many of applications at Safe Apps Directory simply did not work when I needed them, except for CoW protocol swaps, which naturally has fee-based skin in the game to deliver UX.
While that, there is also only Safe based UI widely known to me, that I can use to install safe apps, and there is none for guard plugins at all.
Therefore it’s centralized, and in my opinion, subject to stagnation due to centralization.

Based on these assumptions and observations, theory for adaptation is that demand is there, the supply of accessible solutions is lacking.

EDS approach has potential in solving this, since there is no need to imply any centralized interfaces or whitelisted registries. By acting as a generic distribution system, it aims to ease development, interoperability and distribution processes.

For example, if users go today to https://solutions.peeramid.xyz they will find there one single guard plugin factory contract interface implemented as IDistribution.
It already uses EDS on background and anyone willing to use can use it to create

  • Own factories, chaining existing factory
  • Security oracle, attesting in runtime to this package security

We also can ensure incentive for adaption and developing a smooth & secure installation process including setGuard transaction signing.
Eventually the portal is envisioned to become an on-chain solutions directory, listing various IDistribution packages trough rendering IDistributor.sol frontend.

Similarly, anyone can repeat that, creating free-market competition for best UX & best solutions.

In particular, the DAO can have its own distributor registry, and can list packages from any third party developer or distributor. Given the reputation and expertise of the DAO it obviously will have a market leading role, which will however be competition based with other providers by design.

Educating community
In such a competitive environment, developers using EDS have the upper hand, since they are working in the same framework, they can easily elaborate on other distributions.

To communicate that, part of our proposal is a budget for setting up workshops and educational programs, to ensure individual developers and companies in the space understand the opportunity and have material & expertise to kickstart the development.

Possible practical moves involve making this as part of smart contract lecture program at Invisible Garden, issuing hackathon rewards for EthGlobal, and providing high quality tooling, documentation and mentorship.

2. Comparison to Safe Core Protocol or Rhinestone

The main distinct difference is that EDS is not Safe ecosystem nor attestation only specific.
EDS architecture is a generic answer to industry need for on-chain distributions.

Our initial design was largely inspired by the Repository structure developed by Aragon OSx which implements similar tasks. Similarly, any protocol in DeFi that deploys new markets, wallets, or library-like functionality invests today in a factory/registry/attestation system.

Developers benefit not just from re-using other Safe developer distributions. They may combine code from DeFi, DAOs, any other packaging can be in principle accommodated and pretty much any code that can be cloned, can be also packaged.

One distinct difference from Rhinestone is that in EDS, a canonical (secure and trusted) distributor contract would only list and attest distributions by byte code hash.
This approach has many benefits, primarily security & portability.
By enshrining distributions as immutable bytecode on-chain, not a proxy of a kind, we enable implementing security oracle businesses. Instead of having ERC-7512 with an uncertain model, companies may simply attest to bytecode hashes by deploying own Distributors which is much easier to adapt to.

This also enables a high level of portability, enabling porting packages cross-chain with maintaining trust assumptions.
As example: A third party entity could whitelist Safe DAO distributions even at chains that have no Safe DAO presence, by simply pointing desired codehash. It signals interest by setting a feature-flag that automatically enables once desired code is deployed & indexed.

Our adoption plan is to eventually supersede ERC7744 with EIP-7784, which will provision the highest possible adoption rate for this technology.
While this may be challenging, there are long-term architectural benefits of EIP7784 also for execution clients, which makes us optimistic.

Safe Core Protocol has many similarities to EDS in structure of having middleware, hooks and instantiation logic, however I can point out many differences that make it quite completely different approaches:

  • ModuleManager of Safe Core Protocol acts as centralized element, there is no such in EDS
    • This implies EDS by design is more decentralized and less prominent to single point of failure risks
  • EDS provisions ability to tokenize distribution instantiation and runtime attestation
  • Safe Core Protocol components such as modules, manager could be valuable Safe Distributions within EDS.
  • EDS focuses on bringing ERC/EIP standardised experience

Here is table to summarize comparison:

Feature EDS Safe Core Protocol Rhinestone
Primary Purpose Secure, decentralized & efficient distribution of Safe smart contract infrastructure Listing & permissioning of Safe Core Protocol modules Verification of legitimacy & security of smart account modules through attestations
Distribution Distribution & versioned Repository contracts; Tokenized Distributor Basic listing Module address storage
Security ERC7746, ERC7744, runtime checks, decentralized security oracles Marking modules as malicious Attestations with schemas
Governance Safe DAO owned Distributor & Repository contracts Likely Safe DAO governance Permissionless
User Focus web3 developers Internal Safe protocol Developers of modular smart accounts
Key Concepts Distributions, Repositories, Distributors, Installers Permitted Modules, Malicious Modules Attestations, Schemas, Resolvers, Attesters
Standard Compliance ERC7746, ERC7744, SemVer N/A ERC-7484
4

Hey @peersky, thank you for the detailed proposal! Considering the size of the request, I hope you won’t mind if I’m extra critical.

An important point to note here is that Safe{Wallet} has amazing distribution, but it does not fall under DAO governance. So the DAO (or apps listed through the EDS) will not be able to leverage this. The top of the funnel here has to be either a new UI the DAO maintains to aggregate listings or the applications themselves. If apps are able to bootstrap most of the traffic on their own, I don’t believe they have the necessary incentives to do a meaningful revenue split with the DAO. So, in the end, it comes down to whether this discovery page has the ability to funnel users into various apps and create competition internally.

This to me is a big IF, especially paired with the inefficiency of a DAO to build and maintain tech. While the technical implementation makes sense from a decentralization point of view, this does not matter to the end user. We will be competing on practicality, usability, and the hardest problem in any industry—how to bootstrap users for a new interface. Sponsoring hackathons or giving lectures does not solve this. I would appreciate some proof of success here so that the DAO can more fairly evaluate your request.

There are a multitude of other things as well in the proposal, but this to me is the most important question.

1 Like
5

Totally agree on this.

DAO has intrinsic advantage against anyone trying to funnel majority of DAO infrastructure managed traffic, by simply being The Safe DAO.
If someone manages to outcompete DAO, this only speaks for the DAO inefficiency, not for the missing market opportunities for the DAO.
Improving DAO efficiency is not a primary scope of this proposal, even though we do provision that EDS standardised processes for revenue generation may create positive impact, we however operate under presumption that the DAO is based on free market values, hence strives to become more competitive in context larger then EDS.

FYI, if that would be an interest: as founder of Peeramid Labs, I have committed most of my time, company resources and devotion to flagship product of ours, a protocol eventually, that is aimed on fixing DAO and Corporate Governance inefficiencies. We are in closed testing right now, and if the DAO wanted to have our help on this front - we are more than happy to. You can read more about it on rankify.it

That said, further assuming DAO has market opportunities to take on, and strives to become better version of self.

Let’s say 3rd party company releases a distribution over BSL 1.1 license and explicitly prohibit from anyone using their source code otherwise than through their distribution source.

Practice of app stores, and streaming services beating torrent based distributions proves that such licensing eventually will work out, and majority of users would eventually one way or another follow such a licensing practice.

Such company does not need to care for anyone re-listing their distributions on other interfaces, as long as these interfaces follow defined rules and instantiate from their specified, tokenized, endpoint.

This however does not stop distributors who do such re-listing from adding own margins. For example Safe DAO can point to such a distribution by wrapping it with added values:

  • Provide high level curated distributions aggregation
  • Provide runtime security (it may hire subcontractors to do so to increase efficiency)
  • Provide some level of insurance for users of whitelisted distributions
  • etc

Whatever traffic is on 3rd party company interface, if DAO simply re-lists such distributions with added values, it is likely to capture major traffic anyway. Hence 3rd party developer firms are exceptionally interested in incentivising DAO to list their distribution endpoints while trying to bite as much as they can with making aggressive distribution source protection.

Even if users end up eventually instantiating from 3rd party private interface, being listed (hence attested) by the DAO will give such a company competitive advantage on the market.

Hence firms expected to compete for being DAO listed, even if they host own interface, even if their traffic is sufficiently high.

Ways to incentivise DAO may be using Safe Token, or sharing revenue part with the DAO.

For example, take look on what we are doing at our solutions PoC:

Smaug Safe Guard plugin is licensed under BSL 1.1
It requires 200 USDC payment for instantiation
From this revenue, 60 USDC are sent to the DAO balance. This is 30%, equivalent of standard App Store revenue of Apple Store.

Hackathons and community education program hence have secondary meaning, the primary goal of this proposal is to create sustainable, free market based revenue model for DAO based on developer ecosystem, and portable attestations.

2 Likes
6

If someone manages to outcompete DAO, this only speaks for the DAO inefficiency, not for the missing market opportunities for the DAO.

Exactly. And this is my main concern: with the current operational setup, SafeDAO (or most DAOs for that matter) are designed in such a way that there is a low chance of success if they try out this experiment.

Practice of app stores, and streaming services beating torrent based distributions proves that such licensing eventually will work out, and majority of users would eventually one way or another follow such a licensing practice.

True, but I think both of us agree that the most challenging part in building an app store, or a streaming service is not the app part. Success relies on the teams on ground that can hunt for new partnerships, negotiate deals, iterate continuously to stay on top of narratives, build user capture pipelines, do relentless and genius marketing, etc. Your proposal aims to work on the ‘app’ part, while the rest of the BD/Ops (which is more critical IMO) is up to the DAO to figure out.

Whatever traffic is on 3rd party company interface, if DAO simply re-lists such distributions with added values, it is likely to capture major traffic anyway.

This is a HUGE assumption. Could you share any proof here? Note that venture funded examples like Spotify capturing a significant percentage of the music streaming business is not comparable to SafeDAO funding EDS.

A possible method to test this assumption (if a smaller scale, real experiment is not possible) is talking to the same apps listed on the Safe apps directory. Ask them:

  • How many of them will pay $$ to get listed on the new aggregator, and how much per listing?
  • How many of them will be open to a revenue split for the traffic routed through the DAO-maintained interface, and under what conditions?
  • At what threshold of traffic can they no longer ignore partnering with the DAO-maintained interface?

Note that the apps with the proven revenue potential are ones that power DeFi interactions. This might require the DAO to maintain its own instance of wallet. What will this take (in terms or capital and resources) to keep up with Safe{Wallet} and other instances already live? In the case of non-DeFi apps/modules/plugins, which may not have an established monetization model, what is the actual revenue potential for the DAO?

1 Like
7

We were considering approaching directly the DAO with efficiency improvement proposals, however, we’ve chosen EDS as first priority for two reason:

  • We think first must have problem, then solve it. We don’t see strong market needs for DAO to be efficient in operational sense today. Correct me if I am wrong in this statement, please, I’m curious.
  • EDS would still be a dependency in such a proposal, hence it makes sense to start with it.

Our stance actually is more akin to Pavel Durov with his statement on “we’ve built telegram with 30 people and 0 marketing”.
Not saying it’s not important, but it’s appealing way of thinking about how to grow a business:
Top-notch UX is the ultimate success factor and it’s a primary reason which got Safe and Telegram to where they are today.

Our proposal is to work on portable, and interoperable software distribution model, we can do apps for demonstration reasons. We are similarly talking to Aragon Foundation, and will be talking to any DeFi protocols today deploying new markets.

A strategic direction for Peeramid Labs is developing RWA retail businesses and meritocratic autonomous marketplaces.

In that regard, we foresee numerous opportunities for expanding Safe DAO outreach to organizations who are yet not boarded on using crypto, and we see EDS wil help there.

If DAO would like, we have also legal counsels available in various jurisdictions, we can make part of proposal lefal research on licensing part of such distribution system, as this is quite paramount unless distributed applications are implemented as fhEVM without sources published, which is unlikely happen soon.

Distribution is key. Just as wrapped candy is preferred over loose candy, value-added packaging and distribution layers are critical for digital assets.

DAO listing packages, especially those using standards like EDS, are these crucial distribution layers. They’re not just UI; they are on-chain distributor interfaces controlled by the DAO. Competition will focus on the quality of these ‘wrappers’ and the partnerships (licensing, fees) embedded within their contracts.

This reflects the real world: manufacturers (developers) profit by focusing on volume and partnering with distributors who own the customer relationship. Consider the OEM/ODM model used by giants like Bosch. Bosch achieves massive scale and brand trust by delegating manufacturing while controlling distribution. Having subcontracted for them, we know firsthand: our product needed the Bosch brand and network to sell.

This challenges the Web3 assumption that basic on-chain royalties suffice. Structured distribution wins. EDS enables bringing effective, OEM-like distribution models on-chain.

Key points here:

  • Safe DAO can be the ‘Bosch’ for smart accounts, leveraging trust and distribution for long-term relevance.
  • On-chain distribution interfaces (via EDS) are undervalued but vital. They allow secure, controlled distribution, potentially just referencing an interface URI (metadata: “://interface_uri”) baked into the package.

Our Smaug PoC is real example. We just announced it publicly:

Since we are young company, not VC baked, to get this sold via outbound process, we need to have snowball effect. We will likely unable to get it without Safe support. We’ve issued 30% revenue to incentivise DAO to support us.

What happens if we suddenly (let’s say years from now) become huge aggregator of solutions?
Well, we may re-list package quietly on our interface. That will cause discrepancy between what DAO lists and us, giving us a reputation hit back.
Obviously there are smart people out here, thinking on protocol level, where trustless is our speciality - staking for that regard is possible.

So as business owner for small fair R&D company my answer would be:

  • We would not be willing to PAY, but we would be willing to do stake or tokenise our project with issuing part to Safe DAO as collateral against any partnership that puts DAO at risks.
  • We would be willing to share revenue, baked in to immutable piece of distribution code. If we would become strong enough to generate more revenue on our own interface, DAO Listing would create security onion on top of ours, and we would want to keep it to reduce risks and abstract from direct user support. There is no reasonable way we would want to cut ties with DAO unless it becomes “dead-horse” with zero activity.
  • We would be OK if DAO lists our packages even without mentioning us (ODM/OEM). We would focus on delivering factories woking for DAO. (“If you’re Apple, then we’re TSMC” mindset)

That’s an option to do, but what would be an outcome we are looking for first place?
What would be breaking point in reviewing these answers between evaluating our assumption as “yay/nay” ?

8

Hey @peersky, sorry about the delay in responding—I was OOO for the last few days.

We don’t see strong market needs for the DAO to be efficient in an operational sense today. Correct me if I am wrong in this statement, please. I’m curious.

It’s true that the DAO does not have a lot of day-to-day operational requirements at the moment. But overseeing a project like this one would definitely introduce it. This is not to say the DAO shouldn’t fund something just because it’s not operationally capable of managing the opportunity, but if it decides something is worth funding, it should also set up the operational legos to manage the project well.

Top-notch UX is the ultimate success factor and it’s a primary reason which got Safe and Telegram to where they are today.

I agree that UX has been great with almost all successful products. But a “build and they’ll come” mentality has led to the downfall of even more, including a significant percentage of projects in our world. I understand that you are approaching this from the other side, but I’m of the opinion that the DAO should look at more than just the pitch before taking this decision. This includes whatever indication of success you have as the team leading this project.

Plus, you mention a 30% revenue split with the DAO, while the DAO is funding 100% of your development effort. I fail to understand how this is fair. It may also have to find, and potentially spend more on the distribution and business channels to make this a success, and support your team financially if the initial funding doesn’t get you to breakeven. If it’s only technical development, what says SafeDAO cannot issue an RFP and contract someone who’ll take a smaller cut (even 0% of revenues quite possibly) as they are only doing the technical development?

Tbh, I’m not a fan of the above argument because you can always “find someone to do things cheaper”. What I do want to know, however, is what you can concretely share—beyond your intent and plan —for the DAO to evaluate your offering more objectively.

In any case, note that I do not hold any voting power, so the decision ultimately lies with the voters. Through these questions, I’m simply trying to get to the heart of your offering.

1 Like
9

@peersky, apologies about the confusion in my previous response. For a moment, I confused Smaug for the wider EDS deployment.

10

No worries, @amanwithwings , I actually think all of your questions are super to the point and make sense to answer.

Sorry it took me a while to respond as I’m at Taipei for Ethereum events and last week was full of them (ETHTaipei, EthGlobal).

We would certainly be committed helping DAO to gradually work on this as separate, ops direction.

Agreed, decentralization comes from strength to work your way on your own and being able to find “nodes” that are willing to connect with…

While my stance is more on the “just build it” side, it’s not black & white, I agree on importance especially on synergies mindset.

Our strategy on going for market is quite bold & transparent: we are here for end-user adoption by building community owned marketplaces. We already have few large communities in-line for RWA marketplaces.

We were just at EthGlobal Taipei demoing ZK Passport integrations and showing Smaug as well, all as part of that infra for end-user build-up.

That said, Secure Safe Wallets, EDS etc is instrumental for us: we want to be sure that once we have our partner communities land on blockchain, they are safe & efficient.

We are not asking for 100% funding support.

To this date, EDS has around of 5 month of FTE investment of architecture design, core contracts & industry feedback gathering, which we are not asking to fund retroactively.

However, current form of proposal consists of items that benefit larger set of players than just Safe ecosystem, from 220k requested funding, these spendings could be considered as relevant:

  • EDS Smart Contract Development pending milestones: $30,000 (3 months FTE)
  • SDK Improvements: $10,000 (1 month FTE)
  • Security Audits of EDS core functionality: $40,000

This in total is 80k or ~36% of the requested funding.

In ideal scenario, we want these expenses to be funded by everyone benefiting, hence larger evm ecosystem.
We write these down upfront to the DAO to demonstrate scope of work we face and be fully transparent about needs of EDS in general, so that if DAO can evaluate first mover advantages & challenges.

As mentioned before, such EDS could benefit other projects, such as Aragon, Compound (and any other DeFi protocol deploying markets), perhaps even Lido, RPL or some other larger DAOs.
If there is such interest, we would also be qualified to get grant & security audits support from ecosystem run funding, like Arbitrum Audit Program that recently passed voting

Peeramid Labs is fully committed to do the business dev work of actually going to these communities and talking to them. Current discussion on Safe is first step of doing this work.

Having positive sentiment on funding this proposal (with keeping common ecosystem work as TBD) would certainly help us to move conversations there forward as well.

We are mentioning this for in-production, ready to use system, that DAO has 0 investment in to. If someone deploys Smaug today, DAO gets 30% for free.

For all of the guards funded by Safe DAO, we would deploy distributions so that:

  • Instantiation may happen only trough DAO owned Distributor contract, meaning that DAO will be in full power of monetization
  • We will make sure that source code contract licenses also explicitly prohibit anyone to using anything but the Safe DAO controlled endpoints.

Just to re-iterate on Distributor architecture:

Distributions (deployed by developers) -- may charge --> Distributor (DAO owned) -- may charge --> users

I would argue that Peeramid Labs as trailblazer should be qualified for small % on these distributions pointed by DAO owned Distributor contract.
Argument for this: (i) current proposal does not include work already done on EDS, (ii) it gets developer skin-in-the-game to deliver largely used product (iii) gets other developers more excited to see new revenue sources.

Ideally that would be Safe tokens, therefore we can prove that we become Safe DAO members by contributing useful software, instead of doing speculative trading on exchanges.

We love that. I guess above anwer most of it. You can hire another contractors, but you cannot hire visionaries who will go and trailblaze future together with you.

I will be updating initial post briefly with

  • TBDing expense sections on common ecosystem investment question
  • Adding explicit explanation that guards deployed under this funding will be explicitly licensed to DAO owned infrastructure to distribute those

In the meanwhile, I would love to hear more thoughts from the DAO.

11

I find this proposal incoherent and misguided and it needs major rework before I’d vote in favor, in detail:

What is the primary objective of this proposal? It seems to be all over the place, stated objectives are:

  1. increase revenue
  2. distribute software
  3. enhance security
  4. (later on stated in addition): foster ecosystem growth

These are 3 (or 4, depending where in the proposal you read) entirely different directions which I find all valuable and worthwhile exploring but not in one single proposal that tries to be the Jack of all trades. I am in favor of proposals that are pushing for a specific improvement of clear issues with credible possibility of success.

I then don’t see why Peeramid is well suited or should be funded (with a significant amount) for this work. Peeramid seems to be building various mostly unrelated proof-of-concept products, including (from their website) Rankify and Multipass. None of these product seem to have reached a significant level of popularity and Peeramid is now seeking sponsoring of yet another product which seems to be pre-release. Yet, as @amanwithwings has pointed out, this proposal critically hinges on EDS being a popular market place. I would like to see data for this investment having reasonably high chances of success - and success hinges more on growth and product work than the smart contract work that is being discussed and presented here.

If and when Peeramid can show that EDS is working and has an actually active market place, this proposal would look quite different and I would be easily convinced that this is valuable to pursue as a Peeramid product (as opposed to being a Safe product).

In general, I am supportive of making Safe infrastructure more widely accepted and integrated in the ecosystem and I find it valuable to think about revenue as a guiding principle in these discussions. However, as outlined above, I am not convinced this proposal in its current form is likely to achieve that.

2 Likes
12

Hi @SCBuergel,

Thank you for your direct feedback. It’s valuable for refining this proposal. Let me address your points:

1. Proposal Objectives:

  • You’re right that the proposal touches on several areas. The primary objective is to establish a secure and efficient distribution system (EDS) for Safe wallet software and modules, focusing on interoperability, portability, and enhanced security.
  • The potential for revenue generation and fostering the module ecosystem are significant outcomes enabled by this core infrastructure, aligning with stated ORBA goals (Token Utility & Foster Module Ecosystem). We see these as synergistic benefits stemming from a robust distribution system, rather than separate, scattered aims. If the current proposal feels too broad, we are open to discussing how to narrow the scope to focus more tightly on the foundational EDS implementation first.

2. Peeramid Labs’ Suitability & Experience:

  • Our team brings relevant experience. As founder, my background includes work at OpenZeppelin, contributing to the security of projects like Compound, The Sandbox, and the Bank of International Settlements’ Project Mariana. This experience directly informs our approach to building secure and reliable infrastructure like EDS.
  • While some of our projects, like Rankify, are focused on distinct challenges (like DAO operational efficiency – a point raised by @amanwithwings), they stem from the same core belief in building better decentralized systems. EDS itself is conceived as foundational infrastructure.
  • We acknowledge that EDS is innovative, similarly as concepts behind Rankify & Peeramid Network. We believe this kind of foundational work is necessary to move beyond iterating on existing centralized models and to truly leverage the potential of decentralized systems for security and distribution.
  • Personal Experience: I am founder & solitary owner of Peeramid Labs. My background includes over 15 years of successful product delivery across various industries (details available at https://peersky.xyz). This experience, including work on large-scale industrial systems, informs my perspective that web3 itself is still largely experimental and requires bold approaches (referring to your “proof-of-concept” concerns of ours). We believe that truly embracing decentralization and experimenting with foundational concepts like EDS is essential for DAOs to thrive long-term, countrary to becoming marginal stablecoin banking. We aren’t afraid to pursue these “far out” ideas when we see their potential value and my personal experience keeps me fully convinced: in PL, we’ll get there.

3. Funding Request:

  • Regarding the funding amount: Roughly $80,000 is earmarked for external security audits (EDS core and initial Safe Guards), which is a critical cost for ecosystem security. The remainder covers development salaries for the proposed deliverables. We believe this represents a cost-effective approach compared to the likely expense of an equivalent in-house build or hiring external agencies unfamiliar with the Safe/EDS architecture and having a bloat of PMs & Sales people behind. We aimed for transparency by including the audit costs upfront.

4. EDS Status & Marketplace:

  • EDS is designed as a developer library and infrastructure standard, not a standalone consumer product. Its goal is to enable secure distribution and potential marketplaces, similar to how standards like ERC-20 enabled token ecosystems.
  • While the full EDS vision is new, its core components are already being used in production on mainnet (e.g., powering aspects of https://peeramid.network).
  • You raised a valid point about the “chicken-and-egg” problem regarding marketplace adoption. We see SafeDAO’s support as crucial catalyst. It lends credibility (especially important post-ByBit), helps fund essential audits, and signals to the wider ecosystem that this is a supported standard for building and distributing Safe modules securely. Our Smaug PoC, which includes a 30% revenue share to the DAO from day one, demonstrates our commitment to aligning incentives and building value for the Safe ecosystem, even at this early stage. We are not asking the DAO to fund a speculative marketplace, but rather the foundational, open-source infrastructure that makes secure marketplaces and distribution possible.

Moving Forward:

We presented this proposal to initiate a discussion and gather feedback to shape the best path forward. We believe EDS offers a significant opportunity to enhance the security, efficiency, and vibrancy of the Safe ecosystem.

We appreciate your critical perspective and are keen to refine this proposal based on the community’s input. What specific aspects would you suggest we focus on or modify in a revised version to better align with the DAO’s priorities?

13

Thank you all for the valuable feedback and critical questions on the initial Safe EDS proposal draft. We appreciate the engagement from @SCBuergel, @amanwithwings, @lukas, – your input has been instrumental in helping us refine the proposal’s focus and clarity.

Based on the discussion, we’ve revised the proposal to incorporate the feedback received. We believe these changes make the proposal stronger, clearer, and more directly address the points raised.

Here’s a summary of the key updates:

  1. Sharpened Focus & Structure:
    • Added an Executive Summary for a quick overview.
    • Refined the Abstract and Purpose sections to clearly prioritize the primary goal: establishing a secure, standardized distribution system (EDS) for Safe. Other benefits like potential revenue/utility and ecosystem growth are now framed as outcomes enabled by this core infrastructure, addressing feedback about scattered objectives.
  2. Improved Clarity & Conciseness:
    • Streamlined several sections by removing redundancy (e.g., merged the “One-Time Effort” list into Deliverables/Funding, removed duplicate sections).
    • Condensed detailed technical descriptions in the Background and Benefits sections to improve readability and keep the focus on the core proposal.
  3. Strengthened Justification & Risk Management:
    • Included a more detailed Funding Breakdown directly in the proposal text to clarify cost allocation.
    • Explicitly added/highlighted Adoption Risk and DAO Operational Overhead in the Risks section, along with mitigation strategies, addressing concerns about go-to-market and long-term maintenance.
    • Revised the About Peeramid Labs section to professionally highlight relevant experience and address questions about suitability.
  4. Clarified DAO Control & Deliverables:
    • Made it explicit that the Guard modules developed under this funding will be licensed to ensure the SafeDAO controls their canonical distribution and potential monetization.

Our aim with these revisions is to present a more focused, robust, and transparent proposal that clearly outlines the value EDS brings as foundational infrastructure for the Safe ecosystem, while also acknowledging the associated risks and operational considerations.

We encourage you to review the updated version and welcome any further feedback or questions you may have.

Thanks again for your engagement!