> For the complete documentation index, see [llms.txt](https://docs.northstar.sonicsvm.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.northstar.sonicsvm.org/concepts/settle-back.md).

# Settle-Back Guarantees

When a NorthStar session closes (explicit close or TTL expiry), every delegated account commits its final ER-side state back to L1 in one atomic step. This page explains the formal guarantees and the failure modes.

## The core guarantee

After `CloseSession` returns successfully, every delegated account's L1 state matches its final ER state. Either:

* **All delegated accounts settle**, in one atomic operation, **OR**
* **Nothing settles**, and the session reverts to its pre-close state for retry.

There is no intermediate state where some accounts settled and others didn't.

## Why it's atomic

The Portal program treats settle-back as a single multi-account write. The ER's final state is committed to L1 by the sequencer; any partial failure unwinds. This is enforced at the Portal level, not at the runtime level.

For the cryptographic / dispute-game guarantees that back this — checkpoint bonds, fraud proofs, ZK verification — see the [security model](/architecture/security.md).

## Failure modes

| Scenario                             | What happens                                                                                                |
| ------------------------------------ | ----------------------------------------------------------------------------------------------------------- |
| Owner explicitly closes (happy path) | All accounts settle atomically. Owner regains control.                                                      |
| Session TTL expires without close    | Portal allows **forced undelegation** by the owner. State is whatever the ER had at expiry; same atomicity. |
| Sequencer goes offline mid-session   | Session pauses; owner can force-undelegate after TTL expiry.                                                |
| Sequencer publishes a bad checkpoint | Fraud proof from any uncensored validator triggers slashing + state correction.                             |
| Network partition                    | Unaffected — the session's state is on L1 throughout.                                                       |

## What about in-flight transactions at close time?

When `CloseSession` is called, the ER stops accepting new transactions for that session. Any tx already submitted but not yet confirmed:

* **If it lands before close finalizes** — included in the final settle-back.
* **If it doesn't land before close finalizes** — dropped. Resubmit against a new session, or accept that it won't complete.

Practical guidance: if you have outstanding work that must complete, wait for `confirmed` on every in-flight tx before closing.

## See also

* [Security model](/architecture/security.md) — the cryptographic guarantees behind atomicity.
* [Sessions](https://github.com/mirrorworld-universe/northstar-docs/blob/main/concepts/sessions/README.md) — full lifecycle.
* [Account delegation](https://github.com/mirrorworld-universe/northstar-docs/blob/main/concepts/delegation/README.md) — what's settled.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.northstar.sonicsvm.org/concepts/settle-back.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.