Should we increase the minimum fee?

980 views
Skip to first unread message

Justin

unread,
Jul 21, 2020, 10:58:49 AM7/21/20
to Stellar Developers

Hey everyone!

We just put up a blog post to reopen the discussion about raising the minimum fee for Stellar-network transactions. Please read that post, think about it, and leave your feedback on this thread.  

Gleb Pitsevich

unread,
Jul 21, 2020, 11:51:58 AM7/21/20
to Stellar Developers
LOBSTR nodes would support the increase of minimum fee to 10,000 stroops.
At the current XLM price, that translates 0.001 XLM translates to $0.0001, which still seems like a very low fee for a transaction, even though we are talking about 100x fee increase here.

Corey Ballou

unread,
Jul 21, 2020, 1:46:53 PM7/21/20
to Gleb Pitsevich, Stellar Developers
It's a negligible change that, when put into the context of an actual fiat cost, is miniscule. I don't see any issues with 100x as a starting point to gauge how network spammers will react.

--
You received this message because you are subscribed to the Google Groups "Stellar Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stellar-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/1a7aaed9-1fe1-403c-b382-bb44a2b831a5n%40googlegroups.com.


--
Corey Ballou
CTO  TERNO

Orbit Lens

unread,
Jul 21, 2020, 2:17:53 PM7/21/20
to Stellar Developers

Fully agree with the proposal to raise fees. However, 0.001 XLM is still a rather small fee for executing operations on the distributed blockchain. While we'll definitely see a decrease in failed arbitrage transactions on the ledger, it doesn't eliminate all potential problems.

To my mind, we need to set a long-term target in 0.001 USD for the base_fee parameter and increase max_tx_set_size to at least 2000 ops per ledger. And here is why:

First of all, history showed that the price of XLM is highly volatile, so it's very likely that the validators will need to adjust fees relatively often to keep up with the XLM price when it goes up or down. There is no point to start a broad discussion with the community, developers, and all interested parties each time the fee has to be re-adjusted. We can all agree that fees should be nominated in, say, USD or EUR. If the community agrees to set a 0.001 USD target for the base_fee, validators can decide to vote for the fee changes in response to market price actions and coordinate the voting without starting a long process of gathering feedback from all interested parties. Of course, this only applies if the new base_fee is close to the long-term target nominated in USD (or EUR) that was previously approved by the community.

The 0.0001 USD fee (as proposed in SDF blogpost) is too small to prevent resource exhaustion attacks on validators. Currently, the Stellar mainnet can process roughly 17,280,000 operations daily (max 1000 ops per ledger, ~12 ledgers per minute). So if someone decides to flood the network filling all ledgers with meaningless transactions, it will cost only 17,280‬ XLM (≈ 1,700USD at current price). At the same time, validators pay a lot more for processing and storing millions of those meaningless ops. 

