Proposal for Implementing an on-chain Minimum Gas Fee of 0.1 uscrt

Hello everyone,

I am writing to propose a significant change to our network parameters that I believe will help to maintain the sustainability and robustness of our network. I propose that we implement a minimum gas fee of 0.5 uscrt/gas as a (changeable) on-chain parameter, that enforces every validator and node to adhere to a min-gas fee of 0.5 uscrt. As of right now, there is no on-chain parameter on Secret Network to control the min-gas fee. Only the validators and nodes directly control this value via a setting in their configs.

This Prop therefore proposes two things at once:

  • Kindly ask/signal to SCRT Labs to implement an on-chain parameter to enforce a min-gas fee across the whole network.
  • Set the min-gas fee to 0.5 uscrt, which we will soft enforce (see below) until the on-chain parameter is implemented

The rationale behind this proposal is to ensure that the network remains economically viable and secure. As we all know, gas fees play a crucial role in deterring spam transactions and maintaining the overall health of the network. By setting a on chain minimum gas fee, we can ensure that the network continues to operate smoothly and efficiently, even during periods of high demand.

I’ll be citing @pmuecke for more of the background to this proposal and why 0.5 uscrt makes sense as an initial parameter to this on-chain prop:

It has been a while since we last updated our gas fees and a lot has changed since then. Back in December of 2021 we reduced the default gas fee from 0.25 to 0.0125 uSCRT, a 20x decrease when SCRT was valued between 4 and 6 USD.

Although 0.25 uSCRT was the default a good number of validators were running 0.1 uSCRT and as such that was the ‘low’ fee and currently still is the ‘medium’ fee. One of the main reasons to decrease the fees at that time was the fact that IBC relayers were spending roughly 2500 USD a day on transaction fees.

It is difficult to find reliable data from back then but IBC transactions cost roughly 0.2 SCRT and a swap on SecretSwap 1 SCRT, so roughly 1 USD and 5 USD respectively.

Currently an IBC transfer costs roughly 0.02 SCRT and a swap on ShadeSwap 0.25 SCRT, so roughly 0,8 cents and 10 cents respectively.

Interestingly looking at the thousand most recent transactions involving the bank module we see the following gas fees being used:

0.0125 uSCRT: 20%

0.1 uSCRT: 36%

0.25 uSCRT: 23%

0.33 uSCRT: 16%

1 uSCRT: 2%

In short, in this very limited snapshot a little less than half of the transactions use a gas fee higher than the ‘medium’ Keplr value. Almost 20% use a value (significantly) higher than the ‘high’ Keplr value.

Currently it is not possible to make IBC transfers cheaper than other transactions so we have to keep relayers in mind. Alternative solutions to the costs of relayers have been raised during the last governance call, for example using fee grants to pay the relaying txs.

In the past months there have been several occasions where a large amount of ‘spam’ transactions were submitted, in some of these cases a number of validators have increased their minimum gas fee in order to slow these transactions down from being included in blocks. These increases did improve the amount of missed blocks.

In the interim, if this proposal passes, we can enforce the min-gas fee via the Community API cluster, secret.express, to enforce minimum gas fee even before the on chain parameter passes. This will allow us to begin implementing this change even before SCRT Labs has officially implemented it.

Furthermore, If this proposal passes, we will be getting in contact with the teams behind our major wallets - Keplr, Leap, Starshell, and Fina. This will ensure that all transactions, regardless of the wallet used, will adhere to this new minimum gas fee.

I am eager to hear your thoughts and feedback on this proposal.

Best,
Secret Saturn

//EDIT: Some major changes were made, see the latest post below.

3 Likes

I am generally opposed to raising gas fees. While it may somewhat deter spammers, it will make the network less competitive. If there are scaling issues, we should address them at the network level, infrastructure, etc. Before making a decision though, I think it would be helpful if we’re able to gather and share specifics about the ‘spam’ tx incidents, i.e., how many validators missed how many blocks? Was it caused by large txs using tons of gas, or a high number of txs?

If it is a limitation of the wasm engine + the “less performant” SGX hardware among current validator set, I think that should be brought into this discussion so we can evaluate alternative/potential solutions.

