Sponsor Classic Wallets

This section assumes the reader has a basic understanding of Lumens (XLM), the native token of the Stellar Network. Sponsorship is mainly focused only applications offering non-custodial wallets.

Classic Wallets

Before looking into sponsorship, it's important to first understand reserves and fees on the Stellar Network for Classic Wallets and why they exist.

Skip ahead if you're already familiar with this section.

Base Reserves

The base reserve is an amount of Lumens (currently set to 0.5 XLM), used as a multiplier to calculate the minimum balance. The minimum balance is the amount of XLM necessary to create a wallet or to change a wallet options that require saving data to the network. Think about it as a way to pay for storing data on the network and to avoid spam.

Even if an application's features only use assets other than XLM, having a minimum balance of XLM is still required to operate it. Learn more.

note

The most common base reserves used by accounts are:

• Account creation: 2 base reserves (1 XLM) - learn more about account creation
• Adding trustlines to accept assets (1x base reserve = 0.5 XLM per asset trustline)

Check a full list of account subentries.

Base reserves are temporarily locked on the account. If the data is removed or if the account is deleted (merged into another account), the minimum balance will be unlocked and available for use. More about recovering the reserves is covered later on.

Example: Funding base reserves without sponsorship

Given an account "A" with a balance of 5 XLM willing to fund a Stellar address "B" (not funded).

To fund it, account "A" sends 1XLM to address B (the used operation is Create Account, not Payment).

After completing the transaction, account B is now funded with 1 XLM. Given the requirement of two base reserves, this account has 0 XLM available to use, so it can't add any additional reserves or submit transactions (pay for fees) in its current state.

Without sponsorship, the lumens were actually transferred from account A to account B, so account B has control over them.

Note: This section covers reserves for Classic wallets. Smart wallets work in a different way. To learn more about Smart wallets, see Sponsor Smart Wallets.

Fees

When a Stellar account submits a transaction to the network, it will need to pay a fee to be processed. This is also called "gas" in some networks. This fee in the Stellar Network, although small, helps avoid spam on the network and can be used to prioritize transactions, especially if there's a network surge. The minimum fee on the Network is set to 100 stroops (stoop is the minimum fraction of lumens: 0.0000001 XLM) or 0.00001 XLM.

Applications built on Stellar can define the maximum fee amount they are willing to pay on each transaction to ensure that the submitted transactions will be processed by the network (learn more about fee strategies). The set value is used as a limit, the effective fee paid will depend on the network state at the time of submission. If there's no surge, the fee paid will still be the minimum even though the maximum fee amount was higher.

By default, the fee cost in XLM is deducted from the account submitting the transaction; not having enough Lumens in that account will result in a submission failure. Fee sponsoring (Fee-Bump Transactions) can change this, allowing an wallet developer to pay for fees on behalf of the user, so they don't need to keep an XLM balance in their accounts.

As an example, without using fee sponsoring, sending 1 XLM from an account A to account B deducts 1.00001 XLM from account A since it pays for the minimum fee of 0.00001 XLM + 1XLM sent.

How sponsorship works

note

This guide covers both base reserve and fee sponsorship (fee bump). These are independent features - you can implement either one or both, depending on your application's needs.

Sponsoring base reserves

When sponsoring base reserves, the application will elect to lock Lumens on behalf of the users, so users don't need to hold any lumens. To do this, the application will format a transaction that includes an operation that defines that all the following operations in that same transaction that require reserves will be sponsored by its own account. Then, after defining all the necessary operations, it needs to define another operation that closes the sponsorship. This allows the application to say which operations it wants to sponsor explicitly, and the need to stop sponsoring in the same transaction guarantees that no additional sponsor reserves can be created without the sponsor's consent. If the user decides to change their own account in ways that require additional reserves, these won't be locked on the sponsor's account.

An account sponsorship uses a transaction sandwich of three or more operations in a single transaction:

1. Begin Sponsoring Future Reserves: Initiates the sponsorship. This operation (source = sponsor) designates a sponsored account ID whose future reserve increases will be paid by the sponsor.

2. Include operations that require reserves: Include operations that require reserves, like creating the account, a trustline, etc.

3. End Sponsoring Future Reserves: Ends the sponsorship initiation segment. This operation (source = the new account) lets the new account accept the sponsorship. It must be run by (or on behalf of) the sponsored account and is only valid inside the same transaction after a matching Begin Sponsoring operation.

This transaction that starts with the intent of sponsoring, includes operations and ends with closing sponsorship is called a sandwich transaction, and it may look like this:

