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.

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.