Recently we saw some spikes in transaction costs on Gnosis due to a demand spike from “Ordinals”. While transaction fees ultimately need to cover the cost of running a chain and thus are a positive thing for the chain, on the other hand applications want transaction fees as low as possible or at least not having to deal with huge spikes that essentially make their app temporarily uneconomical.
In this post we want to discuss the economics of Gnosis chain, come up with expectations for future fees and try to discuss ways how to protect applications from gas spikes.
Sustainable fees
Running a blockchain has costs. At the minimum the cost of running the desired number of nodes/validators. The higher that number is, the bigger the “replication factor” of the chain and thus security guarantees that the state of the chain is never lost. Beyond that you want economic security of people locking up capital as “stake” for their validators.
Verify simplified napkin math suggest that the minimal cost to incentives the current validator set at current GNO price is what the chain spends in validator rewards.
170k GNO * 200$ = 34m
Those validators currently earn ~10% = 3.4m
So at a very minimum the chain should generate those 3.4m $ in fees to not need to be financed by GNO inflation or subsidies from GnosisDAO. However - running a chain has more costs, including financing core developers to maintain clients, or potentially financing critical infrastructure like block explorer.
So as ballpark I would say that minimum costs to maintain and run a chain like Gnosis sustainably are in the area of $10m. Please note that is just covers bear costs and would not have any value accrual to GNO.
Let’s quickly do the math on what that means for transaction costs:
If we go with 15m (average gas) blocks (as Ethereum) but with the faster block time of 5 sec (instead of 12) we get: 15m * 12 * 60 * 24 * 365 = 94.608.000m gas per year. Devided by 10m we get:
9.460.800 gas/ $ or
94,608 gas / cent.
So as a very rough estimate, a simple token swap (150k gas) would have to cost ~$0.015 to the chain to be sustainable.
Now, again - those are very rough estimations and one way to keep prices down while still earning the $10m per year as a chain would be to increase the block gas limit. While clients are pushing the limits of what is possible and we might be able to do a 2x - 10x increase (which then could bring the “sustinable gas cost price” down by the same factor) I would still say: if your application can not effort such a fee you might need to look for another home for your chain at least in the next 1-3 years. A great option might be a rollup on Gnosis - one-click options are available by Gateway here.
Lucrative fees
Looking at the other end of the expectation spectrum:
If users would pay similar high fees on Gnosis as they are currently paying on L2 (e.g. 40 cent) per swap - this would lead to a very significant overall fee and thus high value accrual for GNO token. (40 cent per 150k gas ~270m in yearly transaction fees)
Balancing incentives between users and GNO holders
To understand the incentives and possible solutions of fee pricing we can think of a chain like a city that has a specific housing capacity. Application are the renters, and GNO holders are the landlords. However, in this city rents are strictly determined my supply and demand. In a month where a small number of people want to live there rents are almost free (current state) - however - if there is a festival in that city rents can increase 100x from one month to the next. As someone who lives there this is a big problem as your moving costs are very high (migrating to another chain (and you might have the same problem there)).
In the city example I see two solutions for renters:
- long term contracts
- becoming a landlord
Translated to Gnosis, this would mean:
- Block space futures
ideally an application could already in advanced purchase a specific gas amount. You could e.g. buy “100 m gas per day for the next 2 years”.
- GNO locking
If possible, applications and users are GNO holders themselfs, In this case holding GNO can be seen as owning a home and thus you are able to live there rent free. Gnosis chain could offer a mechanism where you either become a validator (earning GNO rewards and tx tips) or use the GNO to lock it which would give you specific transaction capacity you can use “for free”.
To give a rough idea how much that could realistically be:
15m * 12 * 60 * 24 = 259,200m gas per day. If we divide that by 2.5m GNO we get 103.680 gas per day or 725.760 gas per week.
Local congestion
Of course temporary congestion can still happen. E.g if there would be e.g. 30.000 GNO locked that each get the right to consume 100k gas per day - this would be 3000m gas per day. Given that 259,200m gas per day are offered that is less than 1% and should not cause any problem. However - if all those 30,000 GNO locker would want to do a transaction at the very same time, it would still take at least 100 blocks to clear them out. (3000m/30m).
So in this case it becomes clear that worst case guarantees can fall back to: users will be able to include their transaction within a time period for free but not at any point in time.
If you wanted a guarantee you would need to buy blockspace right in every block. This would be incredibly expensive as any block just offers 15m gas. Divided by 2.5m GNO this would result in just 6 gas per GNO per block. So to have the right to do a 60k gas transaction (e.g a simple token transfer) you would need to lock 10k GNO (~$2m)
Luckily we already have an instrument for very local congestion - basefee vs priority fee. Unless we have local congestion the priority fee should be almost irrelevant and a tiny amount gets your transaction into the chain as long as you pay the base fee. However - if the block is full the priority fee becomes the deciding factor. Therefore, a simple implementation would refund user that have bought rights for blockspace the basefee and they just need to pay the minimal priority fee.
Avoiding base fee explosion
In a naive implementation of base fee refunds this could cause a ginormous spike in the base fee. In our previous example we would have 3000m that are completely insensitive to the base fee. So they could fill up the chain for 100 blocks straight (increasing the base fee at 12.5% each it would lead to an overall increase of (1.125^100) factor 130,392 (!). After that it would roughly take another 100 blocks to bring the base fee back to normal. In other words - the chain would become unusable for everyone how does not have this base fee protection. Therefore a sensible approach would be to limit the amount of transaction in a block that can use the base fee refund mechanism. This limit should be certainly below 50% to ensure that a spike in gas fees can only occur if there are actually users that are still willing to pay that base fee. A sensible number could be 25% of the max capacity (so 50% of the target capacity).Concrete proposal
My concrete proposal would be for Gnosis to explorer how users and dapps can get the right to do transaction where they will not have to pay the base fee. However - each block will only have a limit capacity of e.g. 25% * 30m = 7.5m.
Side note: on Gnosis the base fee is taken in xDAI and instead of being burned it is send to a contract controlled by the DAO. This allows for implementations of the above on smart contract level.
It will be difficult to give EOAs that ability without touching the core protocol. However - Safes on the other hand can execute transactions via 4337 or projects like Gelato. It seems easiest to implement setup where the extra logic is handled here and there is e.g. one large bundle transaction per block that handles the up to 7.5m base-fee-refundable transaction.
Feeback
Would be intrested in feeback on:
- on the general idea
- what are the costs your application is comftable with
- what is a inclusion speed you are comftable with (within 3 block, 10 blocks, 100, 1h…)
- what is the maximum variance in fees you want to accept
- are you fine using smart contract accounts that have inclusion guartees, or do you need it for EOAs