Author(s): Jake Lynch, L1 Digital
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:
- 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.
- 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.
- Token Mechanisms Should be a Feature
Users should be excited about what a token mechanism unlocks, rather than burdened.
- 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.
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.
- 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.
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!
- 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.
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.
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.
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!