SAFE Token Utility Proposal

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

@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?

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

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
1 Like

Thank you so much for these ideas , In addition to the proposal outlined above, there are several other potential value propositions for the $SAFE token:

Governance: The $SAFE token can be used for governance purposes, allowing token holders to participate in decision-making processes related to the development and evolution of the Gnosis Safe application. This could include voting on proposals for new features or upgrades, as well as participating in discussions about the direction of the project.

Rewards: The $SAFE token can be used to incentivize users to take certain actions within the Gnosis Safe ecosystem. For example, users could be rewarded with $SAFE tokens for referring new users, or for using certain features of the platform.

Discounts and Benefits: The $SAFE token can be used to provide discounts or other benefits to users who hold a certain amount of the token. This could incentivize users to hold and use the token, as well as create a sense of loyalty to the Gnosis Safe ecosystem.

Network Fees: The $SAFE token could be used to pay for network fees associated with transactions within the Gnosis Safe application. This would create demand for the token, as users would need to acquire it in order to use the platform.

Overall, the $SAFE token has the potential to provide value to users and stakeholders in a variety of ways. The specific value proposition will depend on the goals and priorities of the Gnosis Safe team, as well as the needs and preferences of the broader community.

4 Likes

Excellent research ser! Well done :fire:

Anecdotally, I have encountered a few people who were not aware of the safe app but had multisigs.

It would be incredibly advantageous to develop a way to encourage people to use the official app. I lean towards my comment from January. Integrations that drive legitimate Safe app usage could get rewards in some manner. Either via attention/overall usage, retroactive rewards, # of daily active users etc.

2 Likes

Hope to safe making something different in web3 era

1 Like

This would require transferability, no?

2 Likes

Wondering if there is an update on the protocol designer position here, I saw it was removed from safe career.

2 Likes

Hi!

I think that now is a great time to resume this discussion and understand what the next steps necessary to solve

For a complete picture, need to take this discussion

1 Like

Definitely , this was submitted by @lakejynch almost 1 year ago and we should’ve been already set. Worth considering interesting points / suggestions have been made. Let’s get involved more and draft a valuable utility for $SAFE.

1 Like

Value Capture Not Tax :+1:

1 Like

Is it possible to resume discussion on this topic please ? I have the impression that the discussion was put on hold due to market conditions, but it seems appropriate to resume now. :slight_smile:

4 Likes

@RSivakov, @Billion, @cedricoo. Agree that now is a good time to continue the token utility discussion. Fwiw, going through the proposals in the submission thread, I took a stab at mapping and categorizing the stakeholders that have been mentioned in the proposals submitted so far.

Taking a step back helped me to get a clearer conceptual view of which groups we need to consider to bring more innovative token utility ideas to the table.

Consolidated Categories of Stakeholders:

  1. Development and Infrastructure:
    • Module Developers, Dapp Builders, Registry Maintainers and Managers, Auditors:
      Focused on developing, securing, and enhancing the Safe infrastructure. According to submitted proposals they might be engaged in activities like registry management, fee taking, revenue swaps, escrow fee taking and registry staking.
  2. Ecosystem Management and Governance:
    • Councilors, Treasury/Governance, Working Groups:
      Responsible for the overall governance, policy-making, grant distribution, and ecosystem oversight.
  3. Users and Community Engagement:
    • Retail End-Users, New and Existing Community Members, Token Holders: Might be engaged with the ecosystem through using modules, purchasing them, token swaps, fee taking, participating in staking, and benefiting from mutual insurance and audit systems.
  4. Research, Education, and Talent Development:
    • Researchers, Educators, Top Web3 Talent, Grant DAOs:
      Involved in research and development, educational initiatives, and talent development through grants, bounties, and fellowship programs.
  5. Commercial, Financial, and Investment Interests:
    • Investors, Token Holders, Enterprises, Accelerators:
      Focused on financial aspects like staking, token swaps, collateralized debt positions, and accelerating commercial projects within the ecosystem.
9 Likes

I agree that token utility should be the primary focus until:

  • Founders, early adopters and investors have the ability to exit and reap the rewards of the risk they took on

  • A basic revenue and subscription model is created and scheduled to be implemented when our customers have Safe sufficiently engrained into their business model so that leaving Safe is not a fiscally responsible decision

  • Safe has clearly established how DAO members aka all current and future Safe token holders will, by default, make a significant contribution to the network and business model simply by holding the token.

  • Safe has clearly addressed identity and KYC within the scope of regulatory compliance. Safe ABSOLUTELY NEEDS to be proactive in this regard even if it means approaching the SEC/CFTC/FINRA before they come knocking on the door