After building the sponsoring transaction, it will need the signature of both the sponsor's and the account being sponsored (or any account with enough signing power to do so) before being submitted to the network. This is a requirement so that both parties approve what's being submitted.

An account that sponsors two external accounts may look like this:

Note that the users' accounts don't need to hold any Lumens and that all the reserves were added to the sponsor account. Lumens never left the sponsor account. The sponsor account in the example has 5 locked lumens from:

• Its own account creation (2x base reserve = 1 XLM)
• Creating 2 additional accounts (4x base reserve = 2 XLM)
• Sponsoring 2 trustlines for two accounts (4x base reserve = 2 XLM)

📖 Learn more about transactions and operations in the Stellar documentation.

Check the sponsored reserves documentation

Code example: Sponsoring account creation

import { Server, Keypair, TransactionBuilder, Networks, BASE_FEE, Operation } from "stellar-sdk";

const server = new Server("https://horizon-testnet.stellar.org");

async function createSponsoredAccount() {
  const sponsor = Keypair.fromSecret("<SPONSOR_SECRET>"); // wallet's funding account
  const newUser = Keypair.random(); // user controls this key
  const sponsorAccount = await server.loadAccount(sponsor.publicKey());
  
  // Sandwich pattern: begin sponsorship, create account, end sponsorship
  const tx = new TransactionBuilder(sponsorAccount, { fee: BASE_FEE })
    .addOperation(
      Operation.beginSponsoringFutureReserves({
        sponsoredId: newUser.publicKey(), // designate the account being sponsored
      }),
    )
    .addOperation(
      Operation.createAccount({
        destination: newUser.publicKey(), // user's account
        startingBalance: "0", // no XLM needed from user
      }),
    )
    .addOperation(
      Operation.endSponsoringFutureReserves({
        source: newUser.publicKey(),
      }),
    )
    .setNetworkPassphrase(Networks.TESTNET)
    .setTimeout(180)
    .build();

  // Both sponsor and user sign
  tx.sign(sponsor);
  tx.sign(newUser);
  
  await server.submitTransaction(tx);
}

In the code above, notice how the only additions compared to a normal CreateAccount flow are the two sponsoring operations wrapping around the CreateAccount op. The startingBalance is set to "0" because the base reserve (1 XLM) for the new account will be taken from the sponsor's account instead of requiring the new account to hold it. After submission, the new account exists on the network without the user or sponsor sending it lumens directly – the reserve is sponsored.

The sponsoring account's XLM reserve increases by 1 XLM (locked for this sponsorship), while the new account's minimum balance requirement is satisfied off-chain by the sponsor. As a best practice, the sponsor can later revoke the sponsorship (using a RevokeSponsorship operation) to reclaim that 1 XLM, but only if the new account has acquired enough XLM to cover its own reserves or is going to be deleted.

Code example: Sponsoring Trustlines

import { Server, Keypair, TransactionBuilder, Networks, BASE_FEE, Operation, Asset } from "stellar-sdk";

const server = new Server("https://horizon-testnet.stellar.org");

async function addSponsoredTrustline() {
  const sponsor = Keypair.fromSecret("<SPONSOR_SECRET>"); // wallet funding account
  const user = Keypair.fromSecret("<USER_SECRET>"); // user account
  const asset = new Asset("MYTOKEN", sponsor.publicKey());
  const sponsorAccount = await server.loadAccount(sponsor.publicKey());
  
  // Sandwich: begin sponsorship, change trust, end sponsorship
  const tx = new TransactionBuilder(sponsorAccount, { fee: BASE_FEE })
    .addOperation(
      Operation.beginSponsoringFutureReserves({
        sponsoredId: user.publicKey(), // sponsor reserves for this user
      }),
    )
    .addOperation(
      Operation.changeTrust({
        source: user.publicKey(),
        asset,
        limit: "1000", // optional limit
      }), // user creates the trustline
    )
    .addOperation(
      Operation.endSponsoringFutureReserves({
        source: user.publicKey(), // user accepts sponsorship
      }),
    )
    .setNetworkPassphrase(Networks.TESTNET)
    .setTimeout(120)
    .build();

  // Signatures from both sponsor and user
  tx.sign(sponsor);
  tx.sign(user);
  
  await server.submitTransaction(tx);
}

In this sponsored trustline transaction, the ChangeTrust operation is sandwiched between BeginSponsoringFutureReserves and EndSponsoringFutureReserves. The sponsor's account (S1) is the source for the first operation, and the user's account (A) is the source for both the trustline creation and the end-sponsoring operation. After execution, the asset trustline is established for the user, and the 0.5 XLM reserve for that trustline is taken from the sponsor's account balance instead of the user's. Just like with account creation, the user retains full control over their account and the new trustline, while the sponsor merely locks up some of their XLM to cover the reserve.

