This post has two proposals. 1. Increase tx fees, 2. Introduce burning mechanism to tx fees.
Increase tx fees has two proposed benefits. A. Make DDoS attacks more expensive, B. Explore funding Masternodes with tx fees.
Introduce burning mechanism has one proposed benefit. A. Increase deflationary pressure on tokenomics.
1.A. I think it is important to recognize this as an issue and to figure out a solution to the problem. I don't know if a static tx fee is the solution here or if we need a dynamic fee that responds to tx rate per block (similar to EIP-1559: github.com/ethereum/EIPs/blob/mast...). I think that it needs to be difficult to change the tx fee, so if tx fee becomes a variable that can be set with a protocol upgrade there needs to be a high bar for justification for changing it. We also need to be cognizant of other discussions around tx fees, for example there is an active proposal to upgrade the XDC Network EVM, and this proposal discusses adopting changes related to tx fees: xdc.dev/gary/proposal-on-evm-upgra...
1.B. You are correct that the centralization (both funding and payment mechanism) of masternode reward payouts is an issue that needs to be addressed. One variable that we need to be aware of is that proposals for changes to masternode count and reward amounts are being actively proposed (xdc.dev/riteshkakkad/xdc-network-p...). I think that masternode count/type/rewards should be considered dynamic right now, and that considerations around how/if masternode rewards are subsidized has to wait until proposed changes to masternode count/type/rewards are settled.
2.A. I think that introducing a burning mechanism to tx fees is less important 1.A. and 1.B. Tokenomics is very complicated; increasing the burn will add deflationary pressure to the token supply, which may lower transaction count as existing holders are less incentivized to spend XDC whose price they expect to go up with increased burn, which may lower liquidity of XDC, which may decrease the perceived value of builders looking to select a network to build on. Or maybe not, it's almost impossible to predict (at least for me). There is also the possibility that dApps can elect to burn XDC by sending it to xdc0000000000000000000000000000000000000000, which is important because it shows that burn can't be controlled purely at the protocol level. All I'm saying is that Tokenomics is very complicated.
Given the above statements I would be in favor of moving any discussion around Burn to a different proposal. I know it is convenient to try to kill two birds with one stone, but I don't think it will be efficient.
Lastly, if this vote passes then it will require a group of people willing to champion this idea through the XIP process. I vote for two XIPs, one focused on tx fee increase mechanism and a second focused on introducing a burning mechanism to transactions.
Great, great points. Yes, the proposal was a bit unclear on this front. To be clearer, as I said in the conclusion (but not in the introduction, which I'll go ahead and edit slightly now), the current proposal and vote is ultimately only about this: do we want to increase TX fees, yes or no? How much to increase the TX fee, and how much or (even whether) to burn, depends on the yes votes winning here ... so we'll have separate proposals and votes on those issues sometime down the road, once this more fundamental question is settled by the community. Thank you Jon!
For further actions, you may consider blocking this person and/or reporting abuse
VOTE = YES
This post has two proposals. 1. Increase tx fees, 2. Introduce burning mechanism to tx fees.
Increase tx fees has two proposed benefits. A. Make DDoS attacks more expensive, B. Explore funding Masternodes with tx fees.
Introduce burning mechanism has one proposed benefit. A. Increase deflationary pressure on tokenomics.
1.A. I think it is important to recognize this as an issue and to figure out a solution to the problem. I don't know if a static tx fee is the solution here or if we need a dynamic fee that responds to tx rate per block (similar to EIP-1559: github.com/ethereum/EIPs/blob/mast...). I think that it needs to be difficult to change the tx fee, so if tx fee becomes a variable that can be set with a protocol upgrade there needs to be a high bar for justification for changing it. We also need to be cognizant of other discussions around tx fees, for example there is an active proposal to upgrade the XDC Network EVM, and this proposal discusses adopting changes related to tx fees: xdc.dev/gary/proposal-on-evm-upgra...
1.B. You are correct that the centralization (both funding and payment mechanism) of masternode reward payouts is an issue that needs to be addressed. One variable that we need to be aware of is that proposals for changes to masternode count and reward amounts are being actively proposed (xdc.dev/riteshkakkad/xdc-network-p...). I think that masternode count/type/rewards should be considered dynamic right now, and that considerations around how/if masternode rewards are subsidized has to wait until proposed changes to masternode count/type/rewards are settled.
2.A. I think that introducing a burning mechanism to tx fees is less important 1.A. and 1.B. Tokenomics is very complicated; increasing the burn will add deflationary pressure to the token supply, which may lower transaction count as existing holders are less incentivized to spend XDC whose price they expect to go up with increased burn, which may lower liquidity of XDC, which may decrease the perceived value of builders looking to select a network to build on. Or maybe not, it's almost impossible to predict (at least for me). There is also the possibility that dApps can elect to burn XDC by sending it to xdc0000000000000000000000000000000000000000, which is important because it shows that burn can't be controlled purely at the protocol level. All I'm saying is that Tokenomics is very complicated.
Given the above statements I would be in favor of moving any discussion around Burn to a different proposal. I know it is convenient to try to kill two birds with one stone, but I don't think it will be efficient.
Lastly, if this vote passes then it will require a group of people willing to champion this idea through the XIP process. I vote for two XIPs, one focused on tx fee increase mechanism and a second focused on introducing a burning mechanism to transactions.
Great, great points. Yes, the proposal was a bit unclear on this front. To be clearer, as I said in the conclusion (but not in the introduction, which I'll go ahead and edit slightly now), the current proposal and vote is ultimately only about this: do we want to increase TX fees, yes or no? How much to increase the TX fee, and how much or (even whether) to burn, depends on the yes votes winning here ... so we'll have separate proposals and votes on those issues sometime down the road, once this more fundamental question is settled by the community. Thank you Jon!