You’re thinking about account to account Sol transactions, for which such a low price is deminimis and even 10x price increase is meaningless. But there is a whole other aspect of the blockchain that involves smart contracts and the price per transaction is the same there too. So to call any function in a particular smart contract will cost at a minimum .000005 Sol, and depending on what other functions that function calls, those calls will also be .000005 Sol. And sometimes you need to make many changes over time and you keep incurring these fees. At current levels, it is mostly painless. But it will start adding up if this goes 10X. In short, the impact I am talking about from increased transaction costs doesn’t affect the “money” side, only the smart contract side. The reason I know this is because I build on chain applications and deal with this on the daily.
The transaction fee isn’t based on the number of cross program invocations or function calls - it’s strictly based on the number of signatures required in the transaction. 1 signature in a transaction = 5000 lamports. The fee is the same no matter how many function calls there are. However, if there are more function calls, then the transaction uses up more compute units, and if it exceeds the default threshold, it will fail. The client is free to specify a higher threshold for compute units on a transaction, but that makes it potentially more costly to a validator, so the transaction is more likely to be dropped or deprioritized. However, the client can add a priority fee to the transaction to increase the chance a validator will process it.
You’re thinking about account to account Sol transactions, for which such a low price is deminimis and even 10x price increase is meaningless. But there is a whole other aspect of the blockchain that involves smart contracts and the price per transaction is the same there too. So to call any function in a particular smart contract will cost at a minimum .000005 Sol, and depending on what other functions that function calls, those calls will also be .000005 Sol. And sometimes you need to make many changes over time and you keep incurring these fees. At current levels, it is mostly painless. But it will start adding up if this goes 10X. In short, the impact I am talking about from increased transaction costs doesn’t affect the “money” side, only the smart contract side. The reason I know this is because I build on chain applications and deal with this on the daily.
The transaction fee isn’t based on the number of cross program invocations or function calls - it’s strictly based on the number of signatures required in the transaction. 1 signature in a transaction = 5000 lamports. The fee is the same no matter how many function calls there are. However, if there are more function calls, then the transaction uses up more compute units, and if it exceeds the default threshold, it will fail. The client is free to specify a higher threshold for compute units on a transaction, but that makes it potentially more costly to a validator, so the transaction is more likely to be dropped or deprioritized. However, the client can add a priority fee to the transaction to increase the chance a validator will process it.