Token Design: Exploring the Safe{Core} Protocol
This article provides CryptoEconLab’s thoughts on SafeDAO’s request for community input to identify areas in which the Safe{Core} Protocol’s utility token (SAFE) can help support the ecosystem’s objective.
Introduction
The Safe{Core} Protocol is a modular, open-sourced framework that aims to advance the transition to smart accounts on the Ethereum Virtual Machine (EVM). Currently, externally owned accounts (EOAs), are the standard for users to transact on the EVM. However, Safe argues that EOAs are a flawed standard that suffers from a poor user experience (UX) which reduces the likelihood for EOAs to scale to a wide user base. Transitioning to smart accounts can address the UX concerns inherent to EOAs and onboard the “next billion” users to blockchain economies.
Safe published a whitepaper draft that discussed the initial design of the Safe{Core} Protocol and presented a unified standard to catalyze the transition to smart accounts.
The protocol attempts to address the following problems:
Fragmentation: Ensuring composability for dApps and tooling through standardized modules namely, Plugins, Hooks, Function Handlers, Signature Validators, etc
Vendor Lock-In: Ensuring interoperability and portability of accounts by being vendor agnostic, upholding the freedom of choice and discoverability for service providers among users
Security: Introducing Registries that reduce smart contract risk and provide robust security guarantees
The Manager is introduced as an abstraction layer to manage the interdependencies and interactions between Registries, Accounts, and Modules.
Designing a Utility Token
Principles and Objectives
The Safe team released a whitepaper draft to gather community feedback on refining the protocol’s design. As part of this exploratory phase, the team requested community input in designing the SAFE Utility Token and identifying areas in which the token can support the protocol’s objectives. SAFE token mechanisms can:
- Incentivize the productive participation of key stakeholders within the ecosystem
- Facilitate access to a marketplace centered on composable smart account security across accounts, registries, modules, and end retail users.
Ultimately, token mechanisms should have the above properties whilst also linking the growth and utility of the ecosystem to SAFE value accrual.
Identifying Key Stakeholders
The SAFE token could have several potential stakeholder groups that contribute to the core protocol’s robustness and utility, transact for goods and services, and ultimately benefit from token incentives and mechanisms that support sustainable token value accrual. Some key groups, based on the protocol’s initial whitepaper and design, are isolated below:
- Retail Users/Clients: These would be end users of the Safe{Core} Protocol, who desire account functionality facilitated by the Manager’s interaction with the set of modules available within the Registry set.
- Module Developers: Modules extend the functionality of Accounts (types include Plugins, Hooks, Signature Validators, and Function Handlers, but others can be added over time). Productive module developers support the utility of the ecosystem (and therefore the utility of the tokens) and should be compensated via the protocol’s smart account marketplace.
- Registry Maintainers: The Registry serves a critical function in the Safe{Core} Protocol by ensuring all Modules comply with prescribed rules. The Manager interacts with the Registry to access approved modules. Registry maintainers are stakeholders that maintain this approved module list.
- Auditors or (“Challengers/Verifiers”): There is some overlap here between Auditors and Registry Maintainers, but Verifiers exist specifically to ensure module compliance with rules.
- Token-Holders: Currently, token holders can use SAFE to express a preference on SafeDAO governance matters (ex. SafeDAO constitution)
Each stakeholder group contributes to SAFE’s secure smart account marketplace, but an integral component to the Safe{Core} Protocol’s value proposition is security and interoperability for smart account users. Therefore, registry maintainers, developers, and auditors are critical ecosystem stakeholders since they directly impact smart account security. Token incentives should prioritize aligning rational incentives of these participants to support this aim.
A “Safe” Framework for Incentive Mechanism Design
Identifying stakeholders and their desired behaviors helps inform protocol incentive design. CryptoEconLab provided some example incentive mechanisms and desired stakeholder interactions in the Safe community forum in response to Safe’s request for community input. A number of ecosystem participants have also provided valuable input on token mechanism design questions (e.g., Longhash posted a Safe Value Alignment Program).
An important task ahead for Safe protocol designers is to cohesively synthesize and integrate these design mechanisms suggestions in the Safe{Core} Protocol. Further work should investigate the parameterization and implementation of these mechanisms (for designs based on some form of emissions, staking, and/or slashing). However, value capture for economic participants is largely affected by the macroeconomic supply and demand dynamics of the token; prior to the design and implementation of individual token mechanisms, a useful starting point for cryptoeconomic design should be to analyze the current and future desired state of token supply and allocation. Sustainable tokenomics is in part an exercise in understanding token issuance, consumption, and allocation at a macro level.
Therefore, token designers should understand the impact specific incentive mechanisms and their interactions have on the larger token economy. While an individual token mechanism may help align and incentivize a specific desired behavior, it may have other consequences on the larger token economy. For example, many utility token economies benefit from bootstrapping initial work from early contributors and stakeholders via token rewards (commonly this is block reward minting). Token rewards can be a critical step in generating enough initial economic activity and investment to attract users and further development before marketplace maturation (in Safe’s case this will be the maturation of the marketplace surrounding Registries, Modules, and Accounts). The tradeoff to balance is the dilution of value for existing token holders and users from token creation.
In future iterations of the Safe whitepaper, the team is expected to introduce more information on the token design. Evaluating and iterating on this initial design will not only benefit from a critical examination of ecosystem goals and objectives, but also rigorous simulation, modeling (ex. mechanistic twin), and testing to increase conviction that token incentives will have positive, and not adverse, effects on the token economy’s health. While the design of specific incentive mechanisms is important, it is even more crucial that they fit into the larger narrative of a healthy token economy.
Conclusion
The Safe{Core} Protocol has an ambitious goal to be a core public good infrastructure that accelerates the transition from Externally Owned Accounts to smart accounts. A thoughtful approach to incentive design will play an important role in supporting this objective. However, it is likely more important for the ecosystem to create real utility, and deliver smart account security, discoverability, and functionality to onboard “the next billion users.” The token should be designed to incentivize and benefit from productive economic activity, but sound tokenomics is not a substitute for product market fit, or a robust developer and user experience. As the Safe team publishes initial drafts of their incentive design, the community should consider how the composition of these design decisions interact, and develop robust methods to test and understand the collective impact of token mechanisms on the broader SAFE economy and its participants.
