Increase the cost of bytes

Currently bytes are very significantly underpriced.

We currently charge 10 gas per byte, and I propose 100.

I have to go to sleep now, but I just wanted to get this out and on the forum.

I will be testing this by putting a governance proposal to this effect on the testnet first, so that we can gather some data, and then deploying this on mainnet.

1 Like

What is the reasoning behind this? Isn’t one of the main advantages of Osmosis vs ETH or an L2 that gas prices are very low? This seems to put gas more inline with L2s.

1 Like

Not so sure whether extremely (near zero) tx fees are always a plus.

But it would be good if @faddat would post his more elaborate thoughts :slight_smile:

1 Like

I mentioned this on the other similar thread but surely cheap fees for the average user is a big plus (especially if we’re trying to distinguish ourselves from the up and coming L2s which have lower swap fees and better liquidity – we have better offerings of shitcoins). What faddat and Rarma are trying to “fix” seems to being cyclical (osmo->route->osmo) arbitrage bots spamming the chain because they think they find opportunity. Like I said on the other thread, it’s absurd to me that a whole module was uploaded to the chain in the form of protorev which was supposed to capture this value. Protorev gets first priority at the pickings and doesn’t have to race on speed in the mempool. So it’s crazy that they are leaving opportunities for bots to take advantage of – from what I’ve seen, it seems because some of the routes through newer pools are missing.

Even if the fees are 10x’d, 100x’d, if protorev is leaving an opportunity, it’s going to get spammed by lots of bots trying to take advantage of that inefficiency whenever they occur, even if it’s a rarer occurance. And spam like that will always take place in a short period of time, causing congestion (ie a lot of txs spread out over time isn’t an issue)


An increase from 10 to 20 will be proposed as part of the next software upgrade proposal, which is due very soon to tackle the ongoing issues.

This was also touched on in the signalling proposal thread to raise the maximum gas and lower max bytes.

While a smaller increase than what @faddat is proposing, this will let us see the impact of increasing the bytes and choose whether to increase it further by parameter change proposal while having a much smaller impact on transaction fees.

We are likely going to propose a further gas increase after the v22 upgrade is in place, so I think we can tackle both issues at the same time with further increases if required.