Destinations and the mediator

The recovered XLM has to go somewhere. The configure step is where you tell the demolisher where.

Direct wallet destination

Paste any Stellar G-address. If the address is a regular wallet, the closure ends with a plain ACCOUNT_MERGE to that address. The destination account receives the merged balance and any remaining lumens, including the 1 XLM base reserve the closing account was holding.

The destination must already exist on chain. Stellar's ACCOUNT_MERGE op fails if the destination doesn't exist. If you want to merge into a brand new address, fund it first.

Exchange destination (the mediator)

Major centralized exchanges do not accept ACCOUNT_MERGE operations. If you try to close an account directly to an exchange deposit address, the merge succeeds on chain but the exchange does not credit your account. The lumens are technically delivered but you cannot withdraw them.

Account Demolisher recognizes a curated list of known CEX hot wallets and, when the destination matches one of them, routes the closure through a temporary mediator account.

How the mediator path works

1. The first batch of the classical closure includes a CREATE_ACCOUNT op that funds a fresh mediator account with 2 XLM. The mediator is an ephemeral account; only its secret key is held by the deployment.
2. The closing account is merged to the mediator, not to the exchange. After the merge, the mediator holds the closing account's full balance.
3. A separate two-op envelope is built: a native PAYMENT from the mediator to the exchange address, plus an ACCOUNT_MERGE of the mediator into a fallback (defaulting to the same destination address, but it can be overridden in the configure step).
4. The two-op envelope is sent to the deployment's mediator-sign endpoint. The endpoint validates the envelope's shape strictly: the mediator must be the source of both ops, the payment must be native, the merge must be the second op, the time bounds must be present and within MAX_TIME_BOUND_SECONDS (1 hour), and the envelope must not be a fee-bump.
5. If the envelope passes validation, the server co-signs it with the mediator key and returns the signed envelope. The user's wallet has already signed with whatever account is paying the network fee.
6. The signed envelope is submitted to Horizon. The exchange receives a native payment with the correct memo. The mediator is then merged into the fallback, returning whatever balance remains after the payment and network fees.

The end result is that the closing account is fully closed, the recovered funds end up at the exchange under the right memo, and no XLM is left stranded.

Why this is safe

The mediator key is the only secret the deployment holds. The validator at src/lib/mediator/validator.ts is the primary security boundary. Sixteen distinct failure codes cover every shape mismatch across the merge and forward envelopes. The endpoint is also rate limited at five requests per minute per IP.

If you want to verify the envelope shape yourself, the validator file is short and readable.

Memos and exchanges

Most exchanges require a memo for deposits. Without the memo, your funds may be lost or held indefinitely. The demolisher's registry at src/lib/safety/cex-registry.ts carries 12 entries and refuses to start the closure if the memo type is missing or wrong:

• text memo: Kraken, Bitfinex, KuCoin, Upbit, CEX.IO, Crypto.com, Robinhood, Coinbase Deposits, Blockchain.com.
• id memo (numeric): Binance, Binance Deposits, Bitstamp.

If you are sending to an exchange not in the curated list, you can still complete the closure but the demolisher cannot verify the memo policy for you. Read the exchange's docs before you proceed.

Why the mediator instead of a direct payment

You could theoretically close the account by draining everything via payments and leaving 1 XLM behind. That 1 XLM is the base reserve. It cannot be released without ACCOUNT_MERGE. So the mediator pattern is the only way to recover that final base reserve when sending to an exchange.