Fee Monetization

The Fee Monetization (FeeM) program on Sonic, previously named Gas Monetization, offers developers up to 90% of the fees their apps generate, providing them with a sustainable income, retaining talented creators, and supporting network infrastructure.

With Fee Monetization, we seek to foster a thriving ecosystem for builders, similar to the ad-revenue model on traditional web platforms.

How It Works

Apps have to be approved to participate in Fee Monetization and begin earning a share of the fees their apps generate. We'll provide the application process once Sonic launches.

The transaction fee breakdown will be as follows, which includes an innovative burn mechanism:

Transactions on Non-FeeM Apps

If a user submits a transaction on an app that isn't participating in FeeM, 50% of the transaction fee will be burned, and the remaining amount will be tipped to the Ecosystem Vault and validators.

Transactions on FeeM Apps

If a user submits a transaction on an app that's participating in FeeM, up to 90% of the transaction fee will be given to the app's developer, and the remaining amount will be tipped to validators.

Fee Structure

The table below outlines the difference in transaction fee distribution between an app that does not participate in FeeM and one that does.

Type	Sonic (Non-FeeM TX)	Sonic (FeeM TX)
Burn	50%	0%
Validator Reward	45%	10%
Ecosystem Vault	5%	0%
Fee Monetization	0%	90%

Example: Burn and FeeM

• Scenario: 50% of transactions are from apps participating in FeeM, and the remaining 50% are non-FeeM transactions.

• Average Target Cost: $0.01 per transaction.

• Network Capability: Sonic network can handle up to 900M+ transactions per day.

• Projection: Achieving 10 million transactions per day would result in:

  • ~$0.1 million inflow daily

  • ~$36.5 million inflow yearly

  • ~$9.125 million burned yearly

  • ~$10.095 million paid to validators yearly

  • ~$16.425 million paid to Sonic developers yearly

This projection utilizes a fraction of the network’s capabilities. This is our first step to creating a sustainable L1 model.

Double-Spend Dilemma

In Fee Monetization, double counting is prevented by accurately tracking gas consumption within the virtual machine. The system traces all internal calls in a transaction and splits the reward based on the gas each sub-operation consumes.

This ensures that the sum of rewards across different projects never exceeds the total transaction fee. An example is given below.

• A trade consumes 100,000 units of gas with a total FeeM reward of 0.017 S.

• Inside this transaction, there are operations related to two projects: Project A and Project B.

• Project A, the DEX aggregator, is responsible for consuming 37,000 units of gas, while Project B, the liquidity pool on the DEX with which the aggregator interacts, uses 63,000 units of gas.

• The total reward is split based on the gas consumption:

  • Project A receives 37% of the reward (0.00629 S).

  • Project B receives 63% of the reward (0.01071 S).

• The total reward still adds up to 100% of the 0.017 S FeeM reward, ensuring no over-distribution.