Closure lifecycle
The four stages a close moves through, and what each one guarantees.
A close is a sequence of ordinary Stellar transactions. The app assembles the right ones in the right order, grounds them in live network state before you sign, and recovers when that state shifts underneath.
Four stages: discover, plan, preview, execute.
1. Discover
Horizon is read for the full account state. Soroban RPC is scanned for the account's SEP-41
approvals, and each one is read back from the token's allowance(); those that read zero are
dropped. Blend, Aquarius and Soroswap are probed for open positions, the Aquarius reward gauges
for what they owe, and the account's transfer history for standalone tokens. With a Lumeus key for
the network, the allowance, standalone-token and Aquarius scans also read the account's whole
history from Lumeus, a hosted Stellar history index, and every result is read on chain like a
scanned one.
The audit, the reads of positions that keep the account from merging, and the payout trustline checks are required: a failure there fails discovery or blocks the close. The allowance and standalone-token scans are best effort, and an incomplete scan is reported as a warning with how much it covered.
Account audit · Position discovery
2. Plan
The audit, the positions and the allowances feed a pure generator that emits a directed acyclic graph of steps. There are 20 node kinds, and a node is emitted only when the account needs it.
Each node lists its dependencies. A Blend withdraw waits for that pool's repays, a repay waits for the exits that can fund it, an exit that pays into a new trustline waits for that trustline, and the classic close waits for every other node, so the merge never runs while a position is open. When a Blend backstop withdrawal stays locked after the run, the plan has no merge at all and only prepares the close.
The graph is validated when built: duplicate ids, missing dependency targets and cycles are rejected.
The plan graph · The classic batch
3. Preview
Each Soroban step is built and run through the RPC's simulateTransaction, and its resource fee,
authorization entries and footprint are assembled into the transaction. The sign-time checks then
run on every required step: an allow-listed root contract, exactly the authorization tree the call
needs, and a fee under the cap for its kind of step. A step that fails any of this is marked failed
with its reason, and confirming is disabled while any required step is failed.
A step that runs after other steps and cannot be built against today's state (a collateral withdraw behind its repay, a sweep behind the exits that pay it) is deferred: it is built and simulated at execute time once those steps have landed.
The classic close is not RPC-simulated. Its batches are built locally from the audit, and the preview checks mergeability against the claims the plan really makes.
4. Execute
Execution walks the graph in a stable topological order. Each Soroban step is rebuilt from fresh state, checked again, signed through the connector, submitted and confirmed before its dependents run. The classic close is rebuilt from a fresh audit before every phase.
You sign once per transaction, because Stellar does not combine Soroban and classic operations in one transaction.
What holds across the stages
The merge never runs early. Before each classic phase the executor audits the account again, discovers DeFi positions again and refuses while any is open or a protocol could not be read, checks that no exit payout token is still on the account, and checks mergeability against what the batch really claims.
A step that did not land blocks its dependents. A dependent of a failed step is skipped, never run around it. Only a best-effort step (an allowance revoke, a standalone token sweep or conversion) that was skipped on purpose lets its dependents run.
Nothing is reported done until it confirmed. A node is complete only when it carries the receipt of its own transaction. The classic close records its receipt only when the merge batch lands, and an exchange close succeeds only when the forward out of the forwarding account lands.
A retry re-runs what did not land. A retryable failure runs the same reviewed plan again: steps with a receipt are skipped and every other step is reset and runs again.