Smart Account Fee Engine (S.A.F.E.)

[lukas]

Disclaimer

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.

SUMMARY

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.

MOTIVATION

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.

FEE ENGINE

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).

Fee Intents

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 (FT).
• Fee Payer Intent: The Fee Payer (user), given action (A) desires to pay through their preferred fee (FP).

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.

Fee Types

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.

Fee Type	Description	Example
Flat	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.
Transaction-based	Fees incurred based on transaction volume.	A transaction insurance provider charging 0.01% of the value of each covered transaction.
AUM-based	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.
Subscription	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.

Agent-assisted Fee Settlement

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.

Kickbacks

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.

ECOSYSTEM CONTRIBUTION

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.

Ecosystem Contribution Rate

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.

Distribution

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.

REQUEST FOR FEEDBACK

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.

[Billion]

Thank you @lukas for your involvement and this well designed mechanism, the proposal for the Fee Engine and Ecosystem Contribution in the context of the Safe Smart Account ecosystem seems well-thought-out and comprehensive. It addresses important challenges faced by developers in the smart account space and introduces mechanisms to enhance economic sustainability. Here are some feedback points and considerations:

1. Intent-Based Architecture:

• The concept of using an intent-based architecture for fee collection, especially for complex fees, is innovative and can simplify the process for both Fee Takers and Fee Payers.
• Consider providing examples or case studies to illustrate how this intent-based architecture would work in practical scenarios, addressing potential challenges and solutions.

2. Fee Types and Trustless Mechanism:

• The inclusion of various fee types (Flat, Transaction-based, AUM-based, Subscription) is a good approach to cater to different business models. Providing clear examples for each fee type helps in understanding the practical implementation.
• Ensure that the Fee Engine provides a trustless mechanism for calculating and collecting fees, especially for advanced Fee Types like AUM-based fees.

3. Agent-Assisted Fee Settlement:

• The role of Agents in settling Fee Intents and addressing challenges such as latency is crucial. Ensure that the mechanism for issuing Fee Credits and the associated collateral requirements are well-defined and secure.
• Consider providing details on how Agents are selected, their responsibilities, and how they compete for the right to settle a fee.

4. Kickbacks:

• Kickbacks as an incentive mechanism for developers and third parties are a valuable addition. Clarify the technical details of how Kickbacks work, including how transaction metadata is leveraged and how the system prevents abuse.

5. Ecosystem Contribution:

• The Ecosystem Contribution is a positive initiative to support broader ecosystem initiatives. Clearly define the governance process around the Ecosystem Contribution, including how SafeDAO will oversee and allocate funds.
• Consider providing examples of the types of initiatives that could be funded through the Ecosystem Contribution to give the community a better understanding of its potential impact.

6. Ecosystem Contribution Rate and Governance:

• The introduction of the Ecosystem Contribution Rate is a good step. Clearly communicate the initial ECR, how it can be adjusted, and the governance process involved.
• Ensure that the governance process is transparent, and the community has a say in determining the ECR.

7. Feedback and Community Involvement:

• Encourage community involvement and feedback on the proposal. Consider setting up forums or channels for discussions, and be open to iterating on the proposal based on the community’s input.

8. Documentation and Educational Resources:

• Develop comprehensive documentation and educational resources to help developers and stakeholders understand the Fee Engine, Agent-Assisted Fee Settlement, Kickbacks, and the Ecosystem Contribution.

9. Security Considerations:

• Emphasize the security measures in place, especially when dealing with staking collateral, smart contract risks, and potential vulnerabilities. Consider undergoing audits to ensure the robustness of the proposed system.

10. Scalability:

• Consider the scalability of the proposed system, especially if the smart account ecosystem experiences significant growth. Ensure that the Fee Engine and associated mechanisms can handle increased transaction volumes and demand.

Additional Considerations

