Should we increase the minimum fee?

When you submit a transaction to the Stellar network, you specify a maximum fee you’re willing to pay per operation. If that fee is lower than the network minimum fee — which is a network setting determined by validators, and what we’re proposing to increase — your transaction is invalid, and it fails before it’s submitted to the ledger. That’s an important point, and we’ll return to it below.

Assuming the fee you specify is greater than the network minimum, your transaction becomes a candidate for inclusion in the transaction set validators apply to the ledger. What happens next depends on network activity.

The Stellar network has a capacity — a maximum number of operations that fit in a ledger — and like the minimum network fee, it’s determined by validating nodes. When deciding on ledger capacity, validators attempt to strike a balance: it should be high enough to ensure sufficient network throughput, but low enough to prevent ledger data from becoming unwieldy. There's no financial incentive to run a Stellar node — people run one to improve decentralization and ensure high-availability access to the network — and limiting ledger capacity makes it possible to participate in the network without needing specialized hardware.

Right now, ledger capacity is 1,000 operations/ledger. When network activity is below that, all valid transactions make the ledger and incur the minimum fee. When it’s above that, the network enters surge pricing mode. Since not every transaction can make the ledger, transactions are prioritized based on the fee they specify. The transactions offering the highest fee per operation make the ledger first.

The network has been in surge pricing mode a lot over the past few months. That’s because ledgers are filling up with failed transactions caused by a slew of trading bots attempting to take advantage of a small number of arbitrage opportunities.

Here’s what happens: Stellar has a unique set of operations called path payments, which allow the simultaneous sending and conversion of currency — I send USD; you receive NGN — and they make it incredibly easy to use the network for cross-border and cross-currency transactions.

Path payments convert currency by consuming orders in Stellar’s built-in order books, and sometimes an inefficiency in the order books gives rise to a pricing mismatch. We won’t get into the details here, but savvy developers realized that — every once in a while — you can submit a path payment and end up with a tiny bit more money than you started with, and they built bots to look for those opportunities, and to try to capitalize on them.

The problem is, a lot of people built arbitrage bots, and they all look for the same opportunities. When one comes up, it’s a race: the winning bot submits a transaction that claims the opportunity and succeeds; the remaining bots submit transactions conditioned on the existence of that opportunity, and since it’s no longer available, those transactions fail.

Because those transactions met the minimum fee requirement, they fail after they’re included in the ledger rather than before, so they end up in everyone else’s way. It’s like a passel of pigeons hovering around a park bench: you drop a crumb on the sidewalk, they all dive after it. One pigeon gets the crumb, the rest stay hungry, and while the losers sit there cooing and strutting and wishing for what might have been, they block the sidewalk so pedestrians can’t use it.

Failed arbitrage transactions don’t do anyone any good — they don’t enrich developers; they don’t make the order books more efficient — but, by claiming limited space in the ledger, they do cause problems:

• They force the network into surge pricing mode more often, which makes it harder to predict transaction costs
• They permanently bloat the ledger, which makes it more expensive to run a Stellar Core node or Horizon instance
• They make replaying historical data a lot slower, which makes it more of a hassle for new nodes to join the network
• They slow down ledger close times

We're thinking about ways to limit the amount of failed arbitrage transactions in the long term, but in the short term, a fee raise could mitigate the problem. Right now, the minimum fee is so low that the developers who run arbitrage bots don’t mind paying to submit transactions that will likely fail. By raising the minimum fee, the goal is to make them rethink their actions. It’s worth it to pay 100 stroops/operation to join the pigeon race, but is it worth it to pay 10,000 stroops/operation? At some point, the cost outweighs the benefit, and bot-runners will have to abandon their pursuit or come up with a more efficient — and more considerate — strategy.

Raising the network minimum will also help disincentivize other inconsiderate uses of the ledger: it will cost more to send tiny amounts of XLM with a link in the memo to random Stellar accounts; it will cost more to use the ledger to store arbitrary data. If we set the minimum correctly — which again, may be a process — we can deter bad actors, and ensure that the network as a whole remains effective, efficient, and fair. We’ll drive the pigeons away.

In general, raising the network minimum will have a positive impact on Stellar users. Transactions will still be cheap — fractions of a penny! — so your overall cost will stay very close to zero. Stellar fees will still be lower than those charged by traditional payment systems and most other blockchain networks.

By eliminating the random arbitrage bot activity spikes, raising the minimum should also make it easierto predict transaction fees. Right now, we advise consumer-facing wallets and apps to submit a fee of 100,000 stroops/operation to ensure their transactions don’t get squeezed out by surge pricing, but it’s impossible for them to predict when a crumb will drop and activate the arbitrage bots. If ledger activity is more consistent, it’s easier to reason about — and come up with a plan for — fee management.

Finally, if you run a Stellar Core node or a Horizon instance, increasing the fee will make your life easier. Network data will be leaner, easier to manage, and cheaper to store. Failed transactions are permanent excess baggage, and you’ll have less of them to deal with.

However, if you consistently submit a really high number of transactions, you may notice, and we’d love to hear from you! And if you happen to run one of those arbitrage trading bots, we’d really love to hear from you! In general, we’d love to hear from you. Join the discussion.

The suggestion to raise the minimum fee has come up before, but it wasn’t a real possibility until the recent network upgrade to Protocol 13. The blocker was pre-signed transactions; the solution is fee bumps.

You specify a fee when crafting a transaction, and if you created and signed a transaction a year ago that specified a 100 stroop/operation fee, and you were intending to submit that transaction in 2021, a 10,000 stroop network minimum would prevent you from doing so. Your fee would fall below the minimum, so your transaction would be rejected before it was even submitted to the ledger. For example, imagine you put funds in escrow to buy a house, and agreed to transfer them to the seller at closing: if you could no longer submit the pre-signed transaction, you couldn’t release the funds, the deal would collapse, and you’d wonder why you ever used Stellar in the first place.

We have no idea how many pre-signed transactions exist — they have yet to be submitted to the network, so there’s no record of them to consult — but it’s important to ensure that the network continues to honor valid transactions. Increasing the minimum shouldn’t permanently break things.

By introducing fee bumps, which allow you to increase the fee for a pre-signed transaction, Protocol 13 solved that problem. Now, if you attempt to submit a transaction that specifies a 100 stroop/operation fee and discover the network minimum has increased, you can just bump the fee and resubmit the transaction, no harm, no foul. Fee bumps give validators the flexibility to increase fees to ensure the network stays efficient, and we think it’s time to take advantage of that fact.

Ultimately, the validating nodes on the network decide where to set the minimum fee. But as we mentioned at the top of this post, we want to hear from you before we put this proposal up for a validator vote. Our general plan:

• Listen to and respond to feedback on the Stellar Developers Google Group over the next few weeks
• Make adjustments to our proposal as necessary
• If the ecosystem agrees this is the right move…
• Start coordinating to make sure everyone is prepared
• Schedule a date for a validator vote…
• And see what happens

At this point, the ball’s in your court. What do you think about raising the minimum network fee? Join the conversation.