Counter Proposal to the Envisioned Fee Schedule

Note: This article is quite long because there is a lot at stake and a lot to explain. A ‘TLDR’ can be found at the end of the article.

Context

In a few days, Gala will implement transaction fees on Galachain and open new endpoints to use the functionalities of the chain through programming. This is a major turning point for the chain we’ve been waiting for years. While the system can still be changed after the first implementation, it is fair to assume that this will lay the foundation for the final system. In that perspective, I want to raise awareness about an aspect that transpired as the focus of the first version of the fee schedule: individual fee scaling.

Traditional Fee Schedules

Blockchains need to implement fees to pay for its infrastructure and energy consumption. The fee structure is generally designed to smooth the design of the blockchain because of its limited computing and storage capacity. These technical limitations are not the same on each blockchain and depend mostly on the consensus mechanism. In descending order, this is more pregnant in blockchains using Proof of Work (PoW, e.g: Bitcoin), Proof of Stake (PoS, e.g: Ethereum, Solana) and Proof of Authority (PoA, e.g: Galachain). In our case, Galachain is designed to handle almost instantly a very high number of transactions at a very low energy cost. This usually translates to small transaction costs and low risk of congestion.

In general, the fee structure of a blockchain has the following structure:

A base fee unit

• Unique for every user at a given moment for a given block
• Increases when the network is congested
• Multiplied by the computational weight of a transaction to calculate the complete base cost

A priority fee (sometimes referred to as a tip to the miners)

• Bounded but set by the user
• The higher the value set by the user, the higher the cost and the faster the transaction

A storage fee in some cases (e.g: Solana)

• Users are periodically deducted small amounts of the gas coin to pay for the storage of their wallet’s data
• Proportional to the amount of data stored
• Can be exempted through a form of staking

Generally, the fee structure on a given chain is wallet agnostic: a fee does not depend on the wallet initiating the transaction but only depends on the overall congestion state of the chain and on the complexity of the transaction.

The overall congestion multiplier is required for:

a) fairness between users: user A who uses the infrastructure more than user B during a timeframe should pay more proportionally.

b) protection of the network: a user or group of users who overloads the system should be disincentivized to do so by the growing cost of each transaction

c) smoothing of blockchain usage: users should be incentivized to use the network when it’s the least congested.

Galachain’s Proposal

For the Galachain fee structure, Gala wants to introduce a new mechanism which I’ll refer to as an ‘individual scaling fee’. This mechanism entails:

• A few free transactions per wallet (potentially given periodically or at Gala’s will)
• A base cost for a transaction once the free calls are used
• An acceleration rate that multiplies the cost of a transaction for a wallet, based on its previous activity.

Arguments Against This Proposal

As you probably understood, this mechanism will increase exponentially the costs for wallets which use the network intensively. This would be the case for most services you can currently use on Galachain and others that might come. For instance:

• Creators coins projects: uses a lot of Mints or Transfer to distribute the coins to users or for giveaways
• NFTHarbor marketplace: uses a lot of Transfers through the escrow and soon Mints for the $HRBR token.
• Galaswap: usable thanks to marketmakers who use a lot of offer Requests and Terminate calls to adjust the price to the market.
• Distribution to node owners: several projects reached out to me to distribute NFTs or coins to node owners, this would use a lot of Transfers.

In a traditional fee structure, these projects would already pay more fees than a user who does a few transactions a month. This is normal because of reasons a) and b) detailed above: on first order, N times the usage equals N times the fee. However, with the individual scaling fee, the cost for these projects will be even higher sometimes unnecessarily. For instance: User A makes 100 transactions a day from day 0 to day 10 scaling its individual fee progressively and User B makes none. On day 11, User A and B have the same activity and User A will pay much more than User B for the same load on the network. Even worse, this could happen when the network is barely used at all and can handle the transactions very easily.

This unfairness is in no way justified by technical constraints. Of course, all things equal, this system would mean more revenue/burns for the network in the short-term but consider that increasing costs might make projects unsustainable or even discourage creators to setup their projects on Galachain rather than on another chain. I personally believe that projects are necessary to drive activity on the chain and thus increase burn. Creating unnecessary friction for them will have a negative long-term effect on burns. For instance, pump.fun is the big hit of the moment. Would a creator choose an ecosystem where he is unfairly billed for such a project?

Additional Considerations & Questions Regarding Individual Scaling Fee

• Established users: Gala and affiliated projects are established on the chain in a way that they create thousands of blocks per day. Will they pay the same costs as the average project creators? Who will pay in the case of projects that have almost no revenue (e.g: SpiderTanks)? Gala already hinted that some users will be whitelisted, increasing the unfairness of the system. On what basis will an user be whitelisted and by who?
• Prioritization of transactions: on traditional system, the fee for a given transaction at a given time can be moduled by the user to prioritize its transaction. In the example above, who between user A (active user with high fees) and user B (small user with low fees) will be prioritized for the same transaction on day 11?
• Bypass to the system: multiaccounting is an obvious way to bypass the costs induced by this system. One could create a new account whenever their free transactions are almost depleted. One could also create multiple accounts and transfer assets from a wallet heated by past transactions to a wallet that is cold and would pay less fees for the same transactions. In this case, please note that new accounts are also a load on the network as the data for each account must be registered on the blockchain.

Counter Proposal

• There shouldn’t be any free transaction.
• There shouldn’t be any individual scaling.
• Galachain should use a fee schedule similar to Ethereum’s or Solana’s based on computational use, storage use, overall congestion & individual prioritization. These blockchains have evolved for years to reach their current state, there is no reason to think a new system would be better than theirs, especially when it’s not supported by technical constraints.
• Several community members are willing to work on a global proposal for the fee structure. If I feel that a discussion can be opened with Gala after this article, I will actively contribute.

TL;DR :Gala is set to introduce transaction fees on Galachain with a new fee mechanism known as the ‘individual scaling fee,’ which may significantly increase costs for active users and projects. This proposal argues against this fee structure, citing potential unfairness and unnecessary burdens, especially when the network is underutilized. It suggests adopting a more traditional fee structure similar to Ethereum or Solana, which focuses on computational use and overall network congestion without individual scaling. This aims to ensure fairness and encourage sustainable project development on Galachain.