IIP-15: Sharing of Gas-fee with DApps (SGD)

Governance Proposals
1

Abstract

This IIP proposes to share part of the transaction gas-fees with DApp developers to promote a vigorous cycle of token economics.

Motivation

All blockchain platforms thrive through the success of their DApp creators. We should reward high-quality creators on IoTeX in a sustainable way so as to bring more activities to our chain.

Sharing of Gas-fee with DApps, or SGD for short, is an opt-in fee splitting model that revenue-share with the DApp developers a percentage of any transaction gas fee paid to the network when users interact with their dApps on IoTeX.

To attract and retain quality DApps, and discourage lower quality reward seekers, the IoTeX Foundation will implement a review process for DApps applying to the revenue sharing program. The Foundation will approve DApps based on transaction volume, time deployed on chain and make a final determination. More details below.

Flows

  1. To opt into SGD, developers must first deploy their smart contracts

  2. After that, the developers register the DApp contracts on the SGD registry portal by providing the DApp’s contract address and the address to receive the reward. It will be a contract call (with the front-end hosted on https://developers.iotex.io), signed by the contracts’ deployer address.

Flowchart
Flowchart1648×714 85.7 KB

  1. When users started to use the DApp, gas-fee from those DApp activities accrues gradually and automatically in the SGD treasury every time a transaction is made, as shown in the illustration above. As a good starting point, we advocate that 30% of the gas-fee gets re-allocated to the SGD treasury, while the rest remains in PoS rewarding pool as usual. The actual ratio may be subject to later adjustment by governance voting process.

  2. The DApp owner can withdraw this revenue from the SGD treasury by sending a claim action. The SGD treasury will check the SGD registry to verify the eligibility criteria, and issue the reward if criteria are met.

Components

SGD Treasury

Treasury is a module in the IoTeX protocol stack that manages the SGD rewarding balance accounting and claiming. Each time an SGD contract is called, the shared gas-fee will be credited to corresponding owner’s account. When DApp owner comes to claim the reward, it checks the SGD registry to verify the eligibility criteria, and issues the reward if criteria are met.

SGD Registry

The registry consists of 2 parts: a system contract and an indexer.

The system contract is used by DApp owners to register the contract address and reward address (the address they want to receive the reward). After a DApp is deployed, the owner calls this contract to indicate they want to participate in the SGD program, and register the corresponding reward address. The registration will be reviewed and needs to be approved by the IoTeX foundation (see Eligibility Criteria below)

The SGD indexer keeps track of the SGD contract address, its owner (who deployed the contract), and accumulated number of contract calls to the SGD contract. It provides the following functionalities:

  1. When a new contract is deployed, the contract address and its owner will be recorded

  2. It also keeps track of how many times a contract has been called. Whenever a contract call is made to a contract, it increments that number.

  3. Given a contract address, it provides API to query the owner and how many times the contract has been called (something to be considered in the future)

Data provided by SGD indexer will be used to determine whether a contract is eligible to receive SGD reward. See the section below.

Eligibility Criteria

Without standards or a comprehensive review process, revenue sharing of gas-fee could incentivize spam, clunky DApps, and other gas extraction loopholes. The IoTeX Foundation will review the DApp’s registration request, rate its fitness to the program according to the time it has been deployed on the chain, its transaction volumes, and render a final decision as to approve the DApp or not. To kick-start the program, the initial conditions are set as follows. These may be subject to later adjustment by governance voting process.

  • Completed a total of 100,000 or more transactions on IoTeX L1

  • The DApp has been deployed and running normally for 1 month or above on the IoTeX blockchain

  • DApp application reviewed and approved by the IoTeX Foundation

In case the DApp has incurred spam transactions or illegitimate activities (for example, but not limited to, fraud, rug-pull, attempt to attack user’s token/fund, gas extraction, etc.), the IoTeX Foundation reserves the right to immediately dis-approve the involved DApp in the SGD program, and blacklist the involved owner/address in future programs.

Rationale

This feature implementation consists of the following parts:

  1. SGD treasury to manage the gas-fee distribution, accounting, and claim process for SGD gas fee

  2. SGD registry to handle the SGD contract approval, qualification, and share percentage calculation

And it will be enabled in future hard-fork.

More details could be found here: IIP-15: Sharing of Gas-fee with DApps (SGD) by ququzone · Pull Request #21 · iotexproject/iips · GitHub

If you are interested in DePIN you can learn more about the latest developments in the sector and compare projects by visiting DePINscan. DePINscan powered by W3bstream and IoTeX is designed to empower intelligent investors in the DePIN sector.

8 Likes
2

TL;DR
IIP-15 proposes Sharing of Gas-fee with DApps (SGD), which is an opt-in fee splitting model that allows IoTeX dApp developers to receive a percentage of any transaction gas fee paid to the network when users interact with their dApps. To opt into SGD, developers must deploy their smart contracts and register the dApp contracts on the SGD registry.

Revenue from SGD accrues gradually and automatically in the SGD treasury contract every time a transaction is made. This proposal rewards high-quality creators on IoTeX in a sustainable way, using Affiliate Rewards.

Why should we care?
Developers and end-users should care about this proposal because it will encourage the development of high-quality dApps and incentivize developers to create more innovative solutions on the IoTeX platform.

Are other platforms sharing gas revenue with their developers?

Yes, you can see examples on Fantom Network and Canto.

2 Likes
3

I like the idea of incentives for building on iotex.

4 Likes
4

I like this idea this will attract quality builders to iotex ecosystem.

4 Likes
5

Great idea and seems more people have invested in it daily it would benefit from it

3 Likes
6

So the distribution of a percentage of gas fees reduces supply and increases the price, could the developers who receive iotx provide it as rewards for stakers? This should an option provided to developers, not weighted against their project. Completely opt-in/out not a requirement to develop.

7

Goooood)))
I think this will have a positive impact on the development of the network

