Choose a fee sponsorship approach
A new user often has no XLM to pay transaction fees or base reserves. If the user has a contract account, such as a passkey smart wallet, it can't pay its own fees at all: contract accounts can't sign transaction envelopes, so a separate G-account must act as the transaction source.
There are three ways to cover these costs for a user. This guide compares them so you can choose one, or combine them.
Compare the approaches
| Approach | Pays for | Who signs | What you operate | Trust and cost |
|---|---|---|---|---|
| Fee-bump transaction | The fee for a transaction the user already signed | The user signs the inner transaction; the fee account signs the outer envelope | A funded fee account | You pay the fee in XLM, without re-signing the user's transaction. |
| Sponsored reserves | Base reserves for the account itself, trustlines, offers, signers, data entries, and claimable balances | The sponsoring account begins the sponsorship and the sponsored account accepts it, in the same transaction | A funded sponsoring account | The sponsored base reserves (currently 0.5 XLM each) accumulate on your account until the entries are removed. You can revoke or transfer a sponsorship later. |
| Relayer | Transaction fees, including resource fees and rent for smart contract transactions | The user signs only the authorization entries; the relayer signs the transaction as its source account | A relayer and the accounts that pay its fees, or nothing if you use a managed relayer | If you run the relayer, you fund the fees for every transaction it submits; a managed relayer covers fees on its own terms. The user keeps exclusive control over authorizing their funds, but depends on the relayer to submit. |
When to use each
Fee-bump transactions
Use a fee-bump transaction when the user signs their own transaction from a G-account and you want to pay the fee for it. A fee-bump also lets you raise the fee on a transaction that's already signed, for example during surge pricing.
The fee account pays the fee instead of the inner transaction's source account, but the inner transaction still consumes the source account's sequence number. A contract account can't sign the inner transaction, so a fee-bump on its own doesn't cover a contract account's fees.
Learn more in the Fee-bump transactions guide.
Sponsored reserves
Use sponsored reserves when a user's G-account needs base reserves it can't cover. Sponsorship can cover the account's own two base reserves, so you can create the account with a starting balance of 0, and it can cover the subentries the account adds later, such as trustlines and signers.
Both accounts sign the sponsorship transaction, so the user agrees to it. While the sponsorship exists, the reserves accumulate on the sponsoring account instead of the sponsored account.
Smart contract data doesn't require base reserves; it pays rent instead. A contract account is a smart contract, so sponsored reserves don't cover its storage.
Learn more in the Sponsored reserves guide.
Relayers
Use a relayer when the user has a contract account, or when the user holds no XLM to pay fees. The user signs only the authorization entries for their contract call. The relayer rebuilds the transaction with its own G-account as the source account, pays the fees, and submits it. Rent for smart contract storage is part of the resource fee, so the relayer covers it too.
You can run a relayer yourself, in which case you control its signer and fund the accounts that pay the fees, or you can use a managed relayer service.
Learn more about the signing flow in Signing Soroban contract invocations.
For managed fee sponsorship, see the OpenZeppelin Relayer page. This recommendation changes over time; the page linked here stays current.
Combining approaches
These approaches can work together:
- Sponsored reserves and fee-bumps: a wallet that onboards G-accounts can sponsor each account's reserves and fee-bump its transactions. To estimate the XLM you need for account creation, transaction fees, and trustlines, use the Stellar Wallet Sponsorship Calculator.
- Relayers and fee-bumps: a relayer can wrap the transactions it submits in fee-bump transactions, which separates the account that spends the sequence number from the account that pays the fees. A relayer can also use channel accounts to submit transactions in parallel.
Guides in this category:
Create an account
Learn about creating Stellar accounts, keypairs, funding, and account basics.
Send to and receive payments from Contract Accounts
Learn to send payments to and receive payments from Contract Accounts on the Stellar network.
Send and receive payments
Learn to send payments and watch for received payments on the Stellar network.
Channel accounts
Create channel accounts to submit transactions to the network at a high rate.
Signing Soroban contract invocations
Learn two methods to sign Soroban smart contract invocations: full transaction signing for G-accounts and auth-entry signing for G or C-accounts with sponsored fees.
Claimable balances
Split a payment into two parts by creating a claimable balance.
Clawbacks
Use clawbacks to burn a specific amount of a clawback-enabled asset from a trustline or claimable balance.
Choose a fee sponsorship approach
Compare fee-bump transactions, sponsored reserves, and relayers for paying a user's fees and reserves on the Stellar network.
Fee-bump transactions
Use fee-bump transactions to pay for transaction fees on behalf of another account without re-signing the transaction.
Sponsored reserves
Use sponsored reserves to pay for base reserves on behalf of another account.
Path payments
Send a payment where the asset received differs from the asset sent.
Pooled accounts: muxed accounts and memos
Use muxed accounts to differentiate between individual accounts in a pooled account.
Install and deploy a smart contract with code
Install and deploy a smart contract with code.
Invoke a contract function in a transaction using SDKs
Use the Stellar SDK to create, simulate, and assemble a transaction.
simulateTransaction RPC method guide
simulateTransaction examples and tutorials guide.
Submit a transaction to Stellar RPC using the JavaScript SDK
Use a looping mechanism to submit a transaction to the RPC.
Upload WebAssembly (Wasm) bytecode using code
Upload the Wasm of the contract using js-stellar-sdk.