Some gas % for contract developers

At present, all the gas fee paid goes to baker/endorser. Is it possible to have some percentage of gas fee going to contract developer? So for some contracts- like token contracts, this percentage could be 0, while for some projects like Dex, this could be set to 20-30% of the gas fee paid.

This would avoid developers issuing new tokens like during the 2017 ico craze for the projects they develop while also incentivising developers to develop contracts that will be used rather than dealing with token engineering.


It is rather easy in Michelson (and I expect even easier in high-level languages) to reject transactions whose amount is too low and the limit can be dynamic so for example it can depend on the size of the parameter. What cannot be done currently is access from a smart-contract code to either the consumed gas or the paid fees. If there is a strong use case for accessing the fees of the transaction this could be done easily I think; the consumed gas used to be accessible (through the STEPS_TO_QUOTA instruction) but it has never been used on chain and made a lot of things more complex.

1 Like

Rewarding smart-contract developers in proportion to how much their contract is used is a really good thing but naively tying it to transaction fees does not work for a variety of reasons.

The first thing to understand is that there are no “gas” fees. Transactions do carry a field called “fee” which lets them include a payment in tez to the baker who will include the transaction. When bakers create blocks, they are limited in the number of operations they can include, in the gas those operations can consume, and in the size they can occupy (in bytes), but the bakers are otherwise free to choose the transaction they wish to include. A reasonable, default behavior is for the baker to simply include the transactions that carry the highest fees and use up the least amount of space and gas in the block, but they are not required to do that. In fact, there may be several reasons why a baker may not selecting transactions on that basis. It could be that the baker is being paid off-chain, on-chain, or in some other manner for including these transactions, it could be that the baker only wants to include transactions from certain parties. It can be particularly useful for users who need to make a large number of transactions every day to enter into a long term service agreement with bakers.

All this is to say that attaching tez to the fee field is not something that is programmatically tied to gas consumption but just one way, among others, to pay bakers for the inclusion of transactions.

There are approaches, such as Ethereum’s EIP-1559 that attempt to codify how gas is paid. This approach maintains an optional “tip” field as a way of incentivizing block producers to include transactions, but it also requires a fee, proportional to the gas consumed to be burned. To calibrate the amount of burn required, the block gas limit is rendered elastic, and the burn amount is set by targeting an average block size.

This has the benefit of codifying the bulk of fees being paid and being prescriptive about the way they are paid. There are economic benefits for proof-of-work systems, but these are already captured in a proof-of-stake system. There are important drawbacks to this approach and explaining them in detail would go beyond the scope of this answer but, to take just one important example, this would break the model of bakers selling long-term service agreements.

Assuming an EIP-1559-like system, the fee paid becomes a meaningful number. It cannot be artificially low (due to an off-chain payment) or costlessly high (due to a baker injecting a transaction with large fees in their own blocks). You could decide to take a percentage of the burned fee and give that to the contract but that doesn’t really make sense? Why not just require a payment? Why tie it to gas fees? What if you’d rather refund the user for that amount… it gets messy and it’s not particularly useful.

What does make more sense is a burn discount for contracts on which a lot of fees have been burned. You could count how much fee has been burned since the inception of a contract and apply a multiplier on the burn they require. Obviously this would need to be bounded, but you could imagine that a contract for which 1,000 tez have been burned pays 95% of the fee, one for which 10,000 have been burned pays 90%, of for which 100,000 have been burned pays 85%, etc all the way down to 50%.

The benefit of this approach is that contracts that are initially popular can build a sustainable advantage over copy-cats. (To be sure, I take no credit for this idea at all, it’s one of the thing discussed around EIP-1559 in Ethereum land).

In conclusion:

  • Careful, the fee field is more subtle than it looks
  • If the point is merely to pay contracts per call, there’s nothing stopping contracts to charge and there’s no particular reason for them to make that cost propertional to the gas used.
  • The fee field can look more than what people expect it to be using the approach described in EIP-1559.
  • Even when fees are burned, it’s still not a good idea to try and funnel a portion of that to the contract
  • What might make sense in this scenario to create a fee discount for popular contracts to let creators enjoy a competitive advantage over clones

Hey @murbard

Thanks a lot for your very well thought out response on this. I will read up your response again and think through this to see what may be the most practical.

Thanks for your time on this and for the response.

it could be that the baker only wants to include transactions from certain parties
I’ve been thinking about this. Suppose I’m a baker, and I really like actor Alice, and want to encourage her to send transactions on the network. I decide to, whenever possible, include Alice’s transactions for free in my blocks. Will this in any way affect the odds that I will be selected to bake blocks?

I would think the answer is no, since the chances are based on my share of the rolls, and as long I continue to bake blocks in a timely manner.

(Probably unrelated to the above question) Is there a way to utilize the ability for bakers to arbitrarily discriminate transactions for the creation of a Layer 2?