• It will be important to carefully consider the initial value of the Ecosystem Contribution Rate (ECR). The ECR should be set high enough to provide meaningful support to the ecosystem, but not so high that it discourages developers from using the Fee Engine.
• The governance process for the Ecosystem Contribution should be transparent and accountable. SafeDAO should ensure that the community has a meaningful say in how the funds are allocated.
• The Fee Engine and Ecosystem Contribution mechanisms should be regularly reviewed and updated to ensure that they are still effective in meeting the needs of the ecosystem.

In conclusion, the proposal introduces innovative concepts for fee collection and ecosystem contributions. Addressing the points mentioned above will help in further refining the proposal and ensuring a robust and secure implementation.

[bernard]

Thanks for sharing @lukas - very exciting initiative and great to see the ball is rolling on that front!

The Fee Engine addresses complexities and inefficiencies in fee collection with the potential to reduce friction for a wide range of transactions (off-ramping, bridging, etc.). In that regard it enhances economic sustainability for the key participants:

• Developers benefit from a customizable and sustainable fee flow
• Users enjoy additional features and reduced complexity
• Agents gain a new market opportunity

It also aligns well with the Safe DAO Constitution in

• (1) fostering a robust ecosystem - enabling sustainable incentives for contribution
• (2) resilience through decentralization - further enabling self-sustainability

---

Below are initial reactions from my end:

Idea

1. ECR funneling to OBRA (and setting basis ECR rate):
I like the concept of funneling the ECR to fund OBRA in a self-sustainable manner. Even if not framed out specifically, I assume this is the idea behind it. This could also educate the first rate that we determine for ECR through governance, i.e., OBRA funding needs setting a baseline for minimum ECR rate. Obv. the value itself needs to be educated by the first OBRA cycles.

Questions

1. Failed Settlement: “In case fees are not being settled as expected, the Agents’ staked collateral is used at the redemption of the Fee Credits.”
—> What will be the process for using the Agents’ staked collateral in case fees are not settled as expected? Who oversees this?

2. Agents’ Role:
—> Are agents essential in the process, or can fee settlements occur directly between the fee taker and the payer - with the fee taker taking on the risk & upside?

Looking forward to hearing more opinions on the idea & questions.

[lukas]

@bernard

1. ECR funneling to OBRA (and setting basis ECR rate):
I like the concept of funneling the ECR to fund OBRA in a self-sustainable manner. Even if not framed out specifically, I assume this is the idea behind it. This could also educate the first rate that we determine for ECR through governance, i.e., OBRA funding needs setting a baseline for minimum ECR rate. Obv. the value itself needs to be educated by the first OBRA cycles.

Yeah good point on making the link to OBRA more explicit!

@bernard

1. Failed Settlement: “In case fees are not being settled as expected, the Agents’ staked collateral is used at the redemption of the Fee Credits.”
—> What will be the process for using the Agents’ staked collateral in case fees are not settled as expected? Who oversees this?

If the staked asset is different than the asset the fee taker aims to receive, it would probably require some sort of liquidation process. E.g. whoever settles the fee is able to claim a portion of the stake. And the amount could be determined by a some auction mechanism. Starting from 0% and going towards 100% of the stake until the fee is settled. But didn’t think too much about this part yet and would require more research.

@bernard

2. Agents’ Role:
—> Are agents essential in the process, or can fee settlements occur directly between the fee taker and the payer - with the fee taker taking on the risk & upside?

In general I think the Agents-part is something that probably is only introduced quite late in an implementation of the Fee Engine. As there should be plenty of fee mechanisms that do not require Agents. e.g. if there is no cross-chain / cross-asset conversion involved. E.g. flat fees or subscriptions in the same currency. Haven’t considered if the Fee Taker could also take the risk themselves for lower-risk settlements (e.g. stablecoin conversions). But worth exploring, as I could see some fee takers not wanting the additional cost / complexity involved with Agents and rather just take some risk themselves.

[lukas]

I sense that there was some AI generation behind this, so as I want to prevent spending time on having a back-and-forth with ChatGPT I won’t be responding in detail, but appreciate the post nevertheless!

I’m sorry if this is actually not the case and the post was handwritten. It’s a strange new world where it’s becoming difficult to judge these things. I’m just trying to be resourceful.

[corbinpage]

