Call for Community Input: Strategic Direction and OBRA Funding Strategies

Author(s): Strategy Steering Committee

Context

Over the last few weeks, the Safe team has received tremendous support from delegates, guardians, ecosystem projects, and other stakeholders in the industry. Along with this support was also feedback on how the Safe tech stack could be made more resilient. One of the key questions here for SafeDAO is how it should effectively allocate funding towards making products built on top of Safe more secure.

There are multiple possible approaches here including:

  • introducing a new strategy focused on security to OBRA
  • Introducing community-nominated RFPs to fund security improvements
  • launching ecosystem support programs like audit subsidies, retroactive funding, ecosystem-wide bug bounties, etc.

This post seeks to collect feedback on this topic, as well as the general capital allocation discussion defined below, to shape the next wave of OBRA and possibly also make way for other initiatives.

To also facilitate a more open conversation on the topic, we are planning to organize two discussion sessions: one on this Friday (March 14th) at 12.00 PM CET and the other on the coming Wednesday (March 19th) at 4.00 PM CET. Invites to both calls can be found on the governance calendar.

Call to Action

This discussion is happening at a timely juncture, as we are close to launching the Wave 2 of OBRA (Outcomes Based Resource Allocation) - SafeDAO’s grant program. This gives SafeDAO a unique opportunity to internalize some of the ideas coming out of this discussion into OBRA’s existing structure.

The Strategy Steering Committee is tasked with iterating OBRA based on community feedback and insights from the previous wave(s). As such, this post aims to collect feedback on the question above, and also on the more generic question of capital allocation: which strategies from OBRA Wave 1 should be carried over or sunsetted? Which strategies should be newly introduced?

OBRA Wave 1 distributed ~$1M in grant funding over 2024. You can find more info on the progress of past initiatives on this dashboard; and a high-level discussion on the impact in this retrospective. Attention, performance and funding allocated varies across strategies and they need to be refined further to improve capital efficiency.

  • Strategy 1: Research and implement Safe token utility and Strategy 4: Research decentralization of Safe tech stack may need significant refinements as they were relatively underutilized. The structure of refinement of Strategy 4 depends heavily on the answer to how SafeDAO should approach funding initiatives seeking to improve the security and decentralization of Safe. For Strategy 1, it is important to discuss if it makes sense to retain token utility as a strategy going forward.

  • Considering the influx of applications, it may make sense to retain Strategy 2: Foster module ecosystem; Strategy 3: Increase awareness of Safe Ecosystem; and Strategy 5: Increase governance participation, with refinements to improve their funding efficiency.

  • To fund various operational legos of SafeDAO, it may be worthwhile exploring how Strategy 6: Wildcard can be refined to become an operational strategy. This change will also limit it serving as an unintentional funding vehicle when the budgets for other strategies run out.

Irrespective of how you are involved in the Safe ecosystem, feel free to share projects or ideas you’d like to see funded through OBRA as well as general approaches to address the questions at hand. The Strategy Steering Committee will try its best to condense your feedback into refinements within OBRA or separate initiatives.

2 Likes

Looking at the retrospective it seems like:

  • Lots of BS proposals extracting value from the DAO, especially in Strategy 5. Let’s just remove this category.
  • Critical things like decentralization is not getting the attention it needs, and this is critical for security

Generally it seems like we have two main problems:

  • Lack of accountability - There’s no one to blame if a strategy is over budget, spends money on BS, or isn’t making progress toward stated goals.
  • Lack of vision - The current documents outlining the strategies are very hand wavy. We need clear vision on what is needed and how to get there on each of them.

Maybe it would make sense to have an owner for each strategy that is responsible for setting the vision and moving things forward. They would potentially also be payed by the DAO for this work.

Thank you, @amanwithwings, for sparking this important discussion around the strategic direction and OBRA funding strategies. Here are some thoughts:

Safe{Core} – Our Flagship Product

Safe{Core} is a battle-tested, widely-used set of smart contracts that forms the backbone of our ecosystem. While past funding has supported teams building on top of Safe{Core}, it hasn’t been the core focus of the OBRA grant program. Given its pivotal role, emphasizing it is essential for a vibrant and robust Safe ecosystem.
For example, the Uniswap protocol demonstrates the benefits of having multiple frontends. Their approach—with both an official interface and several community-built access points—has kept users engaged even when controversies (like commission fees) arose on the official frontend. This shows that a diversified access strategy can help maintain and grow user engagement with the underlying protocol.
It would make sense for Wave 2 of OBRA to direct funding toward teams building on Safe, with Safe, or focused on enhancing its security. This not only reinforces the strength of our flagship product but also fuels community-driven innovation and improvements.

Enhancing Safe{Wallet}

Safe{Wallet} is a key product line offering an intuitive and accessible interface that leverages Safe{Core} for everyday operations. Funding efforts to further improve security on Safe{Wallet} will continue to make our ecosystem more user-friendly and resilient.

Reassessing current OBRA strategies

Based on the Wave 1 retrospective, we believe we should consider removing (or revisiting later) strategies such as #1 (Research and implement Safe token utility) and #4 (Research decentralisation of Safe tech stack). This shift in focus could allow us to concentrate resources on more immediate needs, like the ones suggested above.

Prioritising security

As we shift more attention toward builders, security must remain at the heart of Safe. Subsidizing audit costs for these teams would be an effective measure to ensure that enhancements come with robust security, aligning perfectly with the goals of the OBRA grants program.

Acknowledging Recent Contributions

Lastly, we propose a one-off retroactive funding round for teams that stepped up during the past few challenging weeks. This would send a strong, positive signal and demonstrate our DAO’s gratitude to the key community builders who have been instrumental in our progress.

Thanks for raising this discussion @amanwithwings .

@jthor as an OBRA recipient in Category 5. I feel attacked. LOL but agree that funding in general should be tied to macro objectives.

I will be making a case for:

  1. Client diversity.

Why? People need to conduct their daily operations when core services go down.

When we first raised our proposal we did get some flack, [SEP 35] [OBRA: Increase governance participation] Improve voting UI/UX with SAFE on mobile about another client.

We can now clearly see that client diversity is important. When core services were suspended, all the various alt-clients had a chance to shine for the specific SAFE activities they supported.

However, key services are sill needed to transact with Safe which brings me to my next point.

  1. Fallback critical infrastructure.

Why? Again when a core service is stopped for whatever reason vendors NEED fallbacks.
Yes we could clone and run our own txn relayers but this is simply cost prohibitive.

On this point I think we have a few options;

2.a) Petition ecosystem providers to run well known services (Running the Safe Transaction Service – Safe Docs) at a known URL e.g https://txn-relay.safe.optimism.io. This reduces infrastructure burden on small operators and there is increased trust. This also means messages can be pooled.

If I ran my own relayer, it should be HIGHLY UNLIKELY that Safe would want to surface that message on the official UI. Thus we lose some interoperability across various clients.

2.b/ Devise an on-chain method for arbitrary message passing.

3.c/ Deploy a validator like client (rsafetxns) solely responsible for passing messages. Anyone can run this. Possible upside. Truly decentralised. Explore adding additional utility for Safe tokens for staking etc.

I’ve expanded my thoughts earlier on in this thread how this looks like from a vendors implementation perspective. Would appreciate eyes on this as well.