SAFE Token Utility Proposal

Proposals Phase 0: Discussion
5

Open-source business models

GitLab’s co-founder and Open Core Ventures’ (OCV) general partner, Sid Sijbrandij, concisely explains 2 open-source business models.

  • Buyer-Based Open Core (BBOC)
    • Based on who is using the feature, i.e., An individual or organization/business
    • GitLab is based on this model with a free and open-source product it maintains and a forked enterprise version with paid features.
  • Commercial Open Source Software (COSS)
    • Only produce open source code
    • Earn revenue from subscriptions for support, training, and implementation services, e.g. Red Hat

Safe ecosystem

The Safe ecosystem can take advantage of each approach on different time horizons.

Short-term revenue with COSS

  • The SafeDAO and core team can create SAFE token revenue providing services for support, training, and implementation, similar to Red Hat mentioned above.
  • This can be less scalable and efficient because it requires a more manual process and is more customizable.
  • However, it can be a potential way to generate short-term SAFE demand.

Long-term sustainability with BBOC

  • This seems like a sustainable business model for Safe to build features that are worth it to individual users and organizations/business to pay for one-time and/or recurring basis depending on the feature.
  • These features would be more automated and scalable.
  • Potentially both sets of features could remain open-source with the distinction being the premium features are integrated directly within the Safe apps for those who pay for them.
4 Likes
6

This is very well put together — both precise and strategic. Thank you, @lakejynch :beers:

And well put @adamhurwitz.eth you have excellent points to consider.

I certainly wish to see us deliberate on this topic further as it’s a massive value add to the Safe ecosystem and imperative for us to establish a proper utility for the token.

Having a way to prioritize the queue of integrations by utilizing a staking method deserves a fair bit of attention as many projects could be more decentralized in this way.

Integrating trusted and verified applications is no small task and typically consumes a fair number of resources. Just to keep up with the ever increasing number of blockchain applications is a considerable feat itself. Having them displayed on official gateways or front ends is an even larger challenge. This whole conversation is quite intriguing regarding that because it would help teams find a signal through the noise.

This type of conversations makes me think of things like Moonheads by txn street. I become increasingly convinced an under utilized avenue for crypto are verifiable advertisements as a source of protocol revenue and even givebacks.

Opensea has a notable feature page and a fair number of successful projects can lend a portion of that to getting displayed on the front page of a website with a ton of web traffic. As Adam pointed out with Youtube. :thought_balloon:

I suspect there is an area that we can explore that combines a staking and locking mechanism in exchange for some sort of prime advertisement space. Or a ‘sponsored’ section on the Safe UI. Maybe even something akin to bribes where projects could offer a timed incentive where a set of users are rewarded for using a featured app — using bribes to alleviate network costs but also grease the wheels of an exchange. Even something similar to BAT where projects or users are rewarded based on the number of users actively using the apps and how much ‘attention’ an integration receives via the official UI.

This could create a pretty interesting and competitive situation. A bit of this is inspired by Optimism’s way of incentivizing app usage via retroactive funding and rewards campaigns. I understand there is some different interpretations of the quests and the actual activity. But, I still think it ends up net positive because of many other factors.

Since Safe is a fundamental primitive for the entire ecosystem, I do believe there are a number of different strategies that would play well along these lines. Including creating conditions for the rewards to get claimed.

ie; users must create a safe proxy to use the app for it to be included in rewards or they must stake their balances with their safe

This would encourage people to actually use the safe as intended and not simply deploying it to take advantage of potential perks. :key:

We must people clearly see the real perks of using a SAFE.

Thinking along the lines of this tweet by Martin. What Martin and Kevin talk about is interesting to me, because when I first discovered Safe, I didn’t realize it was for another purpose. I had to research DAOs more before I realized they used safe proxy contracts— a multisig —to increase decentralization as we all work towards fully autonomous, decentralized entities.

https://twitter.com/kelvinfichter/status/1618810661521473543

