SAFE Token Utility Proposal

[lakejynch]

Author(s): Jake Lynch, L1 Digital
Created: 2023-01-26T05:00:00Z

Goal

This proposal outlines a mechanism for the SAFE token that would create a sustainable value proposition for the token. To accomplish this task, we have some high-level goals:

1. Value Capture Not Tax

Whenever possible, a token should not create a tax on existing users. A tax disincentives use of the platform and opens up opportunities for competitors (crypto case studies for this include: Uniswap <> Sushi and Opensea <> Looksrare). Rather, a token for a primitive should unlock the unique value of the dApp, which will have it’s own inherent value beyond cash flows. In traditional business models this is analogous to the “freemium” model.

2. The Token Should Solve Problems

Crypto tokens are an improvement on opensource in that they can be used to incentivize work. Effective token models turn liabilities into assets. You’ve heard the expression “one man’s junk is another man’s treasure,” below we describe a utility that does just this: it reworks a cost for the development team into a feature for users.

3. Token Mechanisms Should be a Feature

Users should be excited about what a token mechanism unlocks, rather than burdened.

4. Staking is Better than Burning

Staking is always better than burning for two reasons. First, with regards to adoption, purchasing tokens for staking can be treated as an investment (similar to a company buying PPE). These types of spends are always easier to justify since they have recoverable value.
Second, with regards to alignment. Imagine two models, one where the users stake the token to get the product and one were the users burn the token to get the product. In the former, as usage increases, the user holds MORE of the token. In the latter, the user holds LESS of the token. For both of these reasons, this proposal focuses on a staking model.

Abstract

In this proposal we outline two use cases for the SAFE token. These use cases are not mutually exclusive, nor are they interdependent. They are also not necessarily the only use cases that can be implemented. Rather, we believe they are fundamental building blocks to (1) unlocking the value of the SAFE application, (2) solving immediate problems relating to developer work, and (3) further decentralizing the SAFE ecosystem.

In order to implement both of these components, we will need a staking module and a whitelisting module for dApps. Both of these components are intended for P2P (protocol-to-protocol) use-cases, rather than B2C or B2B.

Proposal details

Part 1: Integration Queue

Rational

• 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.
• The process for integration is currently opaque and relatively centralized.
• As a community, we do not want to integrate every application for various reasons.

Proposal

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. This process is semantically similar to MakerDAO’s collateral onboarding application (MIP6). Following an on-chain vote indicating the DAO’s approval of a specific protocol’s FEIP, the protocol’s staking address will be appended to an on-chain whitelist with the protocol’s name. The integration queue will be a first come, first serve process and the SAFE core team / foundation should allocate resources to integrate these protocols into the front-end. Note that this both decentralizes the listing process and reduces the workload on the Safe core team. After integration is complete, the protocol will need to maintain this level of stake to remain in SAFE’s front-end integrations. We’ll need some RPC solution to monitor this. I recommend RPCh!

Part 2: App Marketplace

Rational

• While we believe the SAFE protocol should remain permissionless, there is no reason not to leverage the SAFE front-end for value capture.
• The SAFE front-end is effectively the web3 equivalent Time Square billboard.
• Priority listing in this front-end could provide material competitive advantages for protocols in highly saturated verticals (e.g. DEXs, borrow/lend, 4626 vaults).
• Currently, the placement of applications in SAFE’s app store is also opaque and centralized.

Proposal

SAFE’s front-end is of critical value for the future of crypto. As multi-sig and fully custodial solutions become the norm for users ranging from independent to institutional, it is clear that no-code solutions will retain and even gain value. The SAFE front-end should capture the value of the “digital” real estate on the front-end application.

We propose a mechanism (building on top of the mechanism discussed in Part 1) whereby protocols can increase their stake to gain favorable positioning on the SAFE app page. As protocols become commoditized, their spend should shift from improving efficiency to increasing usage. 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 delta in value here is value capture that we can transfer to SAFE holders. Furthermore, since this proposal will motivate protocols to become SAFE holders, they will be mutually benefited by this value capture. 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.

If there is sufficient interest, we are happy to build a model to test the impact of variables, such as % thresholds for staking, in this proposal.