So I propose to set at list 10x larger fees to make such an attack much less tempting. The 0.001 USD for transferring money or trading on the DEX is still significantly lower than most other blockchains or centralized solutions can offer at the moment, but it will protect validators and allow them to plan maintenance costs in the long run. The fully synced Stellar Core server requires about 2TB of SSD disk space (it's not feasible to sync the network for a new validator if the server is running on chipper low-cost HDDs – it literally takes months to do it from scratch). We'll have to upgrade our servers in the nearest future as almost no free space left on the SSDs.

And lastly, why increase the limit to 2000 ops per ledger? Not merely to show that we can. It will double the ledger capacity making the network more resilient to sudden transaction outbursts. For example, in cases when many people (and bots) are trying to put or remove DEX offers in the reaction to the anchored tokens price swings. We've seen this on Ethereum – smart contracts simply can't submit a transaction to change the price or liquidate the margin/borrowing position when the Ethereum network is under heavy load. It's one of the biggest problems for DeFi apps. Also, we know that Stellar can handle a much larger load. The limit was reduced from 5000 to 1000 ops when validators voted for protocol v11, which changed how the max_tx_set_size logic works. To my mind, a gradual increase of the network capacity (for instance, doubling max_tx_set_size twice a year) will allow us to reach the throughput comparable to Visa or Swift – is one of the most obvious requirements for achieving ultimate Stellar goals. At the same time, it allows validators to test and adjust their hardware with each max_tx_set_size upgrade without risking the entire network downtime.

Therefore, my proposal is to use 0.001 USD as a long-term base_fee target, which means that we need to vote for setting base_fee to 0.01 XLM and increase max_tx_set_size to 2000 ops per ledger.


On Tuesday, July 21, 2020 at 5:58:49 PM UTC+3 Justin wrote:

Shaun Burrow

unread,
Jul 21, 2020, 3:22:43 PM7/21/20
to Stellar Developers
Our team at DEMARS will 100% support this decision. We've lost so much money to the malicious path payment bots, whilst trying to make markets for fiat to fiat remittances. Anything to deter malicious behaviour has our full support. Hopefully the current validators will support it, but if not, happy to spin something up and vote.

Marcin Olszowy // COINQVEST

unread,
Jul 22, 2020, 8:46:24 AM7/22/20
to stell...@googlegroups.com
Hey! We're fine with increasing the fee. (COINQVEST validators)

Thanks


On 7/21/20 5:58 PM, 'Justin' via Stellar Developers wrote:

Hey everyone!

We just put up a blog post to reopen the discussion about raising the minimum fee for Stellar-network transactions. Please read that post, think about it, and leave your feedback on this thread.  

--
You received this message because you are subscribed to the Google Groups "Stellar Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stellar-dev...@googlegroups.com.

Ollie Brown

unread,
Jul 22, 2020, 3:54:31 PM7/22/20
to Stellar Developers
Hey everyone!

To provide a different viewpoint, 100x fees becomes a significant amount for platforms who pay for all their users' transactions.

We will be using smart contracts and micropayments for a variety of features, and with a large userbase in the future, 100x transaction fees could cost us $10-20k per year.

I think a 10x increase is a good idea if it will solve genuine issues. Whilst 1000x is nothing for the individual making a couple of payments every week, it makes many previously frictionless models unfeasible without making users all pay their own fees (a major friction).

It seems like a mistake to suddenly increase fees too much if there is no urgent need. At the moment, low fees and fast payments are what differentiates Stellar from the rest.

Thanks :)

Drew Palmer / Marscoin

unread,
Jul 22, 2020, 3:54:35 PM7/22/20
to Stellar Developers

We’re fine with 10,000 stroops at the current price of $0.10/XLM.


Even at $1.00/XLM that is still incredibly low for financial transactions, but is cost-prohibitive for “stamping” transactions, such as charging for each email, since revenue for those types of micro-transactions tops out at around $1.00 CPM (.001 USD/tx).


An interim raise to 1,000 stroops for now would give validators some relief and disincentive some pigeons, while leaving room for increased valuation of XLM and use of Stellar network for micro-transactions.


However, if the long-term focus for XLM is going to be on financial transactions, then perhaps the trajectory should be towards a .01 USD/ $10CPM - still awesomely low even for sub 1USD/EUR/100Yen transactions  — but impossibly high for “stamping” transactions like email.

Ozal Mehmeti

unread,
Jul 22, 2020, 4:44:31 PM7/22/20
to Ollie Brown, Stellar Developers
Hi Everyone,

I totally agree with Ollie. We are on the same situation where we are paying for user transactions. Also we are paying for user accounts as well. The reason for this is easier to adapt for users where they directly register and start to use their wallets ( they dont have to buy xlm or anything ) they do it smoothly.

So very big increase will make our types of businesses harder to function.



Tim Read

unread,
Jul 22, 2020, 5:28:15 PM7/22/20
to Stellar Developers
Blockdaemon would support the increase of minimum fee to 10,000 stroops as well. 

Corey Ballou

unread,
Jul 22, 2020, 6:40:05 PM7/22/20
to Tim Read, Stellar Developers
I want everyone to keep in mind that you’re already paying higher fees per transaction simply due to surge pricing with or without this change. The network has been relatively congested.

We’ve internally had our maximum palpable surge fee hard coded far in excess this proposal without batting an eye.

--
You received this message because you are subscribed to the Google Groups "Stellar Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stellar-dev...@googlegroups.com.