I assumed then that a safe contract was an ideal solution to increase security for hot wallets. A way to rotate keys to maintain one reputable address. I ended up using an EOA because making signatures often conflicted with ecosystem dApps. Since then this has become less of a problem. (When I first deployed a safe it was the OG proxy and network fees were an issue for my use case at that time. My work around ended up being swap and send but I didn’t need much more than that.)

If we focus on the narrative that SAFE is the ideal way to store assets on chain then we’ll see increased usage beyond external controls— toward better security principles and account abstraction instead.

TLDR; I resonate with the take back ownership concept and I truly believe that SAFE is critical infra and if we want to onboard the next million it’s key to foster an educational narrative while providing clear benefits to using SAFE above a standard wallet config

People juggle keys already. We we can make a better user experience if we can establish a clear reason for people to setup a SAFE by explaining the advantages of key rotation and account abstraction

A safe is the ideal solution for people we want to onboard and keep safe :wink:

7 Likes
7

The above feedback is greatly appreciated and overwhelmingly positive!

For the sake of constructive conversation, before moving forward we’d love to hear from other investors in SAFE, the SAFE team, core/power users, and anyone else with any strong opinions. If possible, please comment before the end of February or feel free to reach out to me on telegram (same username) if you’d like to discuss first.

6 Likes
8

We appreciate the well-thought out proposal, @lakejynch. Understanding that token utility is a fundamental milestone for future transferability, we love to see progress on this end. Some questions/comments from our team:

Integrating a dApp into the SAFE app’s front-end incurs a developer cost for the SAFE team.
Many protocols would like to be integrated into the SAFE front-end.

It would be great to get a sense of how large this problem is today from the Safe team and developers. If it is a sufficiently-sized bottleneck to Safe ecosystem growth, then we should look at whether solutions from a technical, devrel, educational or marketing perspective have been exhausted first. We worry that tying token utility to an issue that could be remediated with simpler methods is unnecessary and can hamper the overall development of a token utility plan.

We propose a mechanism whereby protocols stake a fixed percentage of the total supply of SAFE tokens to be included in the integration queue. In addition to staking, the protocols will need to post a front-end integration proposal (FEIP) on the Safe forum.

Regarding the FEIP mechanism, would you expect there to be governance bloat within the DAO? As more chains and apps are integrated, we’d expect that an enormous amount of tokenholder mindshare would need to be directed toward evaluating integrations instead of focused on long-term strategy and ecosystem development.

There is also the question of queue prioritization. The first come first served queue that is proposed seems to prioritize those that are early instead of focusing on highest quality or most needed integrations. We would love to see quality control in the resource provisioning process. We understand why making the process more transparent is a goal, but is decentralizing the listing process something that is vital enough to reach the level of tokenomics?

On staking, we really like the idea of SAFE as a token curated registry with staking by applications acting as a natural token sink tied to demand for integrations. This is something we’ve thought about heavily and are working with the Safe team on evaluating.

Priority listing in this front-end could provide material competitive advantages for protocols in highly saturated verticals (e.g. DEXs, borrow/lend, 4626 vaults).

It stands to reason that a DEX listed first in SAFE’s app store will generate more volume from SAFE users than a DEX listed further down in SAFE’s app store

The premise of this makes sense to us, especially when you look at comparative data in traditional e-commerce. It would be good to understand if this holds true in web3 though where an average Safe user is relatively sophisticated and likely understands which applications are available to them regardless of placement on the Safe frontpage. For example, would a DAO operator on a treasury multisig choose a DEX because of its ranking, or would a variety of other factors lead to a decision of DEX? If placement does not equate to better customer acquisition for an application, then it will directly impact the viability of a business built solely around the Safe front-end. With that in mind, it would be great to validate this with quantitative data before making a decision.

Additionally, it allows for a scenario in the future where lending protocols will allow protocols to borrow against their staked SAFE tokens as collateral, increasing their capital efficiency while retaining the core utility of their staked SAFE tokens

