Problem: need to revise or add eth_maxPriorityFeePerGas rpc call

[adu-web3]

Proposal: [Description of the feature]
need to revise or add rpc call eth_maxPriorityFeePerGas
Current behavior: [What currently happens]

Desired behavior: [What you would like to happen]

Use case: [Why is this important (helps with prioritizing requests)]

Requests may be closed if we're not actively planning to work on them.

[adu-web3]

working on this

[adu-web3]

evmbackend will fetch the latest suggested gas tip capacity from feemarket QueryClient, which requires adding messages in query.proto and regenerating the corresponding codes, and implementing the grpc methods of GetGasTipCap for feemarket keeper.
@yihuang suggests that tendermint will not order the txs in mempool, while this rpc is mainly involved with the priority of tx orders. So will return to this rpc call after finishing other rpc calls.

[yihuang]

Maybe return some constant configurable values, to make the web3 client happy? Is any client depends on this API to work?

[adu-web3]

No, MaxPriorityFeePerGas is only used as public api for suggesting gas tip cap.
But SuggestTipCap is used by MaxPriorityFeePerGas, SetTxDefaults and GasPrice public api
Currently, SuggestTipCap returns the minimum gas price of chain defaults, which should be a constant @yihuang

[fedekunze]

are then any actionable items here?

[adu-web3]

are then any actionable items here?

Will come back after finishing other rpc endpoints

[adu-web3]

since currently tendermint will not consider the priority of txs based on gas price tip cap, should we return the minimum gas price of chain defaults or return the suggested gas tip cap by sampling from history gas price tip cap?
Which one do you think is more appropriate? @fedekunze

[adu-web3]

cosmos-sdk is now working on tendermint mempool prioritization (cosmos/cosmos-sdk#9962), and it would be more appropriate to consider the dynamic maxPriorityFeePerGas at that time.
I will close the issue and let the JSON-RPC endpoint act in the current way.