Anthony BARKER

unread,
Jul 23, 2020, 9:32:43 AM7/23/20
to Stellar Developers
Agree with Corey - we could just do nothing and the fees will go up automatically. Also this allows for cheaper payments when the network is not busy.

From a marketing perspective makes the base fee 50 times more expensive than Ripple.

0.00001 XRP  = 0.000002 USD
0.001 XLM = 0.000100 USD

gbubemi agbeyegbe

unread,
Jul 23, 2020, 6:06:11 PM7/23/20
to Stellar Developers
Wouldn't a fee of  0.001 XLM make it expensive for market makers maintaining trading pair on the DEX?
Say you have to synchronize your prices every minute for 5 levels on both sides. 
If a understand correctly, that comes to 0.01 XLM per minute/pair
Seems to me that could add up

Bot401

unread,
Jul 24, 2020, 5:53:40 AM7/24/20
to Stellar Developers
A little bit of background. I run a medium sized market making and arbitrage type of bots operation
on top of Stellar - talking about 100 000 - 200 000 trades in half a year and tens / hundreds millions operations updating the bots
to match constantly changing market prices. Although I focus a lot more on market making side of things.

While I do agree that path payment arbitrage and failed transactions are polluting
the blockchain, there's also a counter argument to be made. On one side arbitrage path payments are an efficient way to match
orders inside the dex. Orders that would otherwise stay passive, which creates volume and make markets stay a little
bit more alive. These arbitrage payments level out inefficient price differences between markets and keep the dex constantly
evolving towards market equilibrium. 

On the other side, path payments are taxating and heavy feature to keep alive
and maintain from protocol's perspective - these "pigeon like" racing conditions are real and true when arbitrage botters
are competing to be first to match the profitable path of offers. Current protocol allows for basically zero risk opportunity
for small profit - negligible risk coming from minuscule fees which you can ignore when path payment fails.

But, when I flip my mind and gaze the view as a market maker, things turn on the other direction. Raising fees could at worse inactivate
the dex and turn market making for small volume pairs not profitable, which could lead towards empty order books.
I think that we can all agree that more liquidity there is on the dex, the better. A simple way to depict this problem is
with a small calculation. Say there is an asset pair and market maker wants to update prices every second ledger: With
proposed fee structure and 5s ledger close time

12 * 60 * 24 * 365 = 6,307,200 * 2 (one offer per side) = 12,614,400 * 0.001 = 12.614.4 XLM / year

12614.4 / 12 = 1051.2 * 0.095 = 99.86$ per month to keep two offers updated ~ every ten second on the ledger. To be fair this may be
an excessive amount of price updates, and certainly is for small and passive pairs, but when you scale that calculation to 5 offers per
side and take in the consideration that some anchors need to mirror prices from APIs outside the dex, otherwise they create arbitrage opportunities,
you can easily see that this would drastically change the dynamics of market making and aliveness of the order books in the dex.

I'm not necessarily saying that this fee hike is bad thing, but it changes the game under we all live, this is not an easy
decision and my question in the end is: Should all operations be equally priced? In my mind path payment for example is
way more expensive operation from protocols perspective than manage buy/sell offer. This all boils down to what do we want
to incentivize, some operations create more value for all users and some just use the network as a resource. 

Bot401

unread,
Jul 24, 2020, 7:51:39 AM7/24/20
to Stellar Developers
Edit: Correct calculation for given example: 6 * 60 * 24 * 365 = 3,153,600 * 2 (one offer per side) = 6,307,200 * 0.001 = 6,307.2 XLM / year
6307.2 / 12 = 525.6 * 0.095 = 49,93$ per month

Corey Ballou

unread,
Jul 24, 2020, 8:14:55 AM7/24/20
to Bot401, Stellar Developers
Bot401 brings up an interesting point on the importance of market makers (as opposed to arbitrageurs).

The former (on most larger exchanges) tend to have a paid account and agreement in place with the exchange to operate a special account for zero fee trading to ensure a sufficient liquidity pool exists. This is positive for markets because it provides necessary liquidity which is something the DEX desperately needs. We don't want to scare market makers away. Even arbitrage has its place for equalizing markets.