We agree that this level of capital efficiency is ideal for any staking design that is implemented. We are curious what your thoughts are regarding what happens in the unhappy case where a part of a protocol’s stake is liquidated - would it mean the protocol loses position/listing on the Safe front-end?

—

Overall, we agree that using a staking mechanism as a way for integration partners to signal commitment should be considered in the overall token design. Before moving on with implementation, we’d recommend checking some data points (e.g. the impact of top of page listings on user growth for applications) and widen the discussion to the exploration of a broader token design (i.e. are there other points Safe wants to monetize on that should be considered as part of the token utility conversation).

10 Likes
9

Great proposal, @lakejynch! Your assumptions make logical sense, especially in light of @adamhurwitz.eth’s comments about similar monetization strategies in Web2. However, as @AccelXR-1kx suggested, it would be helpful to validate this proposal with quantitative data. We conducted some research a few months ago which may be relevant to this discussion.
Our research analyzed the transaction history of Safe apps and found that since the beginning of recorded Safe app transactions, less than 1 million transactions were executed through Safe apps.

Of these transactions, 73.6% had an unspecified origin, 10% came from Wallet Connect, and 3.6% came from the Safe web app transactions. This means that less than 13% or 110k transactions came from apps for which the origin was specified, such as Uniswap, Transaction builder, 1Inch, ApeSafe, or Aave.

While this data may have changed since we collected it in September, it suggests that Safe app usage is still relatively low.

Chart1504×742 34.4 KB

This would mean where you feature in the platform isn’t all that valuable to an app builder. This is not to say that it can’t be in the future and that it could be a viable way to monetize SafeDAO. But the low transaction count suggests that the current selection of apps in the Safe interface do not sufficiently serve the needs of multi-sig users. So in order for us to capture value from the Safe app interface, we could focus first on making Safe apps valuable. We’ve written a post here which describes one way Autonolas is trying to do this.

Thanks for sharing your proposal and starting this discussion, it is an important one to have!

For the raw data on Safe app transactions please follow this link

4 Likes
10

Hey, @lakejynch! Thank you so much for putting together such a well-thought-out proposal - it’s clear that you’ve really put in the time and effort to think things through. I particularly love how your proposed goals tie in perfectly with SafeDAO’s own goals, which is all about building a vibrant ecosystem, promoting decentralization, and capturing value within the Safe ecosystem.

Front-end Integration Queue

Regarding the front-end integration queue, I think @AccelXR-1kx makes a good point about exploring simpler solutions before tying token utility to an issue like dev costs and increase in integration demand. The mechanism that requires protocols to stake a fixed percentage of the total SAFE token supply could make things a bit complicated.

That being said, I do think your idea for the Front-end Integration Proposal (FEIP) has a lot of potential in terms of creating more transparency around the integration process. However, we should definitely think about how we can design a framework that minimizes governance bloat within the DAO. I imagine somewhere along the line with the ongoing discussion about Outcomes-based resource allocation (‘OBRA’). Where we could let the “Adoption Initiatives” create a seasonal front-end integration committee to address these issues. Of course, we’d need to have checks and balances in place, and I think this could be a great way to streamline the process. I won’t go any further as this is probably a topic for another forum thread.

The first-come-first-serve process for the integration queue might not be the best approach, as it could prioritize early integrations over quality control and the most needed integrations. I like @adamhurwitz.eth idea of incorporating prioritization through a DAO vote per each time period “round” like Gitcoin Grants. This could allow us to ensure that we’re focusing on the integrations that are most important to the community.

App Market

Moving on to the App Market, I think it’s really interesting to explore the idea of developing a app marketplace around the Safe app front-end. It’s definitely a big opportunity, but I also believe we need to validate whether having better placement on Safe App would translate into increase in customer acquisition for these applications.

