CIP: Price enforcement

This post is to discuss the CIP for a price enforcement mechanism as described in


  1. Implement a global, consensus-enforced minimum gas price on all transactions.
  2. Ensure that all transactions can be decoded and have a valid signer with sufficient balance to cover the cost of the gas allocated in the transaction.

Thanks Callum.

The CIP shows a change to ProcessProposal to decode the txs but doesn’t it also need to check the min gas is satisfied so validators can reject blocks if not?

Also the initial value of 0.002utia is buried in the implementation section - since we’re introducing a new parameter in this CIP and its initial value we should probably make that more prominent under the specification section.

Could you also shed a bit more colour on the initial choice of 0.002? Presumably it needs to be low enough to not discourage activity until a more dynamic system is implemented, but at the same time if it’s too low it may not sufficiently discourage off chain markets from forming.

1 Like


There is a section below about modifying DeductFeeDecorator (I think in the implementation we only needed to add/modify the CheckTxFeeWithGlobalMinGasPrices). I don’t mind elaborating further if it’s not as clear.

As to the 0.002 value, this was picked mainly as a placeholder and is just the current min gas price. The CIP was opened while still deliberating on how we want that price to be chosen.

It’s looking likely from conversations I’ve been having that it will just be a governance param similar to how the Cosmos Hub have it.

1 Like

Ah yes I see, ProcessProposal is already running the ante handler. Nice.

I think the comment in process_proposal.go and the error returned from the ante handler is misleading then about when the call to the ante handler would fail: this error only gets hit if the account in question doesn't exist. Presumably this is where it should fail if theres not enough gas too. (note I can’t seem to link to github)

Does the current ante handler then stop validators from voting on blocks with txs below their local min gas?

Ante handler logic can be a little hairy so probably worth clarifying more for changes around it.

1 Like

Before this CIP is finalized, I think there should be a discussion about what the default minfee.MinimumGasPrice should be. In the absence of an EIP1599-style fee adjustment mechanism, given that the data availability market is still very early, IMO the default for this parameter needs to be set at a negligible value that can later be increased as necessary. Similarly, the minimum gas fee in EIP4844 for example is 1 wei, the minimum unit of ETH.

I would suggest setting it at 0.000001 utia, as the mempool priority number is currently set with a scaling factor of 1000000, so that number would be the minimum number above 0 that would make a difference to mempool prioritization in the current mempool implementation.

1 Like

I’ve been thinking about this a little more following the dev call.

This effectively is like having the mechanism switched off and relying on the existing mechanism for a price floor: each validators local minimum gas price. I don’t have a strong opinion either way but I do find this very conservative. There has been one time that we’ve needed to adjust the minimum gas price since the genesis of the chain (we thought it was getting too high) and this is at the beginning when there was a lot more uncertainty. With on-chain governance, the minimum gas price can be changed in 1 week. Do we think it likely that we will be forced to change the price in a moments notice and so would rather rely on encouraging validators to change their local config.

By having the price set by local validators we have problems with incongruity in these prices. We also have the drawback that it is not verifiable. Users / clients have no idea what price is acceptable and since they can’t rely on a verifiable protocol, will need to rely on what the consensus nodes talking to them tell them.

I just wanted to bring this up. At the end of the day, I’m not too bothered if we decide to set the floor to almost zero

IMO it’s just not possible to determine what a non-zero consensus-critical base fee should be yet so I think in the absence of (a) an EIP1559-style fee mechanism or (b) better market data from other DA layers to know what the market prices blobs at, it’s necessary for it to be turned off by default, and allow governance to increase it if necessary. For example EIP4844 has been around for almost a month and the base blob fee is still 1 wei.

Users / clients have no idea what price is acceptable

With a good fee estimation mechanism that looks at what transactions in the last blocks have paid, I think it should be possible for users to know. For example Bitcoin has no base fee, but users still know with a good probability what transaction fee is acceptable.