Batch decommissioning
The REST API takes a list of addresses and returns a per-account plan: what each account holds, what the wind-down steps are, what XLM lands at the destination. An operator drives execution from their own backend through the hosted API and signs with their own keys; LumenWipe never holds anything. This is the difference between “we should clean those up someday” and a script that runs in an afternoon. Typical fleets:- Channel and payout accounts from a payments or remittance operation that changed architecture.
- Airdrop or campaign distribution accounts that finished their purpose but still hold trustlines and dust balances.
- Per-customer deposit accounts at an anchor or custodial service after migration to a different model.
- Test and staging accounts that were funded on mainnet for a launch rehearsal.
What the SDK sends, and to whom
LumenWipe supports only the hosted API at api.lumenwipe.com.@lumenwipe/sdk is a thin fetch client to that API: it builds no plans and no transactions locally, and it has no @stellar/stellar-sdk dependency. Every account address you send for analysis, and the destination of the close, reaches LumenWipe, which reads the network and builds the unsigned transactions on its side. Self-hosting is not supported.
Your signing keys are never sent. Transactions come back unsigned, and you verify and sign them in your own backend. If your operations team cannot send account lists to a third party, this API is not the right tool for those accounts.
See the SDK overview for what the client does and does not do.