In a nutshell, is there perhaps a slightly adjusted fee solution to disincentivize the wrong network behavior? 

I believe some stats on which activities are attributing to network congestion would be good for this group to digest. If path payments are the true source of issues on the network,  then the suggestion of increasing fees on path payments only (i.e. base_fee * path_fee_factor or base_fee * path_depth) may be intriguing. 

Matt Walker

unread,
Jul 24, 2020, 11:35:08 AM7/24/20
to Stellar Developers
From the blog post " Because those transactions met the minimum fee requirement, they fail after they’re included in the ledger rather than before, "
How difficult would it be to not include the failed transactions in the ledger? It seems this is the core problem. 

Nicolas Barry

unread,
Jul 30, 2020, 10:22:49 PM7/30/20
to Matt Walker, Stellar Developers
> How difficult would it be to not include the failed transactions in the ledger? It seems this is the core problem

There is no good solution for this right now. The issue is that what happens before consensus and what happens after consensus are order sensitive so the improvement is marginal.
Also, if validators have to perform the work outside of consensus, then fees don't protect them from bad actors.

I think that a medium term solution will be to change some of the semantics so that updating offers (without taking) is cheaper than taking - but building that solution will take some time. In the short term, the only thing we can do is raise fees.

Nicolas


Drew Palmer / Marscoin

unread,
Jul 31, 2020, 2:43:08 PM7/31/20
to Stellar Developers
Given the responses above, I am going to update/revise my previous post and go along with a 100x increase to 10,000 stroops.

For the Marscoin ecosystem where we are using Stellar as the transaction infrastructure (and yes, for those who remember our aggressive plans from August 2019, I know we are a year late on deployment, but our compliance concerns are largely resolved, and the apps are being rebuilt for a February release) we will use 10K stroops at a possible USD 1.00 XLM price ($1/thousand transactions) in long-term projections for transaction fees. A $1CPM expense for tx fees makes a whole lot of micro-transactions economically unfeasible, so those will either have to be off-chain or we will have to raise our prices if XLM appreciates significantly from the current $.10 level, since our financial pro formas currently are based on being profitable at a minimum $1CPM for revenue, so obviously can't budget 100% of that for transaction fees.

If the 10K stroop minimum is adopted, hopefully this will be the last change forever (or at least for years and years) since the more business models that are developed and deployed the more difficult it will be to change such a fundamental cost determinate as stroop transaction costs, for application builders, validators, and market makers alike.

xming980

unread,
Aug 3, 2020, 6:44:08 AM8/3/20
to Stellar Developers
Seems like the people voting for fee increase have not really thought about market making. It actually explains a lot about the sad state of liquidity on Stellar's DEX. Frequent offer updates is basically required to keep a low spread for tracked assets. Otherwise we get 4% spread assets like xcm's BTC and ETH that no one uses. A general fee increase will punish Stellar's liquidity providers at a time when Ethereum's defi apps are actively rewarding them and getting record usage. This will turn Stellar's DEX into an even bigger ghost town.

Marcin Olszowy // COINQVEST

unread,
Aug 13, 2020, 11:00:27 AM8/13/20
to stell...@googlegroups.com
Could we eventually introduced tiered operation fees? Low create_offer_op fees to incentivize market makers, higher fees for path payments et al.?

Drew Palmer / Marscoin

unread,
Aug 16, 2020, 10:55:30 AM8/16/20
to Stellar Developers
Just my two stroops, but I hate the "eventually" idea and would strongly suggest and prefer that any fundamental changes to protocols be sooner than later so that business models can be built, defended and hopefully prosper.

I don't see how a two-tiered system for transaction fees would work, though am happy to be told I'm an idiot I am mistaken. 

Jem

unread,
Aug 16, 2020, 6:27:38 PM8/16/20
to Drew Palmer / Marscoin, Stellar Developers
Are most arbitrage path payments cyclical? What would be the effect on the pigeon problem is we disallowed asset paths that start and terminate with the same asset?

Arbitrage is not the intended use for path payments, I assume. Perhaps if we refine how it works it will become less appealing for such a noisy use case.


