For replies and posts and other actions that are not atomic interactions – i.e. simply toggling something – but involve submission of a larger chunk of data, these actions are sent independently from the batched ones. This is because of UX considerations, where we don’t want a draft post to be lost or forgotten in the mix, along side a bunch of other random up-votes etc. In these cases, the storage requirements are higher, since we’re posting a large b64 encoded string, so the tx fee is naturally higher here.
Also, yes, the fee for a single tip is still high, but as I tried to describe above, there are only a small handful of events happening in the code that really shouldn’t cost that much. Literally just setting a view integer values and adjusting an entry in a map. I think that the most costly thing about the tip tx comes from the fact that it involves the additional execution of a send message in addition to a message to update an index in an auxiliary contract of our own (the aforementioned Map entry update).
We’ve received considerable feedback here beyond Gelotto, highlighting concerns about excessive gas fees. Many of you have raised valid points, and while there’s discussion on whether Gelotto’s code is optimized, it is, the truth is clear to anyone engaging with ARCH: the costs are prohibitively high. This pricing is especially discouraging given the limited attractions available on the platform.
Was ARCH intended to feature high transaction fees? Perhaps, but under the assumption that its primary aim is to generate revenue and add value for its ecosystem/holders. Consult any reputable economist, and they’ll likely question the wisdom of imposing steep fees for services (like block space) that currently see little demand. Such a strategy risks alienating our dedicated user base.
There’s been a lot of feedback on this proposal. It’s both impressive, and refreshing, to see active interest in crypto governance – many similar forums for other networks struggle to drum up interest in governance. I’ll summarize the main take-aways from the discussion:
Overall, there is strong agreement that the MPoG should be lowered, but some uncertainty whether 140 Gway is the correct number. 200 has been proposed as one possible alternative.
Validators receive income based on ARCH inflation rather than from transaction fees, so validator income should be unaffected by changing the MPoG.
Developers receive a portion of the transaction fee each time their app is used (I believe the portion they do not receive is burned?), so changing the MPoG would affect developer incentives, however developers are also able to build-in a developer premium for any of their apps. If a lower transaction fee would result in an unacceptable reduction in revenue for a developer, one possibility to compensate for this would be for the developer to add a premium rather than relying on the Archway transaction fee alone.
In some cases, code optimizations can reduce the transaction fee for a developer’s app, and if a transaction fee seems unusually out of line for what a specific app is doing, reviewing the code, possibly with external assistance, is a good move.
At this time, a very tiny fraction of Archway’s blockspace is used. It is very appropriate for the MPoG to change as the use of blockspace changes, and as the price of the ARCH token changes. The idea of a DAO specifically focused on adjusting the MPoG when circumstances warrant this change was presented and seems well-supported. However, in the interim, an immediate reduction, per this proposal, to avoid deterring use of the network, also seems well-supported.
With the above in mind:
If this proposal went on-chain as soon as possible, as is, would the commentors here (and any others) be comfortable passing it?
If not, is there a proposed reduction you feel is more appropriate? So far, the only alternative that was suggested was 200 Gway. Would a reduction to 200 be widely approved?
Seconded. IF no one builds on the network, those fee re-distributions will be relatively negligible, and, when ARCH’s token price dumps, it hurts those who are supposed to be benefiting.
Seconded about not reduing by 6.5x, but, here’s something from the User side that is important:
We get hit by the higher fees. The users do not benefit financially from paying high gas fees in ARCH for every transaction. It discourages arbitrage traders from even going near Astrovault, let alone Archway, which is a serious problem. If you can’t attract arb traders, you will not get the traction you want, for mass adoption.
What it sounds like, is that Archway is paying developers to build apps, but those apps are not built to be sustainable businesses on their own. It’s basically copying the Silicone Valley model of “constant cash infusions” but for ARCH fee redistribution.
I’m not arguing that Archway’s fees SHOULDN’T be higher than other Cosmos chains, it’s just, when you have such a high minimum threshold, it makes it cost-prohibitive to trade volume when you’re getting docked $5 for a sub-$500 swap.
While I agree that lowering the gas fee will have consequences for a lot of interested parties, let’s just get one thing straight that is very important.
The high MPoG IS an impediment to mass adoption, period. Doesn’t matter how you try to justify that, if you want Archway to have a viable DEX of any sort, gas fees have to come down. Arb traders won’t touch this ecosystem without compromise from the devs and Network, overall. Otherwise, other networks will take market share.
Yes, this is also a call to any of the Archway devs who don’t want to cater to users at all, remember, Astrovault has brought tremendous attention to Archway Network. It IS the featured app and it DOES deserve special consideration.
Energy is very real, and without energy and enthusiastic users, Archway will be stunted indefinitely.
No doubt, balancing developer revenues with user accessibility is a delicate task. The intent has always been to ensure meaningful revenues, but feedback from the community has been pretty loud and clear – current fee levels are a point of frustration.
As an end-user myself, I’ve felt the sticker shock of a 3-5+ ARCH tx fee While I’m willing to eat that 5 ARCH, many aren’t.
From the beginning, we knew we’d need to experiment with these network parameters. That time has come…
While the ultimate goal is to make these values dynamic and context-aware, I agree some more immediate tweaks are needed to reduce onboarding friction / avoid pricing out new users during this early growth phase.
A few other points that come to mind:
These parameter changes are not irreversible, we can (and should) continue to optimize
For lower volume use cases that might be disproportionately impacted by reduced MPoG, there’s always the option to utilize contract premiums to supplement earnings
As stated, let’s all keep pushing to continuously optimize code
While I’m willing to eat that 5 ARCH, many aren’t.