8

Could you go into more detail? How would the supply of IOTX be reduced? Nothing is being burned or moved off chain. And why would dApps give rewards to stakers? Please expand on your ideas.

9

If iotx is not sitting in the pool anymore it reduces the pool size, because they will be sitting in the wallets of the person who received it. If I buy iotx it reduces supply, price increases, simple economics.

The same reason why people stake with certain delegates because rewards are given on top of apy, nobody is saying they should if you understand what I wrote. An option means it is the choice of the dapp developers, who knows what they may do to encourage interaction on their dapp.

1 Like
10

OK - I got you now. Another aspect might be - the income that dApp developers earn could then be applied to subsidizing gas fees from users. This would be a way for the dApp devs to encourage users to use their dApps. This will be possible when we implement Account Abstraction, the IIP we just approved. Thanks for your thoughts!

1 Like
11

It’s a good idea and similar to ASTAR model, not sure about approval seems it creates centralised control, even if dapp is poorly coded or spammed more fees are spent on network. Ethereum are super proud of high fees ultrasound money powered by Mevbots and $PEPE, if network is lucrative to use are all fees not welcomed, someone is paying the gas on poor dapp or spam irrespective, we don’t really like the idea someone will pick and choose which dapps qualify.

A fixed supply network will eventually run out of rewards(initially supplied by genesis IOTX bootstrapping rewards pool) to pay stakers unless transactions fees are greater then rewards, 30% will reduce the amount going back to rewards pool, consider implications and benefits.

How long without any fees can emissions remain at current level even with 0 fees?

currently there are 8 IOTX x 17,280 = 138,240 block + 450,000 epoch rewards or 588,240 iotx a day paid to stakers/validators (excluding foundation bonus) , to generate this at average of 0.5 iotx txs fee ( based on dapp or transfer, fee is slightly high for illustration) you need at least 1.2 million txs a day, more if fees are less fees pee txs

There is a clear benefit to entice new dapps, or usage in general with fee sharing model but also need to understand runway of current rewards pool

4 Likes
12

Thanks for offering this perspective and noting how ASTAR is similar. For those who aren’t familiar with this model - I wasn’t - here’s where you can learn how ASTAR structures it. It is a bit different than what our proposal is. dApp Staking | Astar.Exchange. It’s worth considering.

13

I’m just gonna share what’s going on in my head - maybe we can let approval part be done by the community through the governance portal? I’m not sure how feasible it is though.

The process could be something like this:

