The open-source network Stellar aims to enhance the financial system by releasing the full potential of the global economy by enhancing money flow, market openness, and individual empowerment. Stellar is a decentralized platform that works well for the efficient and transparent exchange of any kind of currency. Stellar doesn’t privilege any particular currency. It is intended to increase the utility and accessibility of traditional kinds of currency; the money that people have been using to spend and save for ages.
Fees, surge pricing, and fee strategies
To stop ledger spam and give transactions priority during surge pricing, Stellar imposes a modest cost on all transactions. Lumens are used to pay all fees (XLM).
Network fees on Stellar
The base fee for the specific ledger multiplied by the number of operations in the transaction results in the minimum fee for that ledger. (Transaction fee equals the quantity of operations times base fee)
The base fee is what the network levies for each transactional operation. A modified VCG auction is used to calculate the base fee. Currently, the base price for each procedure is 100 troops.
Stroop, or one ten-millionth of a lumen, is the smallest unit of a lumen (.0000001 XLM).
You indicate the most you’re willing to pay for each operation when you enter a base charge price. You will only be charged the minimum amount required for your transaction to be recorded in the ledger, thus this does not necessarily imply that you will pay that sum. You will only be charged the network minimum if there is little network traffic and fewer operations are submitted than the network ledger limit. It is presently 1,000 operations per ledger on the subnet and 100 operations per ledger on the testnet (also configured by validators, currently 100 troops).
Your charge becomes a maximum bid when network traffic reaches the ledger limit, which causes the network to enter surge pricing mode. Depending on network activity, this value may change, however for applications that will be used by consumers, we advise sending a charge of 100,000 troops. It’s up to you, though.
Unless there is a fee-bump transaction that specifies otherwise, fees are deducted from the source account.
Surge pricing
Surge pricing mode is activated when a ledger receives more operations than the network can handle (1,000 operations per ledger on the subnet; 100 operations per ledger on the testnet). The network uses market dynamics at this time to determine which submissions to add to the ledger first; transactions with the highest charge per operation are added first.
The transactions are shuffled at random, and the ones at the top form the ledger if numerous transactions during surge pricing provide the same base cost. The remaining transactions are either moved to the following ledger or, if they have waited too long, are discarded. A timeout error will be returned by Horizon if your transaction is rejected.
Fee strategies
The following are the top three strategies for addressing fee variations and surge pricing:
Method 1:
Choose the maximum fee that you feel comfortable paying. You will only pay what is required to enter the ledger; this does not imply that you will pay that sum on every transaction. Even if you have a greater maximum fee set, you will never pay it under regular (non-surge) conditions. Although this approach is straightforward, practical, and effective, it has the potential to fail.
Method 2:
Utilize the free stats endpoint to monitor changes in fees. Utilize this information to decide precisely and sensibly on the fee you’re willing to pay. You can poll the /fee stats endpoint using any of the three SDF-maintained SDKs: JavaScript, Java, and go. Although more inefficient, this method produces contributions that can be trusted.
Method 3:
Make use of a fee-bump transaction.
