Thanks for the answers !
Beginner questions.
1.
Currently it is set that the transaction cost is 0.0001, that is not verified anywhere? why if you set a different value (daily or weekly) it would imply an increase in latency ? if currently it also comes out somewhere that you have to burn 0.0001 per transaction.
2.When you talk about adoption, do you mean adoption for dfinity programmers to adapt the proposal or mass adoption of application developers? If what I told you about point 1 (an update every day/week) is applied, wouldnât it be transparent or more predictable than the current price that changes enormously every day?
The truth is that I donât have technical knowledge to ask you any questions on this point, I just wonder what happens in other blockchains where you have a dynamic burn for each transactionâŚ
Thanks for responding ! Do you think the price of ICP is more predictable than the price of the dollar or the equivalent in SDR?
If I ask you in the long term, how much are you going to spend to make 1 million transactions and you have on the one hand a cost of 0.0001 ICP, vs a cost of USD 0.01. What would be an easier answer?
Letâs take a simple hypothetical - a canister that holds an ICP balance. Every time its method disburse is called, it sends its balance to a specific AccountId.
Today, that process is as simple as calling the ICP Ledger canisterâs transfer method with the following info:
public type TransferArgs = {
memo : Memo;
amount : Tokens;
fee : Tokens;
from_subaccount : ?SubAccount;
to : AccountIdentifier;
created_at_time : ?TimeStamp;
};
Today, that flow would look like this: the canister calls the ICP ledger and checks its balance. 1 async call.
Then, the canister knows everything it needs. The memo, fee, from_subaccount and to can all be hardcoded, and created_at_time is optional. The amount is whatever it has in its balance, minus 0.0001 ICP as the fee. The transfer will run, totalling 2 async calls.
With this proposal, the fee becomes dynamic. We need to configure some sort of scheduled job to update the fee, and we also need logic for what to do in case the fee is wrong. The safest way to handle this would be to request the fee with each transfer, but that would make each update require 3 async calls instead of 2. Instead, the more rational choice would be to cut out the check, and to either have additional costs from using the canister heartbeat feature, or to use an off-chain scheduling service to update the conversion rate.
Most canisters may have at best error handling for the price, but most will just have that number hardcoded today, because the number does not change in practice.
I mean adoption of application developers
I think that the mental model of âhow much does this costâ to a layperson is different from an engineer. Simply put, a transaction costs 0.0001 ICP. The smart contract doesnât need to care about fiat currency at all right now, because the units it transacts in are just tokens. 0.0001 ICP is 100% predictable. It only has the appearance of fluctuating when you are comparing it to your wallet balance in Coinbase or whatever
I love it. Thank you for your hard work on this proposal! I will vote for this proposal, whether the final form ends up being articulated in cycles or in $USD. It helps reduce the possibility of a downward spiral in price and also prevents the he transaction fee from getting out of control at hypothetical higher prices.
Safety comes first and when I think about ICP. Cheap alternatives tend to be more expensive in the long runâŚ. FYI Usually I donât respond more than twice without getting paid; to avoid going around in circles thatâs just me.
To answer your question, in order to prevent a rug & pull, the dynamics of the network have to Match the market demand. If ICP is hot obviously more is at stake so it would be expensive to transact, simple market dynamics.
I agree with @skilesare that .001$ would be a better price for tx fees, itâd be way more expensive than the current one, while still being cheap and appealing, .01$ might not look like much but it quickly adds up when youâre doing thousands of tx.
I agree with all your points, but imo this scenario could happen regardless in the future. Even with a fixed fee if the price of ICP pumps or dumps by orders of magnitude the NNS might decide to change the tx fee cost, e.g with 1k$ ICP hypothetical price 1tx would cost 0.1$, thatâs definitely way more than intended.
So it might be preferable to promote asap better practices when handling tx fees and break a few canisters now rather than many in a few years.
Iâm building something requiring micro payments. Or at least rather small payments.
Donât underestimate the use cases that we could see related to small payments, I think itâs still unexplored territory. At least if I understand correctly a part of the intention behind this proposal is to make ICP payments more expensive simply to burn more, correct?
I think it would send a bad signal. A mass coordinated effort to approach VCs would probably do more for the price than that.
Iâm also wondering how price increases will impact the transaction costs, like how scalable are ledger transactions exactly? I did not properly think about it running on a single subnet. I was assuming the fees would go up by less than on other chains due to horizontal scaling. Am I completely wrong about this?
Thank you very much everyone for the answers! Apparently there are technical issues that are impossible to apply this idea/proposal ([Proposal] Fixed transaction price: USD 0.01 - #19 by kpeacock). We will continue to think about proposals on other topics. Thanks again everyone!
It is also good that this topic remains open to give related ideas (perhaps some do not have technical impediments)
If all devs needed to burn at least one ICP to get started we would already have had a large burn rate. Making a minimal burn rate for ICP should be much more feasible than a minimum transaction fee.
extra perk: This ensures that the people making the canisters have at least 1ICP of vested interest in the site (no bots, mass-made phishing sites etc).
No it does not⌠That is a common false assumption with 0 empirical evidence. Apple charges $99/yr to developers and they are doing fine. So do AWS, Heroku, any platform for devs⌠moreover they are normally a lot more than $5 to deploy.
Actually with a âcheapâ price it can be viewed as an âinferior goodâ which would dissuade the exact type of developers we would want to onboard.
Those platforms are established already, the IC isnât. Besides AWS and Heroku charge based on usage just like IC, donât they? Apple is the exception, but hey itâs freaking Apple.
Plus you canât simply replicate their model, on the IC a single dApp can have hundreds/thousands of canister, whose creation already has a relatively high fee (0.1 XDR iirc), charging 1 ICP to create a canister will make TONS of use cases financially unfeasible. If you were to charge 1 ICP for the ability to create canisters, someone would create service to create canister and switch their ownership to bypass paying the 1 ICP fee. You canât do that on the Apple store or better yet I doubt many would do it cause as an account owner itâd mean a malicious app could get your account terminated and as developer it means fully entrusting your software in the hands of a 3rd party.
Our goal should be to make DX better and lower operational costs as much as possible, not do the opposite.
AWS and Heroku charge monthly and for usage⌠there is a sunk cost to develop using them. Same with Apple but Apple is worse because they do not let you deploy apps without paying it.
hundreds/thousands of canister - what kind of service? It sounds fun
â If you were to charge 1 ICP for the ability to create canisters, someone would create service to create canister
That person would still need to burn a minimal 1 ICP to get Cycles.
â Our goal should be to make DX better and lower operational costs as much as possible, not do the opposite.
Inferior goods demand decrease as income increase⌠so high skill devs all around the world want to work with really cool new shit, that normally has a premium (Apple, AWS, Heroku, ETH, whatever).
The perception of an instant ramen âcryptoâ is the opposite of what we would like. This sounds contradictory but is based in solid economic theory which are also proven by the models of any other developer platform.
I donât see how that would be an improvement, even if it were enforceable. Itâs bad for DX, it doesnât stop bad actors from creating canisters and if ICP token increases in price it will only become a pointless barrier to entry, which is against the whole point of the IC.
You are inadvertently calling the economic models of AWS, Heroku, Apple, ETH, and other successful developer platforms wrong.
There needs to be a minimal cost to reflect its status as a Veblen good. This attracts capable devs rather than dissuading them.
Cool if they need to trade Cycles great. It shows that they have an active interest in developing. Or they could just burn one ICP or whatever the âminimal rateâ is determined to be.
It does stop bad actors as they need to do extra steps or pay a minimum to do âbad thingsâ.
Thank you for your interesting post !
