Safe Token Utility Sprint 1 Output

This thread provides an overview of the Safe Token Utility Sprint 1 outcomes as presented during the Safe {Braintrust} in Brussels (view slides).

In the next 2 weeks, the Safe Token Utility team will be around to incorporate final comments and feedback into the six created utility reports.

At the same time, we aim to support and (co) author follow-up proposals to progress towards tangible MVPs and pilots.

Consider leaving your input on the reports or reach out via the Forum or TG (LuukDAO) if you’re interested in (co) authorizing an MVP/pilot proposal.

Visualization of the Safe Token Utility Sprint 1

Token Utility Reports

Use Case TLDR
1. Safings Account | STU - Google Docs Safings account is a simple yield strategy designed for “lazy” or “conservative” Safe users. It provides access to the simplest, safest, yield-bearing tokens for the major currencies (stablecoins, ETH, WBTC).
2. Vault Marketplace | STU - Google Docs The vault marketplace is a module for asset managers. It allows them to offer yield strategies to Safe users.
3. Safe Premium Account | STU - Google Docs The Safe Premium Accounts focuses on Safe {Wallet} power users and provides them with additional perks and benefits as they continue to use Safe {wallet} and stake SAFE.
4. Safe LP Token Staking (80/20) | STU - Google Docs The Safe LP Token Staking (80/20) creates rewards for SAFE token holders who are willing to LP to increase the onchain liquidity of SAFE and generate value.
5. Advanced App Marketplace | STU - Google Docs The Advanced App Marketplace creates a transparent, competitive process for application developers building on Safe to integrate into the Safe UI and wider Safe Ecosystem.
6. Smart Account Fee Engine S.A.F.E | STU - Google Docs The Smart Account Fee Engine (S.A.F.E.) is designed for builders in the Safe ecosystem, providing a solution for seamless fee collection by implementing an intent-based architecture.
4 Likes

We’re still open to stakeholder input directly on the forum or in the documents. We hope to have the first {Draft} follow-up proposals live in about 2 weeks.

1 Like

We would like to thank @LuukDAO, Kolektivo Labs team and all others involved for their work and contribution towards possible utility for the SAFE token.

As an active contributor to the SAFE ecosystem, a delegate and the treasury manager of the SafeDAO<>GnosisDAO joint treasury we are excited by the opportunity to share our initial thoughts on the six shortlisted use cases. We have also collaborated with the Kolektivo team on use case 4 “Safe LP Token Staking (80/20)”, which served as an example for the remaining use case reports.

We are sharing some brief thoughts on the shortlisted use cases.

The below feedback assumes familiarity with the materials produced and presented by the team above and some statements might not apply outside this context.

  1. Safings Account
    • As the report outlines there is functional overlap with the Vault Marketplace use case. We believe Safings is not necessarily a viable alternative to the Vaults as it is a more constrained implementation but it could serve as an MVP (the report presented both paths as possible)
  2. Vault Marketplace
    • A large portion of the described desired functionality has already been built by teams working on extending Safe such as karpatkey, Brahma and others. Integrating such existing modules could decrease the resources required for rolling out such a use case to validate the demand
    • Notably this implementation is superior to the Safings Account as it provides more accessible opportunities for teams building on top of Safe to create and capture value, which is instrumental for the long-term growth and success of Safe without reducing the available options for SAFE utility
    • From the list of potential paths to bring utility to the SAFE token, staking the token in insurance pools associated with different vaults/modules seems the most promising. Vault operators and module developers can stake themselves or incentivise SAFE holders by sharing the fees they generate with those staking for their vault/module. This can be generalised and used to create a token-curated registry of vaults/modules for the Safe ecosystem [feedback also applicable to Advanced App Marketplace]
    • We see designing a governance process for electing vault operators and pushing this process through the Safe DAO governance creates an undue administrative burden for both vault operators and token holders at the MVP stage
  3. Safe {wallet} premium account
    • As the report outlines this use case is an extension of the current Safe {Pass} initiative, which is perfectly positioned to serve as an MVP implementation. Further examining this path requires some insight into the success of the Safe {Pass} program.
  4. Safe LP Token Staking (80/20)
    • Onchain liquidity currently is supported mainly by the Joint Treasury funds, and generating a sticky increase in liquidity as seen in the Aave and Balancer cases can greatly benefit the SAFE token. An MVP could also be a useful test to see if more onchain activity is attracted by better liquidity.
    • A more stable and liquid onchain market will also be a need for SAFE token utility use cases where SAFE is staked for economic security and insurance (such as a possible Safety Module)
    • Having said that, in our view the MVP should be implemented along with at least one of the token utility options mentioned in the document (Safe{Pass} integration, governance participation, Safety Module) in order to establish a use case and see its impact on liquidity and overall trading activity. If there isn’t a clear use case for participating in the ve8020 other than LP incentives, there is a great possibility that liquidity will go away once incentives are gone
  5. Advanced App Marketplace
    • This use case shares a lot of similarities with Vault Marketplace, which can serve as the first iteration of rolling out a more generalised app/module marketplace
    • Out of the outlined approaches “Safe Ecosystem App integration” appears to be the more versatile as it allows for Safe {Wallet} to surface an App or Native UI integration while bringing value to all users of Safe regardless of their preferred interface for interacting with the infrastructure
  6. Smart Account Fee Engine S.A.F.E.
    • Collateralizing Fee Credits with SAFE is a direct way to connect demand for modules (and thus the need to collateralise Fee Credits and for fee settling) with demand for SAFE token, thus being effective in tokenizing value of the Safe Ecosystem (one of the Strategic Pillars of the Safe DAO Constitution)
    • Additionally, through the Ecosystem Contribution this would advance Safe in the monetization efforts while keeping the alignment with the public good vision for Safe{Core}. Token utility can be further explored by tying SAFE token to the value of the EC, and helping transition SAFE token into a more mature stage (aligned with the “real-yield” segment of mature DeFi tokens). We see this as more and more important over time as crypto markets evolve, bringing in more sophisticated actors that seek real value and not just future growth potential.xt
    • To safely and efficiently establish SAFE as collateral for Fee Credits, healthy and liquid onchain markets are needed (since the fee settlement process happens onchain), so it’s sensible to focus efforts on something like the ve8020 first to understand the resources required for that.
    • Though one of the most promising initiatives for the SAFE token and Safe Ecosystem as a whole, it might carry a high degree of technical complexity and substantial coordination between module developers, other utility initiatives (it could overlap with fee charging for Safings Account and Vault Marketplace for example) and the Safe team has to be in place to successfully introduce the Fee Engine.