While 10 cents may not seem like a lot to some of us, it is a substantial fee in certain places around the globe. A fair amount of spam is actually a good indicator of a healthy network. Zero spam would be a bad sign that the network is ded/dying. Also, if fees are higher, wouldn’t that put extra cost on arbitration and all of secret defi suffer?

1 Like

Nine validators (12.5% of Voting Power) and ten community members responded to a mini-survey on the topic of gas fees, below are the results:

A majority of validator respondents preferred to burn fees instead of distributing them as part of staking rewards. For community respondents, the result was less clear and contained a large group of neutral voters. The inverse was seen with regard to regular updates to gas fees to keep them in line with their USD values, here the community was clearly in favor of regular updates whereas validators were slightly in favor of it but mostly neutral.

Both validators and community members preferred higher gas fees when burned compared to distributed to stakers. Median values were 0.25 and 0.1 uSCRT respectively for the community respondents and 0.25 uSCRT for both situations for validator respondents. Overall the community tended to prefer lower gas fees than validators, including several votes for no gas fees at all. Similarly to the validator respondents, the maximum preferred gas fee was 0.5 uSCRT.

Very few respondents were against paying IBC relayers through a fee grant from the community pool although validators tended to be more neutral on the topic. Overall, implementing the IBC fee middleware in frontends may make a bigger impact and would remove the need for such a community-funded fee grant for relayers.

Other feedback was very varied and ranged from ‘low or no fees are best for user adoption, fees should only be used to prevent harmful levels of spam’ to ‘the higher the better’. Others highlighted the need to set a USD value corresponding to a certain action (for example a swap) and periodically tuning the gas fees in order to stay close to that value. There is also some interest in the community for a fee market implementations where certain tx’s can be prioritized.

To gain further data and more insight into the community’s thoughts a telegram poll will be created shortly.

3 Likes

Was reminded of this discussion so will drop my thoughts here.

General view: fees exist for security reason but are ultimately a bigger impact on UX, these 2 topics should be weighed off in any fee discussion imo.

Specific:

  1. 0.0125uscrt as a fee option has ridiculous scaling to the other options often used by validators (0.1 and 0.5) so to me the largest thing we can do to improve UX is actually make a logical scaling of the fees, if that means adopting all new standards than i am fine with that. Normal scaling could look like ( base - 2x base - 5x base) while current is (base - 8x base - 20x base).
  2. On secret we should set fees based on compute and not sdk transactions imo due to the scaling differences to other chains. Imo a (non aggregated) swap on low fee should not be more than 10 cents (tailoring to users who would like to pay less for slower confirmation). Assuming it costs 150k gas that means as long as we stay under 1.50 dollar scrt 0.1uscrt could serve the low fee option for a very long time.
  3. Fee sponsoring like faucets and relayers: In cosmos the standard has become (and secret has adhered to this for now) that IBC transfers are free. This standard is grounded in close to everything yet is not completely set for other port option in IBC like Wasm, queries and ICA.

So something like muecke states here i dont see actually happen. I think moving away from this standard is not in the current realm of possibilities meaning relayers will sponsor gas for a long time to come on ~100.000 IBC txs a month (as of rn). Quick calc shows IBC costs roughly 100.000 x 0.0125 * ~100.000 (gas) /1e6 = 125 scrt monthly which would go to 1000 scrt using 0.1uscrt as a base. Which excludes the costs made on other chains to also acknowledge the packet. At current prices this is not too much in USD but its important to monitor that as time goes on. The costs in scrt were the same at 6-10$ per scrt but then its suddenly 10k a month USD.

Using a feegrant for relayers imo is a fine way to circumvent this. Alternatively one could set the fee for IBC specific messages in the SDK to lower values as chains like Juno and Carbon have done. This allows to scale other fees without having to worry about running relayers out of money but ofc introduces security risks in people spamming ibc client updates to DOS the chain.

