Fee Bump Bug Disclosure and the Impact on the Protocol 20 Upgrade


Stellar Development Foundation

Publishing date



Smart Contracts

Yesterday, as part of the continued ecosystem-wide effort to test Soroban, a bug was discovered in Stellar Core v20.1.0 that could impact applications and services that use fee bumps for Soroban transactions if or when the Mainnet upgrades to Protocol 20.

At this point, we, the ecosystem — and specifically the validators who run nodes that support the network and participate in governance decisions — have a choice: continue with the Protocol 20 upgrade vote on January 30 as planned or delay the vote to wait for a new Stellar Core release that fixes the bug.

Because this is a bug with limited impact that can be mitigated through adherence to best practices, we, the Stellar Development Foundation in our capacity as a validator, have decided we are comfortable continuing with the Protocol 20 upgrade vote on January 30 as planned.

After thinking through the possibilities, we believe the bug poses a low risk through Phases 0 and 1 of the Soroban rollout because the strict limits on Soroban transactions will cap loss and prevent exploits at scale. We also believe that if applications follow best practices — which you can find in the post below — they can protect themselves from potential harm. And so we intend to arm our nodes for the upgrade as planned.


It is up to other validators to make their own decision. If they decide to vote for the upgrade, then the current timeline will hold. If they decide not to, the network will not upgrade January 30, but we will schedule a new vote when a fix is implemented.

Either way, SDF engineers are already working to resolve the bug, and as soon as a new Stellar Core release is available, we are committed to working with the ecosystem to roll it out across the network and fix the problem entirely.

And while ultimately, it's up to validators to review the situation and decide whether to continue with the vote as planned, we — the Stellar Development Foundation, network validators, and the ecosystem as a whole — could all benefit from some conversation about what to do next. If you have questions, suggestions, or opinions, please share them in the #protocol20 channel of the Stellar Dev Discord.

From us, expect transparency: we promise to share any information with you as soon as we can, and to keep you posted as things develop. From you, we ask for participation: please read through the information below and, especially if you run a validator, let us know what you think.

More on the bug and recommended best practices is below.


What is the Soroban fee bump bug?

To be clear: this bug only affects fee bumped Soroban transactions.

Some background: Stellar supports fee bump transactions, which wrap an internal transaction and pay that transaction's fees. It's a feature used to sponsor fees, often by wallets that want to offer a seamless user experience or by entities that submit many transactions to implement a central fee pool.

Soroban’s multidimensional fee design introduces a “refundable” fee component that can be fully or partially refunded to the transaction submitter if it’s not fully utilized, and the bug lives where that refundable component — which again, only exists in Soroban transactions — and fee bumps overlap.

The fee bump bug causes the fee refund, if it exists, to deviate from expected behavior.

  • Expected behavior: refund would be received by the source account of the fee bump transaction, aka the sponsor account.
  • Actual behavior: refund is received by the source account of the original transaction, aka the sponsored account

As a result of the bug:

  • Non-malicious users might end up with a fractional amount of XLM that should be returned to their sponsor.
  • Malicious users might attempt to craft transactions that maximize the amount of refunds they receive.

Below are the recommended best practices to mitigate the risks of the fee bump bug if the upgrade to Protocol 20 continues as planned on January 30th.

Next Steps

Best Practices for Sponsoring Transactions

This section describes best practices for sponsoring transactions, regardless of the existence of this particular bug.

In general, if you use FeeBump transactions in your product or service:

  • Check the content of transactions as much as possible to avoid surprise costs. For example, if you only expect non-Soroban transactions, reject transactions that contain Soroban operations.
  • Only sponsor transactions for your user base, and implement controls to limit the amount sponsored per user and globally.

In order to sponsor Soroban transactions, we recommend building the transaction on the sponsorship service and using the Soroban auth framework. The wallet client should only send an operation or contract invocation arguments, as well as the corresponding signed auth payload(s). The sponsoring service runs preflight using the provided invocation and auth, and then signs the full transaction.

There are also a few additional measures you can take to mitigate any potential risks:

  • Limit the sponsored resources and fees. The simplest rule is to not sign transactions with a fee above some resource limit. More complex rules could enforce limits on certain resources (e.g. no more than 10,000,000 instructions if you only intend to sponsor simple transactions that only involve SAC interactions).
  • Limit the sponsored interactions to a small number of trusted contracts and Wasms. Ideally, introduce an allow-list of the supported sponsored dApps. The validation can be performed based on the ID of the contract specified in the InvokeContractArgs, and then the footprint can be examined to verify that only allow-listed Wasms and additional contracts are being used.
  • Only sponsor InvokeHostFunction operations. Don’t sponsor the TTL extension operations, as these can be expensive and they’re tricky to link to a specific dApp, since arbitrary ledger entries can have their TTL extended.
  • Do not sign the transactions that have Soroban auth entries with SOURCE_ACCOUNT credentials and no operation SOURCE_ACCOUNT(or if the operation's SOURCE_ACCOUNT is the same as the sponsoring source account). This prevents ‘confused deputy’ attacks.

Talk to us


We want to hear from you in the #protocol20 channel of the Stellar Dev Discord:

  • Application developers: does this affect your application, and if so is this mitigation plan sufficient?
  • Validators: signal support or disapproval of the plan to upgrade as planned to Protocol 20

Next steps

What to read next


Protocol 20 Upgrade Guide

Protocol upgrade


Your go-to guide for upgrading to Protocol 20, which introduces support for Soroban smart contracts to Stellar.

Read More


The Stellar Network’s Phased Rollout of Smart Contracts: The Road to Mainnet


Smart contracts


Protocol upgrade

The release of a full suite of software that supports Protocol 20, which will bring Soroban smart contracts to Stellar is available. With the…



Protocol 20: Preparing for Smart Contracts on Stellar

Smart Contracts


Discover the upcoming Protocol 20 upgrade on the Stellar network, introducing Soroban smart contracts. Learn about the development process, impact on…

Learn More