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

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.

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.

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