Thank you! @bradrian_0x for sharing your research from September on the transaction history of Safe apps, but it’s been almost half a year since then, which is a long time in the fast-paced world of Web3. I’m definitely curious and will dig deeper to see if there’s any recent additional data I can find to help us validate this.

Safe as Token-Curated Registry

One idea I have for the app market is to open up the option of staking for all holders and incorporate elements of ongoing conviction voting for the list of featured or curated apps. This would allow $SAFE token holders, including protocols, to signal and vouch their support for multiple applications ranked based on their allocation for each one. I can see this working along with FEIP in filtering out spam and malicious applications. Overall, this would essentially make $SAFE a token-curated registry with the voting power of all holders acting as a natural token sink tied to app placement or even integration demand. I think this would provide more transparency in the process of selecting trusted/curated lists and prioritization schemes maintained by Safe token holders. Let me know your thoughts!

3 Likes
11

You have my full support ! Well detailed proposal and the approach is the best IMO to capture value while retaining users

Again thanks for submitting such a well thought proposal :slight_smile:

+1

2 Likes
12

I like your concept of “upvoting” apps in the app marketplace based on either delegated or staked SAFE. This is an interesting idea to explore further.

Perhaps SAFE holders could delegate and/or stake to apps in the marketplace.

  • Delegate: Increase apps marketplace position by a weight of 1
  • Stake: Increase apps marketplace position by a weight of 2
    • App devs bid a fee for premium spots (Only pay the fee if they win the spot)
    • Fees are paid to SAFE stakers in the repsective apps that pay the fees
5 Likes
13

Let safety have higher value, which is also what we hope. Very good!

1 Like
14

Today’s Safe{Core} launch sparked more ideas for SAFE token utility.

Along a similar theme of providing valuable services to app developers with the ideas above in terms of marketplace and listing integration, the SafeDAO can begin to learn and develop a list of tools that app developers would be willing to pay for in order to outsource and operate more efficiently. For example, one of the reasons Apple and Google’s mobile app marketplace duopolies have remained and can charge developers 30% is because there are some valuable services they provide.

Services

  • App analytics: Safe must think about doing this in a privacy-first approach.
    • E.g. Stake different levels of SAFE to receive increasing levels of analytics info.
  • Developer access and permissions
  • Payment management
    • E.g. No or lower payment processing fees for paying with SAFE which allows app devs to pass on discounts to users who pay with SAFE.
  • Review management
    • E.g. Stake SAFE to earn a % of SAFE rewards for positive review milestones.
  • Other developer tools…

There can be a healthy balance to offer a great experience for free to users for the core Safe app and independent developers building on the protocol. Then advanced tooling would be paid options. It’d be valuable to learn as a next step what tools teams like Den, Firm, Multis, and etc. need and would want to pay for to operate more effectively.

6 Likes
15

@0xAA brought up a good point to me.

I don’t think charging developers is good to expand safe ecosystem.

I agree that we should prioritize developer growth and not focus too heavily on short-term revenue.

I’m interested to learn more ideas on this.

  • Is charging for tools that developers have communicated that are willing to pay for an exception to the above?
  • Is there a difference between having most core developer tooling free, and charging at a certain scale, such as for large enterprises? This is similar to an open-core business model.
4 Likes
16

The use of safe token payment can return the user’s gasoline fee or all of it. At present, this is also a good utility, but safe utility is far more than the above three points. I hope community members can join in the discussion.

1 Like
17

The ideas presented by @lakejynch and further iterations are really cool. As an addon, would workflows for example that empower maker checker sort of flow for projects that do custody be interesting?

Related to what @adamhurwitz.eth mentions here - market I was imagining something sort of like JIRA marketplace, where entities that want to use an addon module (provided by safe) can pay for it in SAFE tokens. This can be a monthly subscription as long as the SAFE holds enough SAFE tokens or the SAFE has enough tokens staked?