Projects which fulfilled the minimum criteria → apply for the program → team create a new forum thread and/or a new Telegram group where qualified projects can try to sell themselves to get community approval → Voting to send the project to the gov portal will be carried out on this forum → if it reaches certain number → proceed to governance portal → finally, the stakeholders will vote to determine whether yes or no

14

Likewise - thinking out loud. What’s the downside, as Metanyx offers, of having no approval function other than the number of transactions and min. time live on the chain, if the goal is more activity on the chain. Won’t the market ultimately choose what’s worthwhile and what’s nonsense? (Please poke holes in this if I’ve missed something major)

And I like your idea of the community voting but it has the potential to be abused with fake accounts at the forum or Telegram level. This would lead to unnecessary votes on the gov portal. It’s a solvable problem but would require that we move off of Snapshot and possibly implement a system that requires a deposit to make a proposal. Under such a system a minimum deposit would have to be reached for the proposal to move on to the voting stage. That would be done by having supporters contribute toward the minimum deposit required. If that minimum is not reached then the deposit would be forfeit. If reached, it would be refunded to the contributors. This system is meant to discourage proposals that don’t have a minimum level of support. (IIP-999: Declare Marcos Emperor of Web 3, would probably fall short of the minimum deposit amount required, in spite of its obvious merits)

1 Like
15

hehe IIP-999… I understand the concern, but can probably do something else about the deposit. I’m not really a fan of the possibility of losing my funds because of supporting a project.

Once we get a lot of qualified applications, we’ll probably need to improve the process to ensure it’s streamlined, fair and most of the community are informed about it.

At the end, if we go through with the idea, it’s the stakers that will decide whether or not the project deserves the 30% of the gas fees.

Btw, before we move on, just to be clear, my suggestion is more like a 2 pronged mission - to expose the whole iotex community to the project, and to allow the project to market themselves directly via the official channels. More filters will probably need to be introduced to prevent backlash if a project decides to rug after getting all the necessary approvals…

16

I don’t like the centralizing implications of the proposal, since the selection is made dependent on the foundation, which would even have veto power over the applications. For example. it would allow rewarding certain developers over others, or censoring apps for spurious reasons.
But I also don’t like the decentralized version where the community is given equal power. The result could be the same or worse if the community is misled.
The fact is that pre-selection and censorship of apps, present or future, is bad. So we’re fixing a design flaw, the possible flooding of APPS without any value, with another flaw.
So I would only approve of a self-driving version by design. I think we can achieve this by imitating the Near Protocol model on a small scale, taking into account of course the differences in the tokenomics and gas model. Under Near “In transactions where calling a contract would incur a gas fee, the fee is actually divided as follows:
30% goes to the smart contract.
70% is burned.”
The fact that two thirds of the fees allocated to this are burned seems to me extremely useful, since an APP without any value ceases to be: if it succeeds, it is both an iotex “burner” and an attractor of users. If it is not successful it has no effect on the ecosystem.
I don’t see anything wrong with apps that I would classify as garbage, but they attract users to the ecosystem and at the same time contribute to raising the price of iotex (as a result of burning). And it would be sustainable in terms of if many junk apps appear, the price of iotex would increase, scaring them away (and reaching a break-even point).
Applying this model to IOtex tokenomics, the design I think would be:
30% of the fees are reserved for the DAPPS incorporated into the system, and splited:

  • 15% are contributed to the creators.
  • 15% are burned
    (A 50% share developers/burned seems more appropriate in our case)
5 Likes
17

@JoeGoodman @metanyx @anwar139 I passed along your thoughts to the team on an internal call today. You’ve given us good stuff to think about!

2 Likes
18

:clap: well said
Are there any platforms that currently implement this min-support voting strategy you mentioned above?
I like the idea and would like to learn how practical it has been.

19

Yes, you can see examples on Fantom Network and Canto.

20

I agree on @metanyx @anwar139 @JoeGoodman .
Iotex foundation and team must give all the power back to community including Machinefi dao fund which is our money.

And i also suggest burn option initially.

And also if any dapps that’s wants transaction fees and machinefi dao funds they must drip and lock some xrc20 token to the community pool using airdrip which is developed by iotex team.
@raullen @marcosd

2 Likes