Fee Monetization

Apply to Fee Monetization.

Fee Monetization (FeeM) on Sonic lets builders earn 90% of the network fees their apps generate — creating a sustainable revenue stream without relying on fundraising. Inspired by Web2 models like YouTube, FeeM rewards developers for the traffic they drive.

FeeM also challenges the extractive "app chain" model by allowing builders to earn 90% of their app's network fees without the need to launch a separate chain. This approach removes the high costs, infrastructure overhead, and interoperability challenges typically associated with app chains.

By integrating monetization directly into the network layer, FeeM simplifies revenue capture and supports scalable, efficient app development within a unified, developer-friendly ecosystem.

Transaction Breakdown

The transaction fee breakdown is as follows, which includes an innovative burn mechanism.

Transactions on FeeM Apps

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

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.

The table below compares transaction fee distribution for apps with and without FeeM participation.

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

Example

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

Flow of Fees

1

Transaction Submitted

A user initiates a transaction on an app and pays a gas fee in S tokens.

2

Validator Allocation

Sonic automatically allocates 10% of this fee to the network validators.

3

FeeM Allocation

The remaining 90% is sent to the specialized Fee Monetization (FeeM) contract (sometimes referred to as the fee treasury).

4

Off-Chain Oracle Tracking

Multiple off-chain servers (oracles) monitor every transaction on-chain, tracing gas consumption for each registered contract (including sub-calls).

5

Rewards Distribution

When an app claims rewards, the FeeM oracles confirm the gas usage on-chain. Once a quorum of oracles confirms, the FeeM contract releases the app’s accumulated rewards.

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.

The chart below illustrates how the FeeM oracle infrastructure traces each sub-operation and distributes the transaction fee spent on the calls based on gas consumed.

Frequently Asked Questions

My app uses an upgradeable (proxy) contract. Should I register the implementation too?

Typically, you only need to register the proxy. Gas consumed by the implementation via delegate-call will be attributed to the proxy address.

What if my app deploys many user-specific contracts?

If those user contracts act as proxies calling a small set of implementations, you only need to register the main implementation proxies. You’ll receive rewards for all the gas consumed within them.

How do I claim my rewards?

You initiate a claim transaction on the FeeM contract. The oracles confirm your gas usage, and after enough confirmations, your share is transferred to your rewards recipient. You may want to check the Fee Monetization dashboard for a user-friendly claim UX.

What if I don’t claim my rewards immediately?

There is no deadline. Unclaimed rewards stay in the FeeM contract until the rightful project claims them.

Why do my rewards stay the same over a longer time period?

FeeM processes rewards similarly to the staking rewards via the SFC contract. The accumulated rewards are updated after the active epoch is sealed and confirmed.

Questions? Join Sonic Builders on Telegram.