The below is purely a concept. There is no guarantee that any of the below will ever be built. Before any implementation, further analysis (incl. legal/regulatory risks, technical feasibility etc.) would be required. An implementation would also likely be iterative and not start with the full scope outlined below. I welcome everyone interested in this topic to contribute thoughts & ideas.
Smart accounts hold promise for advancing applications building on the Ethereum Virtual Machine (EVM). The Safe Smart Account 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 / 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:
- Complexity: Developers lack tooling for effective fee collection, such as subscription fees, AUM-based fees. User-friendly fee collection may introduce additional complexity through requiring asset conversion or bridging.
- Latency: Asset conversions, bridging, or on-ramping can delay fee collections and require developers to assume additional risk.
- Gas overhead: Transaction fees can make charging fees for subscriptions or micro-fees uneconomical.
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.
A Fee Intent is therefore a combination of an action ‘A’ and a corresponding fee ‘F’ with two distinct perspectives:
- Fee Taker Intent: A Fee Taker (Developer) provides a specific action
(A)for the fee
- Fee Payer Intent: The Fee Payer (user), given action
(A)desires to pay through their preferred fee
While the action
(A) remains a constant in defining the nature of the transaction, the corresponding fee might vary in terms of its type, unit, or even the blockchain it originates from. While a Fee Taker might request
FT [10 USDC on the Ethereum Mainnet], a Fee Payer might have assets on Mainnet and instead of manually bridging/swapping assets, prefer to pay
FP [11 DAI on Optimism] to cover the fee.
While the previous section provided a straightforward example of a flat fee, the Fee Engine allows for various Fee Types to abstract away common patterns as demonstrated by the examples shown in Table 1. Especially for advanced Fee Types, like subscriptions or AUM-based fees, the Fee Engine can provide a trustless mechanism to calculate and collect fees.
|Fees charged for one-time access or pay-per-use for a particular action or service.
|A recovery solution requires a 50 DAI flat fee per recovery triggered.
|Fees incurred based on transaction volume.
|A transaction insurance provider charging 0.01% of the value of each covered transaction.
|Fees derived from the percentage of total assets managed or covered by a solution. Leveraging an AUM-oracle to determine the amount of assets stored.
|An asset management solution charging 0.25% annually on the total value of assets deposited.
|Periodic fees for ongoing services or access. Potentially also “streamed subscriptions” leveraging Superfluid or similar solutions.
|An automation service executing DAO decisions onchain and charging a 100 USDC monthly subscription fee.
Agents settle the Fee Intents and navigate an ever-evolving landscape of DEXs, bridges, on-ramp providers, and other fee settlement paths. Their participation in the network is incentivized through access to order flow, the ability to charge a spread, and other economic motivations. They compete for the right to settle a fee via a request for quote (RFQ) mechanism.
Agents also play a pivotal role in countering (potentially significant) delays associated with fee settlement processes, such as non-atomic asset swaps, cross-chain asset bridging, or on-ramping. For instance, transferring a fee from roll-up A to roll-up B might span days before reaching finality. To tackle this, Agents issue Fee Credits to the Fee Taker. These Fee Credits serve as a guarantee that fees will eventually be settled. This assurance allows the Fee Taker to continue their operations, like executing a specific onchain action or providing an offchain service. Besides addressing latency, Fee Credits also significantly reduce the gas overhead associated with fee collection through payment channels.
To ensure Fee Credits have sufficient backing, Agents must provide a stake as collateral to the Fee Engine. The amount of Fee Credits an Agent can issue is proportional to the stake they allocate. The staking requirements means Agents cannot be undercollateralized, safeguarding against scenarios where fees may not be settled or take longer than expected. In case of fees not being settled as expected, the Agents’ staked collateral is used at redemption of the Fee Credits. As a result, Agents assume various counterparty risks as part of the fee settlement:
- Conversion risk: The potential loss due to fluctuating exchange rates.
- Liquidity risk: The potential for a lack of liquidity to negatively impact settlement paths.
- Smart contract risk: The potential for vulnerabilities in smart contracts such as bridges.
Agents may require a grace period between issuing Fee Credits and their redemption. This buffer ensures Agents have adequate time to settle fees, ensuring their staked amount remains unaffected.
With viable revenue streams, developers in the smart account ecosystem can set a percentage of their fees as a commission. Kickbacks are a general-purpose incentive mechanism enabling Fee Takers to provide an incentive for third parties, such as user interfaces. Kickbacks leverage transaction metadata to determine transaction facilitators, such as a wallet. They provide a streamlined way for developers to create usage- or action-based incentives such as revenue share or referral fees. As a result, (wallet) interfaces can leverage additional revenue streams by onboarding users to solutions that leverage Kickbacks.
The Ecosystem Contribution could augment this concept with a portion of the fees (Contribution Rate) collected via the Fee Engine being allocated for ecosystem-specific initiatives. SafeDAO could act as a governance mechanism for the Contribution Rate. The Ecosystem Contribution would be community-governed and redistributed to support the development and growth of the smart account ecosystem, using grants, public goods funding, and other initiatives.
The Ecosystem Contribution Rate (ECR) is a percentage of the fees used for the sustainable growth of the smart account ecosystem. The ECR could initially be set to zero and can be enabled by SafeDAO via a Safe Ecosystem Proposal (SEP). The ECR could be reviewed at periodic intervals with changes only taking effect following a significant delay for the Fee Taker to opt out, if the ECR is perceived to be too high.
The Ecosystem Contribution can be deployed to fund ecosystem initiatives, public goods, grants, bounties, and other forms of ecosystem initiatives. SafeDAO has existing frameworks that prevent the misuse of the Ecosystem Contribution. The SafeDAO Constitution requires any resource allocation to be attributed to SafeDAO’s mission and pre-defined goals. The Resource Allocation Framework (yet to be ratified) and the Governance Framework structure and scale the redistribution through community governance.
This post serves as a starting point to further discuss opportunities and challenges around economic sustainability of the Safe Ecosystem and the smart account ecosystem at large. I welcome any contributions / criticism / counter-proposals / ideas / experiences.