Stellar’s sponsored-reserve design lets one account cover another account’s reserve requirement without handing over the backing funds. But the word “sponsored” hides three separate questions: who owns the ledger entry, who bears its reserve requirement, and which account signs each operation. The answers can differ, and they shift during a sponsor handoff.
Where the design comes from
The rules come from the Stellar protocol’s Sponsored Reserve proposal, CAP-0033, written by Jonathan Jove and marked Final. Its motivating case is an issuer that wants to pay the reserve for trustlines to its own asset. Before sponsorship, the reserve had to sit inside the account’s balance, so the issuer could fund it only by sending native tokens. An attacker could create an account and a trustline, wait for the tokens, then remove the trustline and merge the account to extract the money. Sponsorship removes that exposure by separating reserve responsibility from control of the funds.
Two records, two questions
The protocol stores sponsorship in two places. An account extension carries two counters: numSponsored, the reserves sponsored for the account, which lowers its reserve requirement, and numSponsoring, the reserves it sponsors, which raises it. These counters track reserve bookkeeping, not two extra spendable balances. A separate ledger-entry field, sponsoringID, names the sponsor of one specific entry; an empty value means no sponsor. One account can own several entries backed by different sponsors, so an aggregate count will not tell you which sponsor backs which trustline.
The relation versus the result
Sponsorship begins through a short-lived relation. BeginSponsoringFutureReservesOp opens it, with the sponsoring account as the operation source; EndSponsoringFutureReservesOp closes it, with the sponsored account as the source. Both operations must sit in the same transaction. “End” is easy to overread: it ends the temporary relation, not every sponsorship already recorded on the account. RevokeSponsorshipOp is the operation that actually adds, changes, or removes sponsorship on an existing entry or signer.
How a handoff moves the payer
Consider a sponsor transfer in the proposal’s example. A new sponsor S3 takes over an entry X backed by S1. S3 begins sponsoring future reserves for S1, the old sponsor, not for the entry’s owner. S1 is then the source of the RevokeSponsorshipOp targeting X, and S1 ends the relation. The entry’s owner never changes; only the reserve payer does. A result like REVOKE_SPONSORSHIP_LOW_RESERVE means the replacement cannot afford the entry, so agreeing to take over does not prove the handoff completed.
What the records do not grant
A sponsor record on a signer ties a payer to a reserve, not control of the signing key. Claimable-balance sponsorship can only be transferred, never removed outright. An account cannot merge while it is sponsoring future reserves or while its numSponsoring count is still nonzero, two checks a casual “end” does not satisfy. The proposal itself flags a trade-off: sponsorship slightly weakens base-reserve changes, because sponsored entries cannot push an account below its reserve floor. For any entry, the safe read is to identify the owner, inspect the recorded sponsor, and keep the operation source separate from both.
Adapted from Stellar Reserve Sponsorship: Who Bears the Reserve and How Sponsorship Changes.