GalaChain Fee Proposal Discussion
Several people including me were asked by Jason Brink to start creating a draft for the GalaChain fee structure proposal. Source: Discord / X
Lukabylie put his proposal draft together HERE. Let’s put together feedback on Lukabylie’s proposal and then we can discuss the points BitBender mentioned in his X post in more detail.
Lukabylie's Galachain Fee 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.
Lukabylie is discussing also a few “Arguments Against His Proposal” Where I agree with his belief.
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.
In the next part we are going to take a look at Lukabylie’s additional 3 considerations & questions regarding the individual scaling fee:
- In the first part “Established users”, where he means Established Channels (Gala and affiliated projects e.g.: Spider Tanks) I don’t think this area should take part in this discussion because established channels have their own Node Networks and the free market should take care of this by itself.
- Regarding Lukabylie’s consideration of “Prioritization of transactions” I think there is nothing to consider if we incorporate a functional antispam system which is proposed in this article below.
- Regarding Lukabylie’s consideration of “Bypassing the system” I think that multiaccounting is a normal feature of each network. Everyone can have more email addresses or Ethereum wallets. I would rather let the free market solve this problem on each project level than try to solve it systematically on the blockchain level.
Lukabylie’s shorter 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.
Jason Brink aka BitBender mentioned in the X post that we should follow this list so we can come up with a solution. We have 4 areas to focus on:
- Seamless Experience
- Channel Operator Control
- Preventing Spam
- Decentralized Oracle
To allow the community an easy way to comment, visit the copy of this article in Google Docs where you can write your comments.
1. Seamless User Experience
1.1 Maintaining a Smooth Flow: BitBender emphasizes that gas fees should never interfere with user experience on GalaChain. The system must ensure that transactions and operations remain smooth and uninterrupted.
1.2 IPFS Storage Fee: To reward Founders Nodes (FN) operators for hosting IPFS data, a fee structure could be introduced. Users could pay a gas fee for additional copies of their data beyond the default settings or for faster download speeds.
1.3 IPFS Pinning Fee: GalaChain could offer data pinning on FN nodes for a fee, ensuring long-term availability. This fee could cover 4–10 years of storage before another pin would be necessary.
1.4 Micro-Fee System: A micro-fee system could be implemented where minimal gas fees are collected and pooled in the background, without impacting individual transactions. Transactions would remain free until the Play & Earn (P&E) effect kicks in, after which a small fee, such as $0.001 per transaction, could be deducted from the user’s earning on-chain activity.
1.5 Ad-Based Revenue Model: An ad-based revenue model could be introduced, where advertisers pay to have their content displayed through an auction system. The fees generated from this model could be burned, and ads could appear on GalaChain Analytics, GalaChain Browser, and GalaSwap.
1.6 New Token Minting Fee: A small fee in $GALA could be charged for creating new tokens on the Gala Creator Platform. This fee would help reduce spam by making it less attractive to create irrelevant tokens.
1.7 Bridging Fee: Micro-gas fees could be applied for bridging transactions between different chains, with a suggested fee of $0.001 per transaction. These fees would be collected in the background, ensuring no disruption to users.
1.8 New Wallet Creation Fee: When a new wallet is created, it could incur a small debt to the network. The first receiving transaction to this wallet would automatically pay off this debt, set at $0.01.
1.9 Download Fee: Each time a content is downloaded from a FN, a debt could be incurred by the downloading wallet. This debt, equal to $0.1, would be paid after minting/receiving P&E or other rewards to the wallet.
1.10 On-Chain Nickname Fee: Users could pay a fee to change their on-chain nickname to a unique ID, making their address more recognizable (e.g., “MetaFlora_Treasury”). The suggested fee for this service could be $0.10.
2.1 Empowering Channel Operators: BitBender insists that the power to adjust gas fees should rest with the channel operators, not Gala. Even if Gala has the technical capability, the control over fees must remain exclusively with the channel operators, empowering them to manage their channels effectively.
2.2 New Channel Voting Fee: To propose a new channel creation, a vote could be deployed on Gala’s Node Dashboard at a cost of $500 in $GALA. The fee would be burned after the vote concludes.
2.3 MAU Success Fee: If a specific GalaChain address interacts with a channel’s smart contracts for three consecutive months, it indicates a level of demand or success. FN could be rewarded in such cases, with each active address contributing $0.01-0.05 per month. This fee would be deducted from the reward stream (e.g., P&E rewards) unless the address never becomes financially active, in which case no fee would be charged.
3.1 Smart Gas Fees: According to BitBender, gas fees should be smart and responsive, acting as a deterrent to unwanted behavior on the chain. This approach would help keep spam and other disruptive activities in check.
3.2 Airdrop Fee: Airdrops are a common marketing tool, and FN operators should be rewarded when an airdrop occurs on GalaChain’s main channel. The fee could be set at the equivalent of 7 days of FN distributions or $200 in $GALA if the $GALA equivalent has a lower value.
3.3 Rapid Transaction Burst Fee: A dynamic transaction fee model could be implemented to target accounts exhibiting suspicious behavior, such as rapid transaction bursts. The fee would scale exponentially based on the severity of the behavior.
3.4 Reputation Scoring System: A reputation scoring system could be introduced to control fee per action unit. Participants with higher reputations would enjoy more relaxed rate limits, while those with lower scores might face higher costs or restrictions. This system would require robust monitoring to prevent abuse.
3.5 Verification Measures: For bulk transactions, users might be required to perform additional verification, such as 2FA, email confirmation, or CAPTCHA, for each portion of the action. These requirements could be relaxed for users with higher reputations or trusted nodes.
3.6 Time-Locked Actions: To prevent spammy behavior, a time-lock could be imposed between mass actions. After submitting a bulk transaction, users would need to wait a few seconds or minutes before submitting another. This delay would allow the reputation system to assess the user’s behavior.
3.7 Legit Stake System: To perform mass actions, users could be required to stake a certain amount of $GALA. If the action is flagged as spammy or malicious, the stake could be locked and potentially burned. Legitimate actions would see the stake returned. The stake amount could increase based on network activity levels.
3.8 Honey Trap Accounts: Honey trap accounts could be set up to appear vulnerable, attracting spammers. Once these accounts are targeted, the spammers would be quickly identified and blocked from the network.
3.9 Anomaly Detection: AI models could be used to detect and flag unusual patterns of behavior indicative of spamming. Once flagged, the system could throttle or temporarily block the user, pending further investigation. While this approach would adapt to new spamming techniques, it would require ongoing model training and could be costly.
4.1 Fully Decentralized Oracle System: As BitBender notes, if gas prices are tied to a fiat value, the oracle determining this must be fully decentralized. A system with no single point of failure or control is crucial for maintaining trust and reliability.
4.2 Layered Oracle Architecture: A multi-layer oracle system could be implemented, where the first layer collects raw price data, and subsequent layers aggregate, validate, and cross-check this data before it reaches the final price feed.
4.3 DEX Price Feeds: Using decentralized exchange (DEX) price feeds could enhance the reliability of fiat price data, aligning with the decentralized nature of GalaChain.
4.4 Data Consensus Mechanism: A network of decentralized oracles could be established, with each oracle operated by independent entities. These oracles would submit price data, which would then be validated through a consensus mechanism. A dispute resolution process could automatically trigger auto reevaluation if conflicts are detected.
4.5 Oracle Staking & Reputation System: Oracles could be required to stake tokens as collateral, with the risk of slashing if they submit inaccurate or manipulated data. This system would incentivize accurate reporting and keep away bad actors. Additionally, a reputation system could be established, where oracles with a history of providing accurate data gain more influence in the consensus process.
4.6 Cross-Chain Oracle Integration: Integrating oracles from multiple blockchains could enhance decentralization and redundancy, providing a more robust and reliable oracle system for GalaChain.
About Rocket Unit
I’m one of you. A Founder Node operator who became part of the Gala Games community in March 2021, thanks to a referral from a friend in the Czech Republic. Over the past few years, I’ve devoted myself to the Gala ecosystem, volunteering as a moderator for Gala’s Czech community for over a year. I’ve also participated GalaVerse Malta in 2022 and represented Gala & GalaChain at various events, most recently at Crypto Summit Del Sur in Brazil, Feb 2024.
My crypto journey began in 2017, and since then, I’ve developed a deep understanding of the space. With a background as a full-time trader, Web3 gaming VC analyst, marketing manager, and co-founder of a Web3 marketing agency, I’ve gained valuable experience to help others succeed in their Web3 projects. Currently, I’m working as the Marketing Director for MetaFlora, a project based on GalaChain that mostly helps with cannabis verification and information access.
X | LinkedIn | LinkTree | Free Marketing Consultation