--
You received this message because you are subscribed to the Google Groups "Stellar Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stellar-dev...@googlegroups.com.

Tomer Weller

unread,
Aug 16, 2020, 7:18:58 PM8/16/20
to Jem, Drew Palmer / Marscoin, Stellar Developers
This discussion is drifting a bit. 

Changing the semantics of existing operations and/or introducing tiered pricing are *protocol changes*. They require a thorough discussion, code changes, a new release and, mostly, a good chunk of time. If you want a protocol change - submit a CAP :) 

Changing the minimum operation fee is a *configuration change*. It can be done fast and later tweaked if need be.

I agree with Bot401 that the upper limit on fees should be one that allows market makers to continue their operations without costing an excessive amount of money. However, I don't agree that $50 is excessive. I'd be comfortable with that number being up to $100s for very volatile markets. 


   

Orbit Lens

unread,
Aug 24, 2020, 4:07:57 PM8/24/20
to Stellar Developers

It looks like this whole discussion comes down to a question about how people (or rather organizations) are using the network – a payment platform or general-purpose storage. 


It's a bit weird to read that some business models are not sustainable with transaction fees as low as 0.001 XLM. In most cases, it's even cheaper than storing data on your own servers, given that you need to pay for at least two servers (a minimal fail-safe cluster), system administrators to maintain them, and developers. Furthermore, what's the plan in case of surge pricing? Temporarily turn off the service each time fees go higher due to increased on-chain activity? What if surge pricing will be in action for a few weeks? History showed that Ethereum projects that couldn't afford to pay competitive gas prices ended up in oblivion. Speaking of, people doing arbitrage trading and liquidity mining on Ethereum were ready to pay dozens of dollars in fees per transaction right now due to network congestion. So the assumption that rising fees will drive off the liquidity and market makers from Stellar DEX looks very unlikely. Especially given that after the rise, they still will be like 1000x lower than Ethereum fees.


Business models built on the assumption that the storage is free (or almost free) can't be successful in the long run. Currently, all expenses are shifted to validators – they pay for the storage. The imbalance of the validator servers maintenance cost and network fees provide an opportunity for all kinds of inept project ideas. For example, I remember someone planned to create a decentralized Twitter on Stellar, storing tweets in transaction memos. Awfully inefficient, but feasible due to negligible fees. As I see it, the base fee should be large enough to prevent devs from building Stellar apps and monetization models that rely on super-cheap transactions. This also falls in line with the primary Stellar mission – to create a universal global payment network.


We all know that the ledger size keeps growing almost exponentially. Consequently, the Horzion database grows significantly larger over time. Currently, it doesn't look like a huge problem, but let's look a bit deeper. We need to understand that in a year or two, the DB will be so large that it will require expensive hardware. The cost of storing this tx in the fully ingested database will double or even triple every year due to the rising hardware requirements. Paying 20-40K USD monthly for a Horizon server hosting in a few years might result in a more centralized network, with only a few large players that can afford it.


Even now, the Horizon server has difficulties running some queries due to the massive DB and indexes. This results in timeouts when fetching payments. And it's only the beginning. When the size of the database doubles, it may result in the exponential growth of response time on complex queries since the DB engine requires more time to process each index participating in the query, then build results intersection, and fetch the data. But here is a more subtle and somewhat counterintuitive example of sudden performance degradation. Once the most frequently used indexes no longer fit in the server RAM, the overall performance of queries that rely on those indexes may drop by two orders of magnitude as the DB engine struggles to load parts of indexes from disk, perform a scan, clean up memory, and then reload another portion of the index for the new query.


Yes, SDF and community developers are conducting research on sidechains, sharding, and other scaling approaches. Maybe this problem will be completely irrelevant next year. But the data stored on Stellar pubnet right now will be there forever even after the sharding (or whatever will be the solution) is deployed. We have technical problems with processing those large volumes of economically meaningless transactions right now. What's the point of super cheap arbitrage or data storage if retrieving historical data from the ledger becomes a problem?