Happy to make a proposal for the feegrant option or help alex set it up if community likes that option.

  1. Having a minimum-min gas fee parameter would be great. Many chains have this integrated and is a good way to set an acceptable floor and allow dapps to integrate that easily. Currently no such floor exists on secret meaning validators could set fees to 0 if wanted.

TLDR:

Increasing gas fees should be done (probably a long time ago) even if only to fix the stupid scaling it has atm. Imo 0.5uscrt is not suited as the min fee but i would be fine supporting that as the high fee moving to 0.1-0.25-0.5. if we move to 0.1 as a min fee id like to see a solution for relayers that looks into the longer term as well. Feegrants or free service doesnt only reduce strain it also allows relayers to go full blast with their config optimisation as they dont have to worry about spending on fees. I have a lot of anecdotal evidence that supports removing fee stress from relayers significantly improves performance on those chains channels.

Happy to see this discussion continuing.

Wanted to add that in discussing fees we should all remember that fees are not a governable number, but they could be if we made some changes. This is notably different from when this discussion happens on osmosis, where proposals can change the fees instead of node runners getting to decide themselves.

Other context.

0.5 uscrt = roughly $0.0175
0.25 uscrt = roughly $0.00875

We are talking about pretty acceptable amounts that are all much higher than the current fee of $0.0004375

I think people discussing fees are not keeping perspective in how low these amounts are but how useful it is to increase them. None of these numbers are “outrageous” in any way other than how affordable they are.

just showing the fee per unit of gas is not reflective of the actual fee to do a swap or lend transaction etc.

And re validators being able to choose their own fees.

Yeah it is an option and fine to do in a permissionless network but people should know that it leads to them basically producing very little TXs.

Data from mintscan shows validators with fees at 0.25uSCRT at the moment (the high fee option in many interfaces) process roughly 1/10th of the TXs validators at 0.0125uSCRT process (they are at 1.2 per block):

https://www.mintscan.io/secret/validators

Since the fees we are talking about increasing to are pennies, people reading this thread should understand even if its expensive to do swaps on something like shade, this makes it a penny or so more. We are still talking about small amounts.

This doesn’t have an impact on relayers or users, transactions still go through and blocks are still produced. Furthermore, updating the fee options in keplr is trivial and would address this topic rather easily. If this point is associated with some specific user issues please share those issues here.

After some awesome discussions with everyone the final proposal that we want to bring on-chain is the following:

Hey everyone,

I am writing to propose a significant change to our network parameters that I believe will help to maintain the sustainability and robustness of our network. I propose that we implement a minimum gas fee of 0.1 uscrt/gas as a (changeable) on-chain parameter, that enforces every validator and node to adhere to a min-gas fee of 0.1 uscrt.

The following two things will be done if this proposal passes:

In the interim, if this proposal passes, we can enforce this min-gas fee via the Community API cluster, secret.express, to enforce minimum gas fee even before the on chain parameter passes.

Best,
Secret Saturn

4 Likes

Seems legit for me. I’d rather go with the soft approach. :metal:

1 Like

I think we have outdone ourselves with this signaling change, even if i dont know how widely accepted it is by validators at least frontends have moved and users are really disliking it.

If there is enough support id like to advocate for a slightly changed 3 step setting validators and frontends can choose to adopt. This until Secret moves to SDK v0.47+ and we can look at the Skip Block SDK for adoption based gas metering.

Additionally id like to advocate again for setting a Minumum min-gas-fee parameter so that we can force validators to charge above a certain amount if the community deems that necessary.

I have always thought the old LOW fee was the most problematic one, hereby a new proposed 3 step fee that is more in line with Feescaling of other cosmos chains and still puts slightly more value on Private computing space.

Low: 0.05 uSCRT
Med: 0.1 uSCRT (2x lower option)
high: 0.25 uSCRT (2.5x lower option)

Best,
Ertemann
Lavender.Five Nodes

4 Likes

I agree with the 0.05 / 0.1 / 0.25 SCRT proposal.
A 0.1 SCRT means that a 4-route swap on Shade will cost around 0.5 SCRT which is fairly good price for a medium price.
However, it will still allow a low price of 0.05 SCRT to be executed with lower priority. As a user this makes sense to me.

1 Like