I like the idea of having fees on transactions that are customizable by amount and the split of the fee recipients. That will lead to all types of new experiments and then new business models. And the Fee Engine design seems well thought out and a nice balance of robustness and simplicity.

My concern is that this design seems mainly for developers that set up Safes on behalf of their users (embedded wallets) and mostly excludes users creating a Safe for themselves? What incentive would a Safe user have to go through the Fee Engine instead of transacting directly…except in an embedded wallet scenario? If I’m understanding that correctly, that limits the total market of Safes for this value capture mechanism and pushes the onus on developers to design and implement a fee system. Maybe that’s ok though given a lot of recent growth would be covered (https://dune.com/safe/all).

One suggestion is to add a Fee Type to the Fee Engine that’s based on gas used, similar to how Paymasters are monetizing in the 4337 ecosystem (7-10% fee on gas). Gas fees are dropping so fast on L2s and L3s that users start to think of them as negligible. So they don’t perceive much pain from a 10% increase on gas that then gets distributed to app developers and the Safe Ecosystem.

[lukas]

@corbinpage

What incentive would a Safe user have to go through the Fee Engine instead of transacting directly…except in an embedded wallet scenario?

The Fee Engine could just be enabled with the same transaction of the first fee that is being taken from a user. So even existing Safe users wanting to enable a subscription or unlock a paid feature could then be onboarded to the Fee Engine by the party wanting to take the fee. So the hypothesis is that the Fee Engine is adding enough value to the Fee Taker that they ask the Fee Payer to use the Fee Engine rather than settle the fee directly p2p and the Fee Taker generally being able to choose which mechanism is used to settle their fees.

[adamhurwitz.eth]

The table above of fee types and examples is great to understand real world use cases!

Ecosystem contribution rate (ECR) vs Token burn

One question that may arise is “Why use the ecosystem contribution rate (ECR) rather than taking a token burn strategy, similar to what is proposed with maximum extractable value (MEV) on Ethereum?”

• Some differences are that Safe ecosystem has a DAO governance, whereas there is no formal “Ethereum DAO”.
• Therefore, the decision making process for Ethereum’s MEV rewards is potentially more complicated due to the lack of existing governance structure.
• Safe’s SAFE token has a fixed supply whereas Ethereum’s ETH has an issuance rate creating new ETH. Burning MEV rewards on Ethereum helps to balance the supply/demand of ETH whereas the total supply of SAFE is fixed.

Tech architecture

For those less technical (myself included), it’d be good to understand from a high-level how this could be built.

• ERC-6900
  • ERC-6900: Modular Smart Contract Accounts and Plugins
  • Compatibility between smart contract accounts and optional upgradability
  • This allows for code dependencies to be created that define the various fee structures above
  • Based on ERC-4337 and ERC-2535
  • ERC-4337
    • ERC-4337: Account Abstraction Using Alt Mempool
    • Separates the logic for validating and executing smart contract transactions from core protocol consensus layer
  • ERC-2535
    • ERC-2535: Diamonds, Multi-Facet Proxy
    • Upgradeable smart contracts using external code imports (facets)
    • Facets share internal functions, libraries, and state variables

[LuukDAO]

I took some time to review the S.A.F.E draft thoroughly - and honestly, you nailed nearly all points, @lukas

In general, my reflections are comparable to @Billion’s reflections.

Some specific I would like to add:

1. Ecosystem Contributions and Retro PGF

• I love this separation, and I think this is the right approach to thinking about ecosystem development in relation to revenue. I believe it’s essential we start identifying and acknowledging these types of Safe Public Goods early. I propose using some of the WildCard budget of S1/S2 on RSPGF (Retro-Safe PGF).

2. Fee Structure and Fee Abstraction

• Agreed that the Fee Engine should be trustless and extremely clear to builders.
• I think we must abstract the fees away from the end-user as much as possible and should invest in constant R&D to identify and implement these processes.

[Billion]

Thank you for this rfp @lukas

I think we should push this to snapshot

Regards,

[Ibrahim313]

Is there any updates on getting this going ?