Stellar sponsored reserves separate the account that bears a reserve requirement from the account that owns the supported entry. In CAP-0033’s documented design, a sponsor can provide reserve backing without handing the recipient control of the backing funds. Changing an existing sponsor is a separate process: it targets a particular ledger entry or signer and can fail if the replacement reserve payer cannot support it.
Three questions therefore matter more than the label “sponsored account”: who owns the entry, who bears its reserve requirement, and which account is the source of each operation? Those roles can differ. They also change during a sponsor handoff in a way that is easy to misread if every operation is assumed to act directly on the entry’s owner.
This guide explains the Sponsored Reserve specification written by Jonathan Jove, created on May 18, 2020, and updated on August 13, 2020. Its Final status and protocol-version labels describe the document; they do not establish today’s activation status, reserve parameters or wallet behavior. The examples below explain the recorded design, not observed transactions.
Reserve backing is not a spendable payment
CAP-0033’s motivation starts with an issuer willing to pay the reserve for trustlines to its asset. A trustline is the account-associated entry used in the proposal’s asset examples. The issuer wants to support that entry without making the backing funds freely available to its owner. The important benefit is the separation of reserve responsibility from control of those funds, rather than a promise that every recipient receives native tokens.
The proposal describes why simply transferring native assets creates a different arrangement. In its historical scenario, an attacker creates an account and trustline, waits for the issuer’s funding, removes the trustline and merges the account to extract the funds. This is the author’s motivation for sponsorship, not a report of a particular attack. Sponsorship aims to provide the required backing without reproducing that direct-funding exposure.
Reserve backing should also be separated from paying to execute a transaction. CAP-0033 explicitly contrasts its reserve mechanism with CAP-0015’s transaction-fee mechanism. As a conceptual comparison, our smart-wallet guide explains why transaction-fee sponsorship is a different cost: changing the payer does not eliminate execution cost. That Ethereum background does not establish Stellar’s fee rules, and reserve sponsorship alone should not be read as automatic transaction-fee funding.
Read the counters and the entry’s sponsor separately
The specification records sponsorship in more than one place. Its account extension includes numSponsored, described as the number of reserves sponsored for the account, and numSponsoring, the number sponsored by it. The comments give these counters opposite effects: the first reduces the account’s reserve requirement, while the second increases it. They describe reserve responsibility, not two additional spendable token balances.
A separate ledger-entry extension contains sponsoringID. The entry-level sponsorship descriptor identifies the account sponsoring that entry; an empty descriptor means there is no sponsor. This answers a narrower question than the account counters: not merely whether an account participates in sponsorship, but which sponsor backs the particular entry being examined.
The analytical consequence is that a displayed balance cannot, by itself, identify every reserve payer. Nor does an aggregate count reveal the sponsor of a named trustline. For that question, the entry-specific record matters. This distinction also prevents a misleading account-wide shortcut: different entries belonging to the same account can have different sponsors, as the proposal’s worked example demonstrates.
For background on why interfaces and underlying ledger records answer different questions, see stored account state versus displayed balances. That comparison uses Bitcoin and Ethereum, not Stellar. Its relevance here is limited to reading accounting state carefully; Ethereum’s nonces, gas rules and account authorization should not be imported into this sponsorship design.
Ending an agreement context does not cancel recorded sponsorship
CAP-0033 introduces a temporary relation called sponsoring future reserves. BeginSponsoringFutureReservesOp starts that relation, with the sponsoring account as the operation source. EndSponsoringFutureReservesOp terminates it, with the sponsored account as the operation source. The difference between those sources is part of the mechanism, not an interchangeable naming convention.
The specification’s agreement model requires both operations in a single transaction and says this guarantees agreement by both accounts. Read that as a documented design property, not a complete recipe for constructing signatures. The transaction source, operation sources and applicable authorization still require care; this guide does not reconstruct a full authorization algorithm.
The word “end” is especially easy to overread. It ends the future-reserve relation used around the relevant operations. It does not mean “remove every sponsorship previously recorded for this account.” The proposal separately introduces RevokeSponsorshipOp to modify existing entry and signer sponsorship. Its examples close the temporary relation while leaving the newly created entries sponsored.
A useful way to keep the distinction straight is to ask two separate questions. First, which future-reserve relation applies while an entry is being created or its sponsorship is being changed? Second, which sponsor is recorded for that entry afterward? Closing the first relation is compatible with a continuing answer to the second. Confusing them makes both sponsor changes and sponsor exits harder to interpret.
Backing a signer does not establish control of its key
Signer sponsorship has its own record. CAP-0033 says signerSponsoringIDs corresponds one-to-one with the account’s signers: the sponsor of a particular signer is stored at the corresponding position. An empty value means that signer has no sponsor. This is more specific than an undifferentiated statement that an account’s signers are all financially backed by one party.
The intact beginning of the signer-change semantics also checks that the account exists and that the named signer belongs to its signer list. A missing account or absent signer produces REVOKE_SPONSORSHIP_DOES_NOT_EXIST. Those checks identify the object being addressed. They do not justify filling in the damaged later comparisons or claiming that the available text supplies every authorization condition.
The control distinction follows from what these records describe: a payer associated with a signer’s reserve, not evidence that the signing secret was transferred. A sponsor record alone therefore cannot establish that the sponsor can sign as that signer, recover its credentials or take over the account. Conversely, financial backing is not a substitute for understanding the account’s actual authorization policy.
Our explanation of signing credentials and recovery scope provides general background on that separate subject. It distinguishes a signing secret from recovery material that may cover multiple keys. It does not establish that every Stellar wallet uses a particular mnemonic, derivation method or recovery procedure; those details depend on the actual wallet and account arrangement.
Follow two entries with different sponsors
Consider the proposal’s example of account A creating trustlines X and Y, with S1 backing X and S2 backing Y. These are role labels in a qualitative example, not real accounts. Before creation, calling S1 and S2 prospective sponsors does not establish a completed result. The operations and resulting records are what give the labels meaning.
For X, S1 begins sponsoring future reserves for A. A then performs the trustline-creation operation for X and ends the relation. For Y, S2 begins a separate relation for A, A creates Y, and A ends that relation. The two-trustline example places both sequences in one transaction while keeping their sponsoring contexts distinct.
After successful completion as illustrated, A remains the owner of both trustlines, but their reserve backing differs: X records S1 and Y records S2. Neither sponsor becomes the owner merely by supplying that backing. Equally, the closure of both future-reserve relations does not erase the entry-level sponsorship that the example was designed to create.
This gives a more precise reading task than asking who sponsors A. For X, identify its owner and recorded sponsor; repeat for Y. The answers share an owner but not a sponsor. If a later operation targets only X, Y is not automatically included simply because both entries belong to A. The entry key, not just the owner’s account identifier, determines the target in the following handoff example.
A handoff involves the old sponsor, not just the owner
Now suppose a replacement sponsor, S3, is to take over X’s backing from S1. S3 is a renamed version of the replacement sponsor in CAP-0033’s transfer example; the new label avoids confusing it with S2, which already backs Y. Let K identify X’s ledger entry. This combines the document’s examples for explanation rather than describing an executed transfer.
The sequence has a subtle participant change. S3 begins sponsoring future reserves for S1, the existing sponsor, rather than for owner A. S1 is then the source of the RevokeSponsorshipOp targeting K. Finally, S1 ends the relation begun for it. In this transfer context, the sponsored account is the old sponsor, even though A still owns the targeted trustline.
The documented transfer pattern uses that arrangement to replace sponsorship of the selected entry. The name “revoke” therefore does not always mean that an entry is left without a sponsor: within the illustrated replacement context, it participates in a handoff. The document also states that RevokeSponsorshipOp requires medium threshold, without turning that statement into a universal number of signatures.
If the illustrated transfer succeeds, X’s sponsor changes from S1 to S3. A remains its owner, and Y lies outside this targeted example. Nothing in that role change establishes an asset withdrawal, an account transfer or a change of signing secret. The narrower consequence is a replacement reserve payer for K, subject to the applicable conditions and actual transaction result.
Separate relation errors from entry-change failures
CAP-0033 defines different failure categories for different stages. For beginning a future-reserve relation, the comments identify self-sponsorship, an already-sponsored account and a recursive relation involving an account that is itself sponsoring another. These labels help locate a problem in establishing the temporary relation. They should not be stretched into a complete rulebook for every permanent pattern of entry sponsorship.
Ending has its own failure: END_SPONSORING_FUTURE_RESERVES_NOT_SPONSORED, described as requiring the account to be sponsored to end. At transaction level, txBAD_SPONSORSHIP is described as “sponsorship not ended.” These are different questions from whether the selected existing entry has a valid sponsor or whether a replacement can afford its reserve responsibility.
For an existing sponsorship change, the operation-result definitions distinguish a missing entry, a source that is not its sponsor and insufficient reserve capacity for the new payer. In particular, REVOKE_SPONSORSHIP_LOW_RESERVE means the new reserve payer cannot afford the entry. Willingness to take over is therefore not sufficient evidence that a handoff completed.
The same result definitions flag a special boundary: sponsorship of a claimable balance must be transferred to another account rather than simply removed. That does not provide a general tutorial on claimants or claiming conditions. It establishes that different entry types can constrain the available sponsorship change, so the trustline example should not be generalized indiscriminately.
For the hypothetical X handoff, the practical analytical distinction is between a requested change and a successful result. A failure category does not establish that S3 became X’s sponsor. Verification would require the actual result and recorded state. These definitions alone do not justify additional claims about fee charges, rollback behavior or every reason a production transaction might fail.
A sponsor’s exit has two separate checks
Account merging exposes why temporary relations and continuing obligations must remain separate. CAP-0033 says an account merge fails with ACCOUNT_MERGE_IS_SPONSOR if the account is currently sponsoring future reserves for another account. It gives a second check with the same result when numSponsoring is nonzero. The first concerns the active relation; the second concerns recorded reserve responsibility.
Apply those checks to S1 after X’s creation. Ending the creation context addresses the temporary relation, but does not establish a zero sponsorship count: S1 still backs X in the example. A reader who treats “end” as a complete release would miss the second merge constraint. The account-merge semantics explicitly preserve that bookkeeping distinction.
A successful later transfer of X to S3 changes the obligation associated with X, but does not prove S1 has no other obligations. Likewise, S2’s backing of Y is not settled by a handoff targeting X. Checking whether an account can merge therefore requires more than recognizing one successful transfer; and satisfying these sponsorship checks does not establish that every other merge condition is met.
What the base-reserve caveat does—and does not—say
The proposal’s security section identifies a qualitative trade-off: it says sponsorship will slightly reduce the efficacy of base-reserve changes because sponsored entries cannot cause an account to pass below the reserve requirement. That is the author’s stated concern about the design’s interaction with reserve changes. It is not a measured estimate of network impact or a guarantee against every balance-related failure.
No current reserve amount or numerical stress scenario follows from that sentence. Nor should an exact minimum-balance formula be reconstructed from the incomplete expressions in the available text. The document’s claimable-balance schema discussion also contains a self-replacement statement about sponsoringID; it cannot safely establish a field migration. These limits leave the intact role, record and result distinctions useful without pretending the historical text answers every implementation question.
For a real entry, the decisive evidence is narrower and concrete: identify its owner, inspect its recorded sponsor, distinguish the operation source from both, and check the result of any requested change. For the X example, a completed handoff means evidence that S3 replaced S1 for that entry—not merely a closed future-reserve relation or an unchanged wallet balance.