It’s very important to remember that every founder, early adopter, and investor of every company - public or private, blockchain or non-blockchain- has the basic right to profit from risking their own capital and or resources to potentially benefit the company The only thing the company must do is follow the rules and precedent that have been in place for the last 90 years. If the company does this correctly, then there’s nothing to worry about along these lines. Does a DAO legally have to be a public company? Not at this time. Food for thought.

I am all for full autonomy and a brilliantly designed network. But sometimes things need to be taken in multiple steps. If we can find simple method while working toward the greater idea, we will have more $ and resources available during that 2nd ‘greater stage’. If any of the below is impossible on Safe because of technical limitations, please let me know. I am an early adopter through a company I founded, have multiple Safes but am by no means an expert on Safe development. This is something I must brush up on in the near term.

Questions:

  1. Thoughts on allocating grant funds to creating a rock solid plan for the next 5 years along with a “Utility team” who understands engineering, business, the regulatory environment, and anything else deemed important within the scope of token utility? I am not saying anyone currently working on this shouldn’t be - I am saying monetary incentives can go along way in pushing things ahead more efficiently. Just like staking rewards do for blockchain networks.

  2. Why can’t we keep it simple for the time being and institute a simple NFT based subscription model similar to what pinata has going on?

  3. Again keeping it simple for now - can we plan to require all subscription payments be made in SAFE tokens via Gnosis Pay? Create USDC to SAFE swap pair specifically for this purpose allowing demand to dictate the cost of SAFE. Thereby solving a portion of the utility question with intent and a documented plan of action. This is how the ‘Open Blockchain Token’ regulations work in the state of Wyoming, USA.

  4. What about a simple system where SAFE token holders and wallet users contribute a portion of network bandwidth and or SAFE liquidity for sub payments?

  5. Anyone have an opinion on SAFE’s total value or market cap?

  6. Who’s in communication with Safes VC investors?

  7. Has SAFE contacted the SEC and or received SEC approval for EDGAR access and filing capabilities? I did this myself for the company I founded - a US based DAO LLC that also has a US Gov’t issued SAM number which is required to be eligible to win US Government contracts. My point is, I have experience with this and can help in this regard if needed.

  8. Has anyone discussed a tender offer? Where Safe offers to buy back some of the tokens from early adopters and investors. This would quell the concerns of those who believe they should have the ability to reap some of the rewards by now and those who don’t want to enable transferability yet.

With the recent market move up, SAFE has between $60-$70 billion of assets in custody and 75% of the defi market as its customers. We have the potential to pull off something similar to the Oracle Database (founded in 1977) model and it is time we take advantage of the opportunity before us!! Does everyone realize that there’s talk that the SEC is going to approve Bitcoin spot ETFs across the board in early January? Does everyone realize BlackRock will be investing trillions in the blockchain space? This is the moment we’ve been waiting for. No regrets!

4 Likes

Can we press ahead this proposal to Season 1 - Sprint 2 ?

2 Likes

You’ve highlighted lots of important long-term initiatives.

Thoughts on allocating grant funds to create a “Utility team”?

  • I would pick a specific opportunity, initiative, or issue to focus grants funding on first before creating any new entities
  • This would be a proof-of-concept (PoC) to begin to prove out the need for a “Utility council”
  • It’s likely easier to receive funding for a specific project than forming and funding a new team/council
3 Likes

Also can’t wait for this to be put to next stage. However, imo, I think we’d be wise to not prematurely rush it into this sprint just for the sake of timing for two reasons:

1. Regulatory Clarity
Imo, some of the points @rmourey26 made regarding regulatory certainty are valid. We would be wise to achieve a deeper level of regulatory and legal understanding before presenting the condensed token utility proposal. This would also save us unnecessary time and mindspace, i.e., can avoid discussions on utilities that may not be legally feasible in the first place.

2. Implications of OBRA
We should conclude the underlying elements of OBRA (e.g., details on strategies) to the extent that we understand its implications on Token Utility (e.g., determining if parts of this will be funded through OBRA). I recall this being a topic in the last community call and there is still a very active discussion around it. @adamhurwitz.eth being mindful that you contributed a lot to the OBRA discussion already, would be amazing to get your view there.

Would love to hear others’ opinions on this.

2 Likes

Yes, that would make sense in my opinion.
@Andre maybe you could take a look at this discussion?