Fee Monetization
Fee Monetization (FeeM) on Sonic rewards you with up to 90% of the network fees generated by your apps, providing a sustainable income stream. This allows you to focus on scaling your app and growing your user base without the constant pressure of fundraising or securing additional financing.
Inspired by Web2 ad-revenue models popularized by platforms like YouTube, FeeM ensures you directly benefit from the traffic your apps bring to Sonic. By prioritizing developer rewards, Sonic sets itself apart from many blockchains that offer limited incentives and focus primarily on value extraction.
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 soon.
The transaction fee breakdown is 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.
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.
Last updated