Skip to main content
Platforms that create a Stellar account per user (embedded wallets, fintech apps, remittance and payout products) front the cost of every account they activate. A master account funds each new user account with enough XLM to exist: the 1 XLM minimum balance, plus 0.5 XLM for each trustline the product needs, a USDC trustline being the typical first one. That XLM is working capital, and it stays locked for the life of the account. The problem shows up with churn. When a user leaves, their account keeps holding the platform’s XLM unless someone winds it down properly, and “properly” means the full sequence: remove trustlines (after clearing any balance), remove data entries, cancel offers, then merge. At fleet scale this is not a manual job. A platform with 100,000 activated accounts and one trustline each has 150,000 XLM committed to reserves; every percentage point of churn that goes unrecovered strands 1,500 XLM permanently. LumenWipe closes that loop. The REST API takes the departing account and returns the full wind-down plan ready to sign; the platform signs with its own key infrastructure, as it does for everything else. The merge destination is the master account that funded the account in the first place, so the activation capital returns to the same pool it came from and funds the next signup. Only the platform’s keys can move anything; LumenWipe never holds funds or keys. And every plan is checked against live on-chain state before execution, so an account the user already emptied or changed is handled correctly instead of blindly replayed. To see the integration end to end, the SDK ships a headless example that closes a testnet account from a plain Node process, signing with an in-process key and verifying every transaction before it signs.

​
Example: a platform that funds its users’ accounts

Consider a platform that activates every user account from a master account. When a user leaves, the platform calls the REST API for the wind-down plan, verifies each transaction, and signs it with its own key infrastructure. Nothing runs without a signature from the platform: the API only builds unsigned transactions. The merge destination is the master account that funded the account, so the activation XLM returns to the pool it came from. This is an integration pattern, not a description of any particular partner, and the SDK headless example above shows it end to end on testnet.