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).
Smart accounts hold promise for advancing applications building on the Ethereum Virtual Machine (EVM). The Safe Smart Account 13 introduces a modular smart account implementation that empowers an ecosystem of applications optimized for smart accounts.
Below is a proposal for a Fee Engine that could advance the economic sustainability of the smart account ecosystem by establishing novel fee mechanisms. The Fee Engine could be built as a Safe Smart Account Module 6 / ERC-6900 Plugin and leverage an intent-based architecture to simplify and streamline fee collection for developers. Moreover, an Ecosystem Contribution could be dedicated to supporting community-driven initiatives within the smart account ecosystem.
Enabling pathways to economic sustainability for developers is crucial in building a thriving smart account ecosystem, much like the self-sustaining mobile app ecosystem with its fee mechanisms (installation fees, in-app purchases).
Smart Accounts are expected to provide significant user value through easier onboarding, security features like multisig, and gas abstraction / sponsored transactions. Yet, there remain challenges for developers to generating revenue and sustainably unlock this value to users:
To address these challenges, I propose the concept of a Fee Engine optimized for modular smart accounts, facilitating a frictionless method for developers to collect fees and allow incentive mechanisms through Kickbacks. As a result, the Fee Engine helps to ensure economic sustainability for the smart account ecosystem.
However, some essential initiatives that directly or indirectly contribute to the smart account ecosystem might not be self-sustaining. Examples include ‘public goods’ such as open source software libraries, research and educational efforts, and security measures such as bug bounties. To support these initiatives, we could introduce an Ecosystem Contribution, allocating a portion of fees collected by others to nurture the broader ecosystem.
The Safe Smart Account could allow developers to charge fees using the Fee Engine, providing simplified fee collection, as well as optimistic finality and reduced gas overhead. Fees could also be shared with other stakeholders, such as referrers (see Kickbacks below).
Especially for more complex fees (cross-chain, cross-asset), the Fee Engine could leverage an intent-based architecture to streamline fee collection. A Fee Taker generally only requires a guarantee that they will receive a specific fee amount. They are, however, agnostic to how the fee is produced. This is comparable to an e-commerce shop not being opinionated about what currency or credit card is used as long as they receive the specified amount. While these intents inherently align based on the action described, discrepancies may arise in the fee denomination. For example, a service may want to be paid in its native token, while the user does not own the native token but would be able to pay in stablecoins instead.