An overall theme across most of the examined use cases (1,2,3, and 5) is that they depend predominantly on Safe users interfacing with the infrastructure through Safe {Wallet}. This has two distinct consequences that are worth considering:

  1. The team building Safe {Wallet} is best positioned to execute any next steps. Where the conceptualised functionality is already built by a team in the Safe ecosystem integrating those modules through a direct collaboration between said team and Safe’s team seems the most MVP path. Leveraging the DAO for procurement and execution at the MVP stage would create unnecessary additional coordination overhead. If the MVP is successful and a complete implementation is to be deployed, as per the token utility paths outlined the token holders will play an essential role.
  2. Strong reliance on Safe {Wallet} for the monetisation of the Safe stack could create incentives to consolidate all Safe-related activity through that singular interface directly competing with existing differentiated front-ends (Den, Coinshift, Brahma, HQxyz, etc.) and removing incentives for new teams to emerge and build on the stack. These stakeholders should probably involved in the decision-making around these options.

We are looking forward to hearing how other ecosystem stakeholders view those. Furthermore, we would be delighted to further support the discovery process where our expertise can be beneficial.

4 Likes

Were any of these use cases considered @LuukDAO?

These are all proven value-capture mechanisms for wallets and communities.

As a large Safe delegate, it sounds like you’re trying to reinvent the wheel instead of taking clear steps to move the Safe ecosystem into a massive economic engine.

  • Fee on the swap router
  • Onramps/offramps fee
  • Safe should have default bridge, earn fees
  • Safe staked ETH derivative
  • Sell .safe.eth subnames
  • Consider a Safe stablecoin
  • Referral fees for recommended txs (Zora, sound, etc)
3 Likes

Hi @corbinpage

Some of the use cases you suggested have already been mapped and included, but overall, these are good suggestions! Thanks for sharing.

  • Fee on the swap router | This is already close to happening

  • Onramps/offramps fee | This has not been explored in detail, but this could be valuable, although it is likely closer to SEF terrain than SafeDAO due to legal implications.

  • Safe should have default bridge, earn fees | To date, cross-chain safes haven’t been extremely user-friendly, so this wasn’t explored in detail. This could change in the future!

  • Safe staked ETH derivative | I can see the upside of this, but it also seems like a significant investment. I’m curious if you have any pointers on this approach vs. incorporating third-party derivatives and charging a small fee on that front.

  • Sell .safe.eth subnames | This is part of the Premium Account use-case

  • Consider a Safe stablecoin | Due to the regulatory elements of a Safe native stablecoin, this hasn’t been considered in detail. Do you have any specific examples you think are relevant for Safe on which to base this use case?

  • Referral fees for recommended txs (Zora, sound, etc) | Can you describe the use case here with an example of the fees this generated?

Can you articulate what approach to progressing Token Utility ideas and suggestions into tangible use cases for SAFE would be better than our current approach?

1 Like

It’s a good idea, I hope you can elaborate on it。

a little late to the party but i would like to share my opinion regardless. it’s clear that the intentions of these token use cases are to create native defi apps and reestablish safe identity as a the defi protocol. i do not believe that safe should to be a defi protocol and my comments below reflect that.

Use Cases

no. 1 & 2 i feel that staking is so widely available on the blockchain that safe does not need to integrate a native staking contract. the only advantage that i can see is allowing more control over safe points apr. although, like how morpho was handled, the same can be done but more streamlined for future protocols. the advance app marketplace is a better way to streamline staking in the safe UI.

no. 3 is good and can get partners to give out prizes/airdrops based on tier.

no. 4 LP is good, solidifying liquidity is important.

no. 5 seems like a proposal to start curating the second marketplace for advanced users. no problem with that but i fail to understand the vision behind this. it’s important that attracting users to the marketplace is streamlined and profitable.

no. 6 a good proposal but i disagree with tokenizing fees. a credit system makes sense but creating a token from it adds unnecessary layers. see article for reference on a credit system that could be utilized. https://learn.utility.credit/ alternatively, the safe points system could integrate fee credits for users, builders and protocols respectively.