Please refer to the full proposal text on the SafeDAO forum. Some parts needed to be removed to fit within the character limit on Snapshot: https://forum.safe.global/t/sep-21-safe-token-utility/4802
This proposal outlines strategies to enhance the utility of the SAFE token (“SAFE token” or “SAFE”), inspired by ideas from the Safe community. The ratification of this SEP completes milestone E as specified under SEP #3 (“Towards clarity on milestones before voting on enabling transferability again”). It also plans for future token utility expansions, emphasizing community involvement in the further development of the SAFE token utility.
State which proposal type this proposal belongs to.
[] SEP: Constitutional Proposals
[ ] SEP: Governance Proposals
[X] Other SEPs
This proposal outlines suggestions to expand the utility of the SAFE token. The token utility ideas that were collected from the Safe community served as a key input for this proposal.
This section examines the primary goals and guiding principles that shape the utility of the SAFE token, ensuring strategic alignment with the Safe ecosystem's overarching objectives.
Safe enables users to own their digital assets in a secure, convenient and interactive way, which will require smart accounts (also known as smart contract wallets) to become the default in web3. This is also reflected in the mission outlined in the SafeDAO Constitution:
“SafeDAO’s mission is to establish smart contract wallets as the default means for interacting with web3 [...] As SafeDAO, we aspire to work towards this mission by establishing standards for composable smart contract wallets (the “Safe Protocol”).” (SafeDAO Constitution, “2. Mission”)
The SafeDAO Constitution further bases this mission on three strategic pillars / goals that impact the SAFE token utility:
OBRA: The resource allocation framework OBRA derives strategies and initiatives from the above goals and establishes processes for resource allocation. While not impacting the token utility design space directly, OBRA needs to be considered for funding future explorations and implementations of token utility.
The Safe Smart Account has become a trusted infrastructure in the web3 ecosystem, currently securing over $100bn in assets. Given the broad potential applications for the SAFE token, this section suggests a strategic direction and guidelines for developing and integrating token utilities, aligned with SafeDAO's mission. This strategic focus serves as guidelines for future explorations and implementations of token utilities and the respective growth of the Safe ecosystem.
Any explorations of token utility should be merely seen as preliminary conceptual ideas, which are likely to be subject to substantial change, as token utilities could also be explored beyond the ones mentioned in this SEP as long as they fall into the SAFE token utility design space defined below. There is NO guarantee and NO warranty that any of the mentioned utilities are being explored and/or being implemented in the future.
At the core of this strategy is Account Abstraction, the foundation enabling smart contract-based accounts. For smart accounts to become a mainstream option, they must offer clear, tangible advantages to both developers and users. These benefits will be facilitated by the Safe Core Protocol, encompassing different ‘abstraction layers’. These abstraction layers can be implemented separately but will eventually be strongly interconnected.
1. Account Abstraction (“Smart Accounts”)
Account abstraction is the basis for enabling smart accounts to interact with web3 applications. Initiatives such as ERC-4337 empower and standardize smart accounts, enabling new use-cases such as passkey-controlled accounts, recovery schemes, or seedless onboarding. However, account abstraction itself is only a first step towards achieving mainstream adoption of smart accounts. Additional challenges have to be solved to fully unlock the potential of advanced security, payment and network properties of smart accounts.
2. Network Abstraction (“Smart Link”)
The Network Abstraction Layer aims to simplify the fragmented blockchain network landscape, enabling a seamless experience across different chains. This layer introduces a framework that significantly enhances cross-chain functionality, fostering a more interconnected ecosystem. An example of this abstraction layer is the ability of a Safe Smart Account to control assets on multiple chains and make cross-chain interactions (see also the discussion on the community forum).
3. Username Abstraction (“Smart Domains”)
Username Abstraction offers an intuitive way to navigate the blockchain's complexity by replacing cryptic blockchain addresses with human-readable names, combining existing solutions like ENS (SafeDAO holds safe.eth) with smart contract wallets (e.g. leveraging solutions like Nameverse or similar). The SAFE token could potentially be used to e.g. claim usernames on a designated namespace. This abstraction layer not only enhances user experience but also paves the way for new economic models based on domain registrations or renewals (Some discussions were held on the community forum on this topic, including this thread).
4. Payment Abstraction (“Fee Engine”) Traditional payment functionalities, such as recurring payments and subscription models, are still underutilized in the web3 space. The objective of payment abstraction is to bridge the gap between conventional payment systems and the evolving web3 payment infrastructure and enable economic sustainability for the Safe ecosystem. An initial proposal for payment abstraction is the Fee Engine. The SAFE token could potentially play a role around the concept of a payment splitter (suggested by @varunkcs). Additionally, the proposal also outlines the concept of an Ecosystem Contribution, which allows to support community-driven initiatives within the Safe ecosystem via SAFE token governance.
5. Security Abstraction (“Registry”) Smart accounts enable opportunities to create new onchain security primitives that protect users. One example is the introduction of registries (e.g. by leveraging Rhinestone, ZenGuard or similar solutions) as a way to establish stronger security properties and enforce standards for smart account modules. An initial architecture can be found on GitHub. On the SAFE token’s role, several ideas were put forward by the community (@CryptoEconLab, @varunkcs and @Abraxas, @LongHash_Ventures and @LuukDAO). Examples include mechanisms around the curation on a module registry, or a “security module” that acts as a protocol-native insurance.
Future Abstraction Layers There may be additional abstraction layers that become relevant for the Safe Core Protocol. This may include privacy abstraction, such as adopting a UTXO model or stealth addresses (as suggested here), or compliance abstraction that enables privacy without sacrificing on compliance. Generally, the Safe Core Protocol aims to enshrine components where the value of standardization is higher than the value of heterogeneity.
The SAFE token utility should intentionally not be part of the Safe Smart Account itself. Having the SAFE token be a requirement for developers using the Safe Smart Account may hinder its adoption or even lead to forks. This can negatively impact the ecosystem consistency as well as inclination of certain developers to adopt Safe Smart Accounts in their solutions. Having a commitment from the SafeDAO to keep the base smart account functionality independent from the SAFE token allows for a more aligned ecosystem to be built around the Safe Smart Account. This allows the ecosystem as a whole to become more valuable, which will ultimately benefit other layers of the stack such as the Safe Core Protocol.
This section lays out a proposal, to be ratified by the SafeDAO, on the SAFE token utility as well as potential opportunities for future explorations of additional utilities.
SafeDAO is governed using the SAFE token (see SafeDAO Constitution). Governance should remain a key utility of the SAFE token, which was also indicated by the community (see for example token utility proposals from @varunkcs @LuukDAO around the votings on the allocation of resources, including grants).
SAFE token holders can vote within the scope of governance of SafeDAO. They can vote with their vested and unvested tokens and delegate their voting power.
The following domains are part of the governance of SafeDAO (for more details on the scope of governance see Section C of the Governance Framework):
Constitution (see SEP #4)
Governance framework: This encompasses the scope of governance, dynamic governance, decision-making process and principles of proposal implementation (see SEP #7)
Resource allocation framework (see SEP #8)
Assets held for SafeDAO (see “Treasury” in the Governance Hub)
Safe Grants Program with funding and administrative support provided by SEF (see SEP #6)
SEF governance signaling: Suggestion (“social signaling”) regarding the establishment and composition of DAO committees, once established by the Foundation
Unpausing of SAFE token transferability (see SEP #2)
Safe{Core} Protocol: Parameters and other governance-related aspects, once they have been transferred to the governance of SafeDAO
This proposal introduces the Safe Activity Program, which incentivizes Safe users to actively participate and contribute to the Safe ecosystem (both onchain and offchain activity that is deemed valuable could potentially be considered, but also depends on factors such as technical feasibility). By actively using the Safe Smart Account, users participating in the Safe Activity Program display dedication to the long-term success of Safe. In return, these users become eligible for discretionary activity rewards, such as additional functionality, discounts, or other benefits. The Safe Activity Program would be designed to benefit and involve the entire Safe ecosystem.
The exact scope of the activity rewards will have to be worked out. But rewards could consist of for example:
The SAFE token gets an additional activity related use-case as part of the proposed Safe Activity Program. Locking SAFE can boost/multiply the rewards the participants receive from their activity in the Safe ecosystem.
Any SAFE tokens that eligible users would be able to claim will be funded from the remaining user allocation. This discretional Safe Activity Program would run over a limited time of up to 6 months, afterwards it will be revisited for potential extension by the Safe Ecosystem Foundation. This allocation serves a two-fold purpose:
1. Expand the number of token holders: The Safe Activity Program increases the token allocation of each participating user. By providing additional utility, the Safe Activity Program should attract more stakeholders who do not currently hold a SAFE token and are active Safe users. 2. Strengthen the user allocation for active users: Offering Safe Activity Program rewards benefits all active Safe users. This gives each user the opportunity to individually influence their allocation relative to others through activity.
The initial Safe Activity Program rewards already provide various benefits for active token holders participating in the Safe Activity Program. The program should also help bootstrapping the adoption of the SAFE token. However, it is designed as a composable mechanism that can be adapted or expanded over time through future community initiatives, such as expanding the program to networks beyond Ethereum L1.
This SEP should be seen as a first step / foundation for ratifying and exploring the token utility of SAFE. As the Safe{Core} Protocol evolves over time, the design space of utilities for the SAFE token will naturally expand.
Below summarizes some early themes identified from community feedback on the proposal, as posted on the SafeDAO forum and discussed during a community call. They narrow down the strategic focus into more concrete ways how the SAFE token can obtain additional utilities. A thorough analysis is required to take into account legal, regulatory, technical and feasibility considerations before any implementation. Any explorations of token utility should be merely seen as preliminary conceptual ideas, which are likely to be subject to substantial change, as token utilities could also be explored beyond the ones mentioned in this SEP as long as they fall into the SAFE token utility design space defined above. There is NO guarantee and NO warranty that any of the mentioned utilities are being explored and/or being implemented in the future.
Canonical DeFi features / modules An area to explore is use cases that link DeFi modules to SafeDAO. Currently there are over $100bn in assets stored on Safes, and DeFi modules could enable asset owners to use their assets more productively. Potential examples include canonical swap, stake, bridge, stablecoin or flashloan modules. Through those modules, the abundant liquidity could be tapped into by others, and an Ecosystem Contribution similar to the one proposed in the Fee Engine link back to SafeDAO.
SAFE Staking This idea suggests that the proposed activity program for the Safe ecosystem, which involves locking SAFE tokens, could potentially evolve into a form of staking. As the abstraction layers are being built out, different components will have the need for economic security to be provided through staking mechanisms. This could allow SAFE token holders to engage in various staking opportunities as they develop within the ecosystem. A framework could be developed which, similar to restaking, enables SAFE holders to choose among different staking mechanisms, possibly even simultaneously participating in different security models. The different available staking mechanisms could be governed by SafeDAO via an onchain registry, ensuring that they are aligned with SafeDAO's interest and security standards.
Fee engine Several community members highlighted the “fee engine” as an initial concept that should be prioritized and iterated on. In this respect, it is important to determine which products and services the market is willing to pay for. Another aspect is to balance fees (determine what should remain free/affordable and what a fair market rate could be).