Ultra-cheap Stellar transactions is not a feature; it's a delayed bomb. The only reason why the fees are so low, is that there wasn't much of an on-chain activity in the beginning. Ledgers were mostly empty, so there was no need to adjust fees. Our community was ready to increase base_fee more than two years ago (there was an extensive discussion on Slack back then), but we couldn't do this as pre-signed smart contracts would be stuck forever. Now, with CAP-15 implemented, we can finally raise the base fee amount without messing up old smart contracts.


To sum it up, increasing the base fee to 0.001 USD will ensure that projects developing on Stellar right now will start planning their on-chain activities more wisely. If we can keep the ledger relatively clean for now by enforcing a bit higher fees, there is a fair chance that maintenance expenses won't rise exponentially as they will be partially compensated by the hardware evolution – disk space and memory gets cheaper every year. The higher base_fee is not a whim – it's an investment into a sustainable future of Stellar Network. And, frankly, it's a really small price to pay considering the fee statistics of most other blockchains.



On Tue, Jul 21, 2020 at 5:58 PM 'Justin' via Stellar Developers <stell...@googlegroups.com> wrote:

Hey everyone!

We just put up a blog post to reopen the discussion about raising the minimum fee for Stellar-network transactions. Please read that post, think about it, and leave your feedback on this thread.  

--
You received this message because you are subscribed to the Google Groups "Stellar Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stellar-dev...@googlegroups.com.
Message has been deleted

Drew Palmer / Marscoin

unread,
Mar 19, 2021, 8:27:59 AMMar 19
to Stellar Developers
We are okay with increasing minimum fee

On Thursday, March 18, 2021 at 12:58:29 PM UTC-4 razticks...@gmail.com wrote:
A group of us on Stellar Global would increasing the minimum fee. Also, we would like to see this conversation re-opened. There seemed to be a large amount of consensus building around raising the fee, but the conversation stalled. Can we get this conversation rolling again?

Thanks!

Raztick Stormwind

unread,
Mar 19, 2021, 8:28:11 AMMar 19
to Stellar Developers
Hi all. I deleted my post from last night and am posting fresh since there was some confusion. Stellar Global is not making an official position on anything here and I do not speak for Stellar Global in any way. Some people who met there, but are not officially associated, have been discussing this thread about increasing the minimum fee and why it seemed to stall. I suggested that we should just ask for the topic to be reopened and make our support for the minimum fee increase known.

There appears to be a lot of support for the fee increase in this thread. LOBSTR, Orbit Lens, and others. The blog post in the original post above asked people to "Join the discussion." That's what I'm doing. The SDF blog post is compelling and the arguments in favor of the fee increase are compelling.

Drew Palmer / Marscoin

unread,
Mar 19, 2021, 11:59:42 AMMar 19
to Stellar Developers
@Orbit-lens you summed it up perfectly.

We were guilty of thinking it as free backup as a side benefit but I want Marscoin built on Stellar to be around for decades at least and centuries would be awesome.

That's not going to happen the way the fees are structured right now.

Orbit Lens

unread,
Jul 5, 2021, 7:55:54 PMJul 5
to Stellar Developers
Just to reiterate. This thread will be interesting to node maintainers: https://www.reddit.com/r/Stellar/comments/ocwxse/upload_files_to_the_stellar_blockchain_for_less/

Someone created an app to store arbitrary files on Stellar mainnet. Like, mp3, or images. Using data entries. Awfully inefficient but still dirt cheap. ~25K operations per an average mp3 file stored on the ledger forever, just to upload some junk for fun. Do we need any other evidences that the base fee increase should be done ASAP?

xming980

unread,
Jul 8, 2021, 9:49:29 PMJul 8
to Stellar Developers
An unconditional fee increase may not affect apps like block explorers but it will be detrimental to the liquidity of the DEX. Stellar's central limit orderbook optimizations are very unique and the ability to update limit offers cheaply is something that only Stellar and Solana can do. As soon as it becomes costly for market makers to maintain operate the DEX liquidity will dry up. Stellar will also lose one of the few advantages it has over Ethereum and its army of lookalikes (BSC, Avalanche, Near, etc..).

A fee increase that negatively impacts liquidity should be balanced by another change that improves it- for example to have the order taker to pay the fee to the maker.
Reply all
Reply to author
Forward
0 new messages