So this then would be frictionless to the SAFE core offering and would not be construed as charging developers. These apps then can compete with others provided by different parties.

2 Likes
18

Over the weeks, I’ve been examining the recent transaction data (March 2, 2023) available from the Safe Transaction API. I noticed that the API allows for an optional field to specify the transaction’s origin. Transactions that occur through the Safe App interface are in default assigned a specified origin. Therefore, I categorized any origins with Safe-related URL origins as originating from the Safe App Interface. With help from @bradrian_0x (thanks alot man!) and one of my colleagues in gathering and interpreting the data, I wanted to share the information I obtained with everyone. Hopefully it can be used to support ongoing discussions around Safe Token utility, providing data to inform decision-making processes.

Based on our analysis of Safe transactions data, we found that the majority of Gnosis multisig transactions do not have a specified origin. This suggests that most Safe multisig users do not initiate their transactions from the integrated DApp from the Safe App interface. Furthermore, of all the transactions, only 6.8% are with Safe App origins.

image
image724×421 13.5 KB

  • Approximately 80.7% of Gnosis multi-sig transactions do not have an origin.

    image
    image701×422 15.1 KB

  • Of the approximately 19.3% of transactions that do have an origin

    • 35.1% of transactions are with Safe App origins
    • 64.3% of transactions are with other specified origins
    • 0.7% of transactions are with specified numeric origins
      image
      image729×442 14.2 KB

Please note that there were several limitations on the data collection and some uncertainty on labeling origins, and therefore our findings may not be conclusive. Nonetheless, this information is a good starting point for further investigation on Safe user research/analysis, and it’s definitely helpful for getting a sense of how much volume is going through the Safe interface.

Additional comment:
Further research is necessary to understand why users are not using the Safe App interface. It is possible that Safe multisig users may not be aware of the benefits and ease of use that the Safe App interface provides, or that they prefer to use other interfaces for other reasons. To gain a better understanding of user behavior and preferences, conducting user surveys or focus groups could provide valuable insights, which can inform future development and marketing efforts.

Moreover, to capture more value for the Safe Token, it may be worthwhile to explore ways to incentivize or encourage Safe App usage (if we want to go towards app market direction). For instance, providing gas sponsorship for users who execute Safe multisig transactions through the Safe App interface could encourage more users to adopt the interface.

In conclusion, while the current usage of the Safe App interface is low, there is potential to increase adoption and capture more value. Further research into user behavior and preferences, as well as strategies to incentivize Safe App usage, can help achieve this goal.

10 Likes
19

Great insights @v3naru and thank you!

Is it possible to estimate which app UI’s are being used to initiate transactions if not from Safe?

1 Like
20

Safe can build its own layer2 network through cosmos or Optimism, and building an application chain can improve the application scenarios of Safe. It can act as gas, and can stimulate and prosper the safe ecology through the main network.

21

Since most of the tx data I got from the API does not have specified origin, it’s hard to tell where the majority of those tx are initiated from. However, for other specified origin there are some that do use their own specific dapp url which suggest that they are using the dapp’s UI. For instance:

{"url": "https://app.zerion.io", "name": "Zerion"}
{"url": "https://app.uniswap.org", "name": "Uniswap"}

suggest that they were initiated via Zerion and Uniswap’s dapp interface respectively. However, if we break it down into each individual dapps - The total tx is still relatively small

1 Like
22

@v3naru, Is it possible the origin of the transactions are not discernible if most of these transactions are being initiated on-chain by other smart contracts, and not initiated by other user facing frontend apps?

23

Yes, I think that could be the case as well, but since origin field is optional, which means that we are assuming that transaction creators are inputting the data truthfully.

1 Like
24

This is very helpful data.

I would consider it an invalidation for the concept of sorts, or at least, until there is a materially change in user demographics (towards more retail). We’re working on a new idea that relies less heavily on the UI/UX. In the meantime, would love to keep hearing these great ideas as they provide a lot of inspiration.

4 Likes