Requirements & Costs

In order to implement both of these proposals we will need a staking module and an RPC solution. The former can be developed internally, and for the latter, we recommend a solution like The Graph, which can provide a fully decentralized data feed for Safe’s front-end. It’s important to understand that these proposals are modular, if designed properly, they can be turned off and on and other monetization methodologies can be incorporated.

We will also need to draft and agree upon a template for FEIPs.

About Us

L1D is a crypto-native asset manager. We invested in the Safe round this previous year. As active users of the protocol we are extremely bullish on Safe’s potential!

---

We would love to hear your feedback and if this is interesting to you, please signal your interest. If there is further information required, we are also happy to address any such concerns.

If there are strong opinions against this proposal, we encourage you to voice them!

[Melodic_Platypus]

Detailed and well thought out proposal. This utility is an obvious must as you’ve pointed out that Safe is like a billboard to the dapp world. You have my support.

[adamhurwitz.eth]

Thank you for the clear and strategic proposals @lakejynch! Both the integration queue and app market aim to solve for existing inefficiencies in the Safe ecosystem by building processes and rules that are open and implemented through code. Both proposals take a practical approach for SAFE token utility which seems like the right place to begin.

Then, after practical applications we can explore experimental use cases. Pro features for organizations and businesses is an interesting area to explore. It also aligns with the ethos of providing valuable public goods to individuals for free and adding value for orgs and businesses at a recurring price that is profitable to them.

Part 1 – Integration queue

Front-end integration proposals (FEIP)

• The on-chain SafeDAO FEIP vote is a great way to move towards more decentralization of the app integration process.
• As part of building this utility we should also define and outline the existing integration process with the help of the core Safe team to better understand areas to improve.
• Reducing the workload of the core Safe team would be great. They won’t need to spend as much time and energy on prioritization given an effective DAO process.
• The DAO could also own a larger part of the educational onboarding process in terms of educating potential apps on the technical requirements and governance process.

Prioritization

There will likely be apps that have a potentially higher impact to the ecosystem and would be beneficial to prioritize. The DAO vote could incorporate an element for prioritization.

• I imagine the core team would be able to communicate a goal of integrating X apps per N time period.
• The DAO would vote per each time period, “round”, similar to Gitcoin grants, on which apps to integrate and the prioritization.
• Perhaps there is a way to balance an element of both first come first serve and prioritization.

Part 2 – App market

Building a marketplace around the Safe app is a big opportunity.

Organic vs paid

• It’s important for us to think through how much of the app feed should be organic vs. paid.
• I worked with mobile app developers while at Google to help apps optimize their Google ad spend. The Google Play store has a mix of mostly organic content with purchaseable ad spots. I don’t know what the current ratio is. Let’s call it 90/10 organic/paid.

Customization

• There is a lot of potential for customization of recurring ad revenue.
• The most expensive spots sold were the US YouTube mobile mastheads that show first thing when opening youtube.com or the mobile app with different ad placements and prices per country and day.
• There could be an option to select different views of the app store.
  • "Curated”: Shows the organic apps derived through SafeDAO methodology and paid app spots.
  • “Custom”: User manually selects and saves apps to display in their app feed. Perhaps this is a paid feature paid in SAFE.

Analytics

• There needs to be analytics within the Safe apps marketplace to prove the value of app placement for dapps.
• Analytics need to be non-intrusive and open-source.

[wjw12]

Good proposal! Think of a decentralized App Store where those apps that get listed / get recommended are governed by SAFE community.

[adamhurwitz.eth]

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.

[raynemang]

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

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.

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.

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

[lakejynch]

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.

[AccelXR-1kx]

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

[bradrian_0x]

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.

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

[v3naru]

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!

[Billion]

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

+1

[adamhurwitz.eth]

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

[qianwan_lv]

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

[adamhurwitz.eth]

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.

[adamhurwitz.eth]

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

[qianwan_lv]

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.

[cryptobugbear]

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.

[v3naru]

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.

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

  

• 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
    
    

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.

[adamhurwitz.eth]

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?

[lvbatou123]

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.