This is just an idea, I want to open a discussion about it. I am hoping you can help me flesh out this idea. Maybe it’s already been discussed.
Right now I believe we all pay, what, .0001 ICP with every transaction for a fee. Is that right? It’s very low, we love that. But first off, can that fee be changed via NNS?
I think everybody here wants to see more ICP burned. My idea is that we could set the burn fee at a constant $USD amount, maybe $.01 per transaction. Something very low. But when price is low, that burn fee is greater in terms of ICP.
Right now we have a similar system with cycles, where at low prices more ICP need to be burned to obtain the same amount of cycles.
The advantage here is that at low prices, people would be burning more ICP in their transactions, which could help (very marginally) to support price at these low levels. And if price ever did fall to, say, $.03 (people like to joke that we’ll fall back to VC price) we would see lots of ICP burned.
Thoughts? The main idea is this: the transaction burn fee could be changed to be a constant $USD (or cycles) amount.
For days I have been thinking about a dynamic transaction pricing system, whether related to cycles or a fixed sum.
This makes a transaction come out the same when the token was worth 50 that it is currently worth 5 and when it is worth 500 it comes out the same.
I’d be surprised if a research team hasn’t thought of all the possible ways to motivate burning, I think they already have… That’s why I didn’t post my thoughts, I think they already thought about everything and everything has a logic.
It could also be used to reduce volatility. If the price is very low ($5) it generates an extra burn by increasing the price, if the price is very high ($1000) it generates less icp burned per transaction.
That’s correct, every (ledger) transaction costs/burns 0.0001 ICP.
And yes, it would be possible to implement a different strategy for transaction fees and create an NNS proposal to change the behavior (if the proposal gets accepted).
@bogdanwarinschi can certainly say more about this but one advantage of (and reason for) the current fixed fee is that it is simple. No interaction with the cycle minting canister is required to determine the fee.
Personally, I don’t think changing the ledger transaction fee to a constant value in fiat terms would increase the burn rate considerably because transactions are and should remain cheap. As you can see on the dashboard, less than 0.5% of all ICP is burned in transactions, so even a tenfold increase would not change the burn rate dramatically.
But I’m happy to read about other perspectives and ideas.
Thanks for the compliment but I’m very sure that we haven’t thought of everything - and any input that helps us and the community to improve the Internet Computer is greatly appreciated!
Thank you very much for the reply! So I am going to continue with my analyzes that I have been carrying out to model the idea. I’ll share them later on the forum. Thank you !
Again, burning ICP as a result of ICP transfers has a very small effect on the total supply at the current trading volume. Changing the fee to something like 0.01$ wouldn’t have a big impact even at times when the ICP price is low.
Note that the purpose of the ICP ledger fee is to prevent denial-of-service attacks.
At 0.0001 ICP, a transfer costs more (even when the ICP price is low) than the cycles required to update the balances in the ledger.
Raising the fee is also risky in that certain applications with high trading activity may suffer and, in the worst case, may no longer be economically viable. Moreover, if there is a reduction in ICP transfers as a result, the burn rate may not increase (or even decrease).
Such aspects need to be considered carefully before making changes.
Another issue is that many callers explicitly state that the fee they’re willing to pay is 0.0001 and not more. If the fee were raised, a lot of the canisters that perform ledger transfers would (accidentally) stop working entirely.
If a DEX makes many ICP transfers, its operational cost could increase by up to a factor of 100 in that case. Even if the DEX can pass on this additional cost to its users, it’s still a significant change (the new fee may affect trading activity).
A DEX will likely survive such an increase but, as @Severin pointed out, canisters may also simply break because they expect to pay a fee of 0.0001 ICP.
Unless the canister is black holed which would be the only instance in this case where it would be a problem. You could easily update the canister to expect a new transaction fee amount.
You guys act like projects can’t update their own canisters especially with this simple update.
If that’s the case this should be addressed sooner rather than later while the network is still small. Waiting to do so when the network is say, 100x larger, will make it even more difficult to address should the community eventually decide to change the fee further down the line.
Additionally if the state of this project in it’s entirely is at risk of collapsing due to a death spiral something small like this isn’t a big request to ask from developers for implementing their own personal update to their projects.
Yeah it’s a low impact to the overall problem with the tokenomics but if it’s a small positive impact I think its worth implementing.
Alright, let’s assume that changing transaction fees will not break the internet computer. I assume this could be done. Now I’m an idiot regarding tech, please forgive me here. But if canisters are hard coded to a .0001 fee, maybe the fee should instead be coded as a variable, no? And then that variable could be changed by proposals?
I think it’s obvious that transaction fees should be under the jurisdiction of the nns. Am I wrong?
The configuration is controlled by the NNS and can be adjusted easily. But if other canisters have the fee hard-coded those canisters will break unless they get updated