Behind the scenes: The Stellar ledger records that the trustline entry is sponsored by the sponsor’s account (it will show a sponsor attribute in Horizon data). The sponsor's minimum balance increases to cover the extra 0.5 XLM reserve on behalf of the user, and the user's minimum balance does not increase for this trustline. In the future, if the user obtains sufficient lumens, the sponsorship can be reversed (using a RevokeSponsorship op) so the user takes over the reserve or the trustline can be removed to release the reserve.

Cancelling or removing sponsorship

To remove sponsorship, the account being sponsored must perform operations that release reserves (e.g., removing trustlines or merging accounts). The sponsor can explicitly revoke sponsorship in a transaction approved by both parties.

Sponsoring base reserves FAQ

Once sponsoring begins, should future operations be reserved by the sponsor?
No, sponsorship only covers explicitly defined operations within the sandwich transaction.

Who holds the sponsorship funds?
Lumens remain locked within the sponsor's account and are never transferred to sponsored accounts.

Can sponsorship be removed from active accounts?
Yes, but only after sponsored accounts clear sponsored reserves or through mutual consent to end sponsorship.

Sponsoring transaction fees (gas)

Transaction fees sponsorship uses "fee bump transactions," allowing sponsors to pay transaction fees on behalf of user accounts. Fee bumps wrap user transactions in a higher-fee transaction paid by the sponsor.

Check the fee bump transactions documentation.

Comparison: With vs. Without Sponsorship

To summarize the differences between traditional flows and sponsored flows in a wallet context:

Aspect	Without Sponsorship	With Sponsorship
Lumens Requirement	Users (or their wallet provider) must provide XLM for new accounts and trustlines upfront	A designated sponsor account provides the lumens for reserves, allowing users to start with zero XLM of their own
Transaction Structure	Standard operations (CreateAccount, ChangeTrust, etc.)	Adds only two extra operations (begin and end sponsorship) around the normal operation. The logic remains the same - essentially a small "wrapper" around existing operations
Signatures and Control	Only the account performing the operation needs to sign	Sponsored transactions require an extra signature (the sponsored account's) to approve the arrangement. The sponsoring account never gains control over the user's account; it only locks some of its XLM as a guarantee
Onboarding UX	Users must acquire XLM before they can create accounts or add trustlines, creating friction for new users	Users can receive their first assets directly as another asset issued on Stellar and transact in those assets, while the wallet application invisibly handles the lumens overhead. This dramatically lowers friction for new users
Recovery of Funds	If a wallet sends lumens to a user, it has no guarantee of retrieving them	The sponsor can remove sponsorship when the user later deposits lumens or no longer needs it. Reserved lumens (1 XLM for an account, 0.5 XLM per trustline, etc.) unlock in the sponsor's available balance once the user covers their own reserves or sponsored entries are removed

Calculating sponsorship costs

There are costs related to sponsoring the user's base reserves or transaction fees. The cost is calculated in Lumens, so the price in any currency, such as USD, will vary. This section will suggest a simple model that you can use to calculate these costs.

Estimate costs

Estimate the average cost of sponsoring for Classic Wallets

Creating a sponsorship infrastructure

The stellar/wallet-backend project provides server-side tooling to make creating and using wallets seamless.

Key Features

• Sponsored Account Creation
  Supports creating accounts and paying reserves on behalf of new users.
• Fee Sponsorship ("Gasless" UX)
  Uses fee-bump transactions so a distribution account pays transaction fees.
• Channel Accounts
  Manages sequence numbers and scales throughput by using pre-funded channel accounts.
• Secure API
  Exposes endpoints for building, signing, and submitting transactions, secured by JWT-based authentication.

Typical Flow

1. Frontend

   • User signs an operation according to their wallet’s logic
   • App sends the signed payload to the backend.

2. Backend (wallet-backend)

   • Builds the transaction using a channel account for sequence numbers.
   • Wraps it in a fee-bump transaction so the distribution account pays the fee (and any reserve if needed).
   • Submits the transaction to Stellar RPC.
   • Polls for confirmation and returns the result.

3. Result

   • User’s wallet action succeeds.
   • User never needed to hold XLM for fees or reserves.
   • Sponsor absorbs costs and can manage them.

Adding funds to the sponsorship account

To fund accounts, you can acquire XLM from a variety of sources including exchanges.

Exchanges

Check a list of exchanges