We have deployed Threads and other dapps to chains like INJ/JUNO and it’s way cheaper. On INJ it’s a penny to create a long thread.
Most Web3 products are focused on some kind of financial transaction that makes it worth paying for gas. If we want to open up Web3 to normal people, we need apps people will just want to use without the expectation of making money. Making a post or even upvoting needs to cost less than a penny.
I definitely think we can get enough support to lower MPoG 
. We just need to find a middle ground that’s reasonable. Part of that journey should be optimizing Threads to consume the correct amount of gas. Since its gas consumption is higher than expected, we need to determine the root cause for it.
It might be hard to get validators to support such a large reduction to 140 ARCH/Gas as suggested in this proposal, this is because validators are barely breaking even afaik.
Supply / Demand economics, lots of block space everywhere, not enough developers. If Archway is truly serious about onboarding lots of devs, including Web2 devs, then we need to find a way to incentivize them. Can’t give them all money but what we can do is give them access to cheap compute + tech support until Archway gets more activity/users and once the demand is there, increases the gas.
Hey guys, awesome post, and thanks for bringing it here! I have 2 hats in this one, both as a co-founder of Astrovault, and the ex-Phi Labs Tokenomics Lead who contributed much to the existing design, gonna try to weigh in on both sides here.
Layer 1s need to capture value. The higher MPoG leads to more burns, theoretically more value capture. Yes it was initially designed with a lower MPoG, however that was also with dynamic fees which are not yet built out, and are pending another upgrade or two. This said, even your proposed decreased MPoG is still pricier than many other chains, and doesn’t set gas fees to 0.
We’ve discussed lowering MPoG before, and opted not to as the price of ARCH had significantly declined, leading to a similar dollar cost as asked for in the thread. As ARCH has recovered, and hopefully continues upwards, we’re certainly on the higher end of intended gas costs currently, and have room to go down. MPoG was always meant to be flexible, changing with the market and needs.
We won’t be at a risk of DDOS even with the proposal passing. It would still be very expensive and burn a bunch of ARCH, and it certainly would make it easier to onboard more people. Activity on the Archway blockchain hasn’t been substantial enough to capture significant value anyways, so much growth must take place regardless. A safe catalyst for growth is, in my opinion, a good idea, and we can always revert or fine-tune it if anything comes up.
I’d have chosen 200 GWAY as a target point, but think that potentially going lower than that to 140 is a great approach to bootstrapping community, and support this prop from my Archway hat.
Yes please!!! Our community is demanding it constantly. We have people coming in wanting to do a bunch more trades, but $50 trades with $0.80 fees adds gas significantly as a factor. Yes we’re benefitting from the ARCH rewards, but it’s worth it to us to forego those to grow our userbase who prefer us to alternatives, but are currently choosing to reduce their activity.
To date we’ve earned 81.5k ARCH in dev rewards ($14k at current prices) and over $400k in revenue from Astrovault’s model independently of the rewards. Whatever helps onboard the most users is what’s best for us, with our only concern that the chain is safe so that our operations can continue unimpeded. Dapps that struggle with monetization, who are most reliant on Archway’s model are free to set premiums on their contracts.
Now value capture for ARCH is still imperative to us, as the AXV DAO is heavily invested in Archway, but many have voiced that growing out the ecosystem, 10,000Xing our txs on chain even with 15% of the value capture, will end up capturing much more value!
TL;DR: You have my personal FULL SUPPORT with this prop, and I’m STOKED to use Threads more often with our community, at a more affordable price.
MPoG doesn’t affect validator income at all. Validators only earn from inflation. This directly impacts dev rewards and ARCH burned.
It seems to me like blockchain networks approach the matter of gas price as if there’s a one-size-fits-all solution. What really matters is whether the system is flexible enough to encompass a plurality of business models and software architectures. Ultimately, the gas system should be flexible. It should allow a smart contract designed to have more rapid but smaller executions have a different kind of gas rate and computation budget compared to other smart contracts designed to have less frequent larger transactions.
The blockchain doesn’t exist just for people in “crypto”. It’s also a general-purpose back end technology that’s an alternative to AWS as a platform for hosting micro-service architectures and as such has profound implications for current and future web apps.
Do we want normal web users or not? If we do, then we have to have a system that is flexible enough to create value through normal user interactions at scale, and we should be vigilant not to overfit the network to the speed and workflows of traditional financial applications.
Our goal should be to fill up the blockspace with meaningful, compulsive, consistent transactions as we progressively tap into the natural economic flows that emerge therein. If we don’t have a system that’s permissive enough to let new seeds grow, we won’t see the kind of innovation we need to see to reach the next level.
We have debated this issue for quite some time, as I remember an early governance call when Max and I were on stage discussing the psychological impact of unit bias alone. Seeing entire ARCH tokens be used for a single transaction (though cheap in the grand scheme of things compared to say, Ethereum) was always going to be a deterrent.
I am glad that we are finally having a discussion that will hopefully lead to a proposal going up soon. I fully support this and believe it will only help the Archway protocol grow its community base as well as draw additional developers to this incredible burgeoning network in the Cosmos ecosystem.
Easy AYE in my mind, and something that I am confident our team at Lucky Friday will support with our validator’s vote too.
Thanks for grabbing this issue by the reins and getting the discussion going, @Tritador 
I totally agree and, yeah, I had to learn this lesson the hard way myself. (This is Daniel | Gelotto, by the way). If I may extrapolate a bit on your point here… 
The thing is, even using strategies like the one you describe, the applications that we build often involve two or more modular smart contracts under the hood, which perform internal functions necessary for the user-level orchestration of the app, giving you search functionality, ordering functionality, relationship functionality, and so on.
To give you a concrete example, the Threads dapp that we just released involves three distinct types of smart contracts. Each thread is its own smart contract instance, instantiated through a separate “database table” contract, indexing their respective addresses and providing other functionality, like generic many-to-many relationships for associating given account addresses with contract addresses. It also provides tagging functionality. The FE can then paginate over the contracts and related addresses in various orders, simulating a SQL select statement. Not only that, but other smart contracts can also hook into this functionality for their own higher-level purposes, since it’s not in a DB but all on chain.
In addition to these things, there is also an ACL smart contract that manages roles and permissions granted to specified account addresses, allowing or denying access either to specific business objects or routes (i.e. contract execute functions). The Thread and Database contracts both query a shared Threads dapp ACL to authorize user executions.
All of these contracts use data structures and algorithms that are chosen with consideration to runtime complexity. Everything is O(1) or O(log N). In certain places, I’ve even employed runtime amortization strategies by distributing normally larger procedures across larger numbers of executions. Even though everything is reasonably designed and optimized, it still involves the execution of a number of things, beyond just adding or subtracting a single value somewhere within the business objects themselves.
On top of this, when you start batching together message executions across multiple contracts at the same time, like we do with threads, where someone can add multiple up-votes, tips, bookmarks, etc to something like a shopping cart and then checkout, batching them in a single transaction instead of approving a separate transaction for every little thing, they quickly add up to a prohibitively expensive sum; however, this kind of batching is precisely what is needed in a UI as more dApps are built using less monolithic design patterns that otherwise act as giant attractors for hacking and are more difficult to migrate and maintain over time.
Griffin - Phi Labs (Founder)
This is a great discussion on gas fees, and I’m glad it’s happening. Thanks to everyone for keeping it civil.
The vision for the protocol was never to become a chain with the lowest gas fees. Instead, it aimed to establish fees that are not overly burdensome for the end user but substantial enough to make a meaningful impact for developers and contribute to burning (sustainable emissions). This is likely to be an ongoing issue, surfacing every quarter, as we need to adjust various parameters in the protocol to effectively balance the interests of all stakeholders and align with broader chain goals.
If anyone wishes to form an ad hoc group (DAO) around this, I would be supportive
As mentioned earlier, I believe a crucial aspect of this is encouraging dApps to concentrate on optimizing their codebases. As a community, we can likely identify ways to significantly reduce the fees associated with our own dApp. I encourage everyone to revisit their codebases.
Lastly, in my opinion, the solution is not to reduce fees but to eliminate them altogether for the end user. An updated fee grant feature will be launching soon, assisting each dApp in subsidizing fees entirely for the end user. Therefore, Gelotto and Astrovault could potentially remove all fees for their users.
I support the idea of lowering mPOG, but in choosing the exact parameters, I would prefer a more data-driven and formulaic approach to adjusting mPOG because this won’t be the end of this conversation.
The tip function doesn’t have to read the post content. The content is stored separately, but it’s not as simple as ticking up a total tip value. There are other requirements at the
“user story” level, which necessitates being able to sort and page through all the individual thread contracts according to such things as total tip amount. The largest data element loaded by the function is a “node metadata” object that contains a few u16’s, u32’s, a couple Timestamps and an Addr. In regards to what the function does:
It’s really not that much, and it’s the minimal necessary to achieve a UX that’s not extremely boring or largely dependent on running a private database and web server to maintain – i.e. not a real dApp.
I could eliminate the need to read the entire metadata object, but its objectively not that much. If reading an object that contains a few integers and an address is considered “large”, then I think our concept of size and complexity needs to be revisted. If this is “large” then we really can’t build anything interesting or cool without putting the great majority of the business logic and non-functional requirements in a traditional AWS web stack
Side note: I’m looking into the possibility of storing the content of the thread in a compressed format. Zip maybe. The main issue there is that we can’t validate the contents of the post on the contract side if it’s compressed, so I’m still thinking about how we could do this…
– And as I said previously in an earlier reply: We’re not only looking at the cost of a single tip in isolation. To make the UX tenable, we have to batch multiple actions into a single transaction. Putting these tips together visually inflates the overall transaction fee to levels that are psychologically difficult to swallow.
Planned out a trade today just to get more Arch for trades. For a 5$ trade, the gas fee was $1.14! For smaller investors, the gas fees are a major obstacle.
This needs to happen sooner than later. Your estimates of a complex swap is off. I am paying $0.96 in Arch gas on almost every swap I make. and that does not count the Astrovault swap fees. I am sorry but this is not competitive nor is it acceptable and it needs to be addressed asap.
SUPER stoked to see this rolled out! Sounds like a major upgrade to UX in the entire ecosystem!
I also support the ad hoc DAO to monitor parameters, and am happy to contribute and/or equip them with as much info/resources to make best decisions possible!
Instead of waiting for that though, I personally still like the idea of a prop passing now in the short term, while we still work on a more fully fledged long-term solution so that the community can see action taken. we just need to make sure the conversation isn’t laid to rest after it passes while we build out a more data-driven and dynamic solution.
I misunderstood this, thanks for clarifying! Should be easy to get support for this prop 
Thanks for adding all of this context!
Is there a reason you aren’t batching txs from the dapp using executeMultiple?
They actually are. When a user tips, up-votes, saves a post, etc, they are staged in a shopping cart-like thing. On checkout, these actions are bundled and sent in a single tx (using executeMultiple in the FE)
This statement sums it up. I do agree that the incentive for builders with a higher-than-usual gas is useful, but in the bootstrapping phase of the ecosystem, in which we find ourselves, we might want to be slightly flexible to allow users to engage freely with the ecosystem and position themselves.
The gas could be increased progressively once certain metrics are achieved in activity, TVL, etc. The DAO suggested by @andergri to monitor this could be extremely helpful.
Agreed.
And it would be cool, as time goes on, to build new kinds of workflows that allow network fees to be payed out of a dapp’s organic revenue streams, from sales including things like sponsored posts, visual customizations, tools and services, etc. In addition, there are features in dapps that have natural fee regimen built in, out side of tx fees. Think maker/taker fees or taxes.
All of these mechanisms generate natural revenue for a business, and it would be better for us as a business to be able to pay network fees on behalf of our dapp instead of distributing the burden of paying the network fees to the user for each individual action they take, regardless of what the business model is.
Ah okay, sorry I misunderstood!
What worries me is one of the txs @notRizbe shared seemed to not even be part of a batch (unless I misunderstood) and the gas was still pretty high.
Luckily it seems so far like everyone is really keen to reduce the MPoG.
