> 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/readme.md).

# Introduction

NorthStar is a programmable Ephemeral Rollup (ER) platform on Sonic SVM. It lets a developer carve out a single-tenant, isolated runtime — a **session** — anchored to Solana L1, run logic at custom slot cadence inside it, and atomically settle state back to L1 when the session closes.

Same Solana programs. Same SDK shapes. Different latency, different fee policy, different blast radius.

## What problem does it solve

A single global blockchain is a bad fit for workloads that need:

* **Sub-50ms confirmation** — agents reasoning faster than human perception, market makers responding to mid-quote shifts, real-time games.
* **Per-app fee economics** — gasless reads for end users, custom fee schedules for high-frequency strategies, MEV-aware policies.
* **Isolated execution boundaries** — one tenant's congestion can't slow another's confirmations.

Today's options force a choice between L1 (general, secure, slow, fixed fee policy) and an offchain server (fast, but you've left the trust model behind). NorthStar splits the difference: an L1-anchored, single-tenant runtime that inherits Solana's security and gives the operator the dials.

## What you actually get

A session is a bounded execution context with five properties the operator chooses:

| Knob                   | What it controls                                         |
| ---------------------- | -------------------------------------------------------- |
| **Grid id**            | Identifier; one session per `(owner, grid_id)`           |
| **TTL**                | Maximum lifespan in slots before forced settlement       |
| **Fee cap**            | Lamport budget for internal accounting                   |
| **Fee structure**      | The schedule that prices instructions inside the session |
| **Delegated accounts** | The state the session is allowed to write                |

Inside the session, transactions execute against a private Solana validator, with confirmation at the operator's chosen slot cadence (current devnet default: 400ms; the path to 10ms is in the [Real-time confirmation](/architecture/real-time.md) docs). Outside the session, those same accounts are **locked on L1** — no transaction signed by anyone, including the original owner, can mutate them until the session closes. When it does, every change settles back atomically.

## Who it's for

* **dApp developers** who already ship Solana programs and want isolation, custom cadence, or programmable economics for a specific surface (orderbook, AMM, agent harness) without rewriting their stack.
* **Agent builders** running model-driven trading or coordination loops where end-to-end latency dominates and global slot cadence is a tax.
* **Protocol designers** who want application-specific MEV policies, custom fee curves, or tenant isolation as first-class primitives.

If you've shipped a Solana program before, the SDK is the same shape you already know. If you haven't, [Hello World](/getting-started/hello-world.md) is \~30 lines.

## Where to start

| If you want to...                   | Read                                                                                                              |
| ----------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| See it work end-to-end in 5 minutes | [Hello World](/getting-started/hello-world.md)                                                                    |
| Understand the formal model         | [Sessions](/concepts/sessions.md), [Account delegation](/concepts/delegation.md)                                  |
| Understand how it's wired           | [ER topology](/architecture/er-topology.md)                                                                       |
| Understand the trust model          | [Security model](/architecture/security.md)                                                                       |
| Migrate an existing Solana program  | [Migrate to NorthStar](https://github.com/mirrorworld-universe/northstar-docs/blob/main/content/build/migrate.md) |
| Look up Portal program instructions | [Portal program reference](/reference/portal-program.md)                                                          |

## What this isn't

* **Not a sidechain.** State lives on Solana L1 throughout. The ER is execution-only; settlement is L1-native.
* **Not multi-tenant.** A session is single-tenant by design — that's the property that makes the cadence + economics knobs safe.
* **Not a general L2.** It's purpose-built for short-lived, application-scoped sessions. Long-running shared state belongs on L1.

## Status

NorthStar is live on Sonic Devnet (the Sonic L1 surface anchored to Solana Devnet). The platform is feature-complete for single-owner sessions; per-user isolation, real-time slot overrides, and the formal challenge protocol are tracked under the public [Linear roadmap](https://linear.app/mirror-world). The [litepaper](https://github.com/mirrorworld-universe/reports) covers the formal model and the path to mainnet.


---

# 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/readme.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.