How to sell TDGOLD and get your reserve back

The steps in the guide to buying TDGOLD on the same order book run in reverse here, with one asymmetry. Buying needed a trustline first, because Stellar refuses a payment of an asset the receiver never opted into. Selling needs nothing new: the TDGOLD line already exists, and XLM requires none because it is the native asset.

The reserve is the other half of that. Selling the position does not release the 0.5 XLM your trustline locked. Only removing the trustline does, and that is a separate operation you have to submit yourself.

Stellar has no market order operation. The order book takes manageSellOffer, manageBuyOffer and createPassiveSellOffer, and conversions take the two path payment variants, so whatever a client labels a market sell is assembled from those. An offer priced to cross takes the resting bids in price order until your amount is filled, which on a thin book is how a sale ends at an average price nobody quoted.

Depth is public, so this is measurable before you sign anything, and the same book is read by every wallet and explorer. A resting offer costs 0.5 XLM of reserve for as long as it sits there, because an offer is a subentry exactly like a trustline. Offer prices are stored on the ledger as a fraction of two 32-bit integers, so the price echoed back to you may be the nearest representable ratio rather than the decimal you typed.

Stellar also has automated market makers in the protocol, and a swap can route through a pool rather than the order book, or through both in one operation. A pool charges a fixed 30 basis points, published by Horizon as fee_bp, and prices along a constant product curve: the larger your sale relative to the pool reserves, the worse the average price, and not linearly so.

Trading against a pool needs no pool share trustline. That trustline exists only for depositing liquidity, and consumes account reserve of its own. Selling through a pool is an ordinary path payment.

Whether a pool holding TDGOLD exists at any given moment is answered by Horizon, not by this page. Seeding one sits in the liquidity phase of the published roadmap, so check the ledger rather than assuming the route is there.

A path payment converts on the way. You name the asset leaving your account, the asset the destination should receive, and the network finds a route through order books and liquidity pools. The destination may be your own account, which converts one asset into another without the funds leaving you.

The two variants differ in which end is fixed. One fixes what leaves you and lets you name the least you will accept; the other fixes what arrives and lets you cap what may leave. Either way the network refuses the whole thing rather than delivering less than you asked for, so a failed swap leaves your tokens exactly where they were.

A service that pools customer funds into one Stellar account identifies you by the memo, not by the deposit address, because the address is the same for everyone. That is the case SEP-29 was written for: a payment sent without the memo, or with the wrong one, still succeeds on the ledger and credits nobody. Stellar has no reversal, so recovery depends entirely on the receiving service.

The type matters as much as the value: a text memo holds at most 28 bytes, an id memo is a 64-bit unsigned integer, and they are not interchangeable. SEP-29 lets an account publish the requirement on chain as a data entry named config.memo_required set to 1, and a wallet that checks for it refuses to submit a memoless payment to that account. Not every wallet checks.

The reserve was never spent, only subtracted from what you were allowed to spend, and removing the trustline stops the subtraction. Your minimum balance is 0.5 XLM multiplied by two plus your subentry count, so dropping one subentry lowers that floor by 0.5 XLM.

The operation is changeTrust with a limit of 0, and the network accepts it only if the new limit still covers what the line holds. In practice that means a balance of exactly zero, down to the seventh decimal place Stellar stores, and no resting offer still buying the asset against that line. Otherwise the wallet refuses the change. Recreating the line later costs the same 0.5 XLM again, so remove it only when you are done with the asset for good.

An issuing account holds no trustline to its own asset and needs none. Tokens paid back to it are not stored there, they stop existing. That is how burning works on Stellar, and the payment succeeds, so no error warns you.

For TDGOLD that is final rather than merely expensive. The issuance procedure ends by setting the issuing account master key weight to zero, after which no signature exists that could reissue what was burned. Sell into the exchange, or pay an account that already holds the trustline, and copy the destination from the wallet you are sending to.

Nothing is withheld at the protocol level. Stellar has no token-level transfer tax, TDGOLD adds none, and a trade costs the network fee of 100 stroops per operation, which is 0.00001 XLM. No statement is produced for you either, because no custodian or broker sits between you and the ledger.

Whether a disposal is taxable where you live, at what rate and against which cost basis, is not something anyone running this site can answer. What we can point at is where the evidence sits: the ledger is public and permanent, and Horizon serves your own history at /accounts/{account_id}/trades and /accounts/{account_id}/payments. Export it while you still remember which addresses were yours, and the questions people ask most often about TDGOLD set out what the asset is and what it is not.