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