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.
- 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)
- 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
- 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.
- 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
- 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
- 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:
- 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.
- 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.