Activate and transact in Freighter without first holding XLM

[adrianvrj]

What problem does your feature solve?

On Stellar, a Freighter user cannot exist or transact until they hold XLM.
Opening an account locks ~1 XLM, each trustline locks 0.5 XLM more, and every operation spends a network fee in XLM. Sending a user to an exchange to buy XLM is a bad UX design.

That cost is small in dollars and large in drop-off:

• A user who was sent USDC (or another held asset) still cannot claim or spend
  it until they acquire a second asset they were not given.
• Freighter’s current unfunded state can only say “add XLM” / Friendbot.
• No on-ramp is designed to sell ~1.5 XLM.

This is not a fee-sponsorship-only problem. Stellar spends XLM as a fee and locks XLM as a reserve. Covering only the fee still leaves the account unable to be created.

What would you like to see?

Let Freighter activate an unfunded account, and later pay classic send/swap fees, using a supported asset the user already holds, without requiring them to acquire XLM first.

Concretely, in the extension:

1. Unfunded account + inbound claimable in an accepted asset: one
   “Activate with {sendMax} {ASSET}” path. One signature creates the account (starting balance 0), opens the trustline, claims the balance, and pays reserves + the network fee from that asset. The button shows the quoted ceiling, not the waiting balance.
2. Classic send / swap when spendable XLM is 0: an optional fee-assetpicker for accepted balances. Existing XLM-fee paths stay as they are.
3. The user always sees sendMax before signing. If the route moves past that ceiling, the transaction fails and nothing is taken. Opt-in and conditional: the token path only appears when Reserve accepts the network and a supported asset is actually available. Funded accounts with enough XLM should look and behave exactly as they do today.

Integration details (for product review)

This would use Cavos Reserve, a hosted Stellar sponsor we operate
(docs, SDK @cavos/reserve).

What it sponsors	Base reserves (CAP-33) and the network fee (CAP-15 fee-bump)
How the user pays	PathPaymentStrictReceive in the same inner tx: token → exact XLM owed to the sponsor. Rate is the SDEX/pool route, not an oracle
Networks	Testnet and mainnet hosted endpoints. No API key required
Accepted assets	Allowlisted, liquidity-verified issuers only (XLM, Circle USDC, EURC, PYUSD, USDT0, AQUA, …). A code without its issuer is rejected
Keys	Reserve never holds a user key and never adds itself as a signer. It signs only the outer fee-bump. SetOptions / signers / thresholds are not expressible in the request
Wallet check	Freighter re-derives the server-built transaction from the request it made and compares XDR before prompting (ops, sponsorship sandwich, fee destination, destAmount, sendMax, path hops)
Scope in this proposal	Classic G… accounts. Not Soroban, not dApp signTransaction inference

We maintain the SDK and the service, and we can change either if Freighter needs a different trust, allowlist, or operational boundary.

Happy to join a product review or adjust the integration before any code review of #3001.

[aristidesstaffieri]

@adrianvrj thanks again for your work on this issue. Transparently, it's too early to commit to a solution without first having explored the problem space sufficiently and considered alternatives. This is definitely an issue we're interested in but we should first spend some time getting more involvement from stakeholders to understand the constraints.

Initially, I don't think No on-ramp is designed to sell ~1.5 XLM. is true as you can buy small amounts of lumens through several venues and we are currently considering how to expand our on-ramp options.

Also, since you have to establish trustlines to assets, in practice I think an address that has been created by adding reserves tends to have more than the minimum, where the cost is not huge. Assuming the user does have an asset that they can pay fees with if it was allowed, I'm not sure that the friction to swap to lumens and pay the fee is much higher than paying another account to pay your fee. If it is, then wallets could also implement a swap-then-submit flow to smooth this out.

As far as the service, I think it's possible that a fee payer could also be a standalone contract on the network, which may bring less dependence risk to wallets using it.

[adrianvrj]

Hi @aristidesstaffieri, thanks for this. Totally get it!

The plan on our side is to develop this, get it audited, and open it as a public good so any wallet or operator can run their own copy. The hosted endpoint is just a default. Someone still has to sign the outer envelope with a classic account. It doesn't have to be us. We are designing the sdk to be like this, anyone could change the origin of the endpoints so they do not have to relay on a single operator.

Where this actually helps is people who only want to get paid. That's a lot of Freighter users. Someone sends them USDC (or another asset they already use) and the address isn't even on the network yet. Right now they have to leave the wallet and buy XLM before they can claim money that is already theirs or receive a payment. On-ramps and swap-then-submit both need an account that can already transact. This doesn't: one signature creates the account, opens the trustline, claims the balance, and pays the reserves and the fee out of what just arrived.

I understand this may not be a priority for a Freighter user but for an embedded wallet it makes more sense since the objective of embedding the wallet is disappearing the wallet itself for non crypto native users, either they sponsor their users (which at scale ends up being a linear cost) or they have to send their users to an exchange, making the embedded wallet have no sense.

We're around if you want us in that conversation when you pull more people in, including those other options for accounts that already exist.

Kind regards!

[aristidesstaffieri]

Hi @aristidesstaffieri, thanks for this. Totally get it!

The plan on our side is to develop this, get it audited, and open it as a public good so any wallet or operator can run their own copy. The hosted endpoint is just a default. Someone still has to sign the outer envelope with a classic account. It doesn't have to be us. We are designing the sdk to be like this, anyone could change the origin of the endpoints so they do not have to relay on a single operator.

Where this actually helps is people who only want to get paid. That's a lot of Freighter users. Someone sends them USDC (or another asset they already use) and the address isn't even on the network yet. Right now they have to leave the wallet and buy XLM before they can claim money that is already theirs or receive a payment. On-ramps and swap-then-submit both need an account that can already transact. This doesn't: one signature creates the account, opens the trustline, claims the balance, and pays the reserves and the fee out of what just arrived.

I understand this may not be a priority for a Freighter user but for an embedded wallet it makes more sense since the objective of embedding the wallet is disappearing the wallet itself for non crypto native users, either they sponsor their users (which at scale ends up being a linear cost) or they have to send their users to an exchange, making the embedded wallet have no sense.

We're around if you want us in that conversation when you pull more people in, including those other options for accounts that already exist.

Kind regards!

I definitely agree that other kinds of wallets, like embedded wallets, could have a different use case and maybe more of a need for this kind of service. I'm not sure if the user story of receiving assets before your account is funded is common for our user base so I definitely want to keep this open to hear from others. Thanks for all of the details here and we will of course reach out if this becomes a more obvious need in order to learn more about your solution.