# Security Model

NorthStar's security model is **L1-anchored**: every guarantee a session offers traces back to a property the Portal program enforces on Solana, plus a fraud-proof challenge protocol that lets any uncensored party invalidate a dishonest sequencer's state.

This page covers the trust assumptions, the custody guarantees, the challenge protocol, and the failure modes.

## Trust assumptions

| Party                       | Assumption                                                                                                                                                             |
| --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Owner**                   | Holds the keypair that opened the session. Trusted to act on their own behalf — no protection if their own keypair is compromised.                                     |
| **Portal program**          | Trusted as immutable, audited L1 code. Its deployed bytecode is verifiable on-chain.                                                                                   |
| **Sequencer / validator**   | **Untrusted for state honesty.** Trusted only to be live (provide service); state correctness is enforced by the challenge protocol below.                             |
| **Solana L1**               | Trusted as the canonical settlement layer. Inherits Solana's consensus security.                                                                                       |
| **At least one challenger** | The challenge protocol assumes at least one honest, uncensored party can submit fraud proofs. This is the same `1-of-N` honesty assumption optimistic rollups rely on. |

The combined assumption: **as long as L1 is live and one honest challenger exists, the sequencer cannot finalize a dishonest state.** Liveness depends on the operator; correctness does not.

## Custody guarantees

While a session is active, every delegated account has the following invariants — enforced by the Portal program at the L1 level:

1. **L1 write-lock.** No L1 transaction signed by anyone — including the original owner — can mutate a delegated account. The account's `owner` field is the Portal, and the Portal's CPI rules reject all writes that don't come through the settle-back path.
2. **ER exclusivity.** Exactly one validator instance is authorized to write the account inside the ER. Routing is enforced by the `(portal, owner, grid_id)` tuple in the delegation record.
3. **Atomic settle-back.** When the session closes (explicit or TTL), every delegated account commits its final ER state to L1 in one operation. Either all accounts settle, or none do — there is no intermediate state.
4. **Forced undelegation.** If the operator goes offline and the TTL expires, the **owner can unilaterally force-undelegate**. The state used for settle-back is whatever the ER had at expiry; if the operator has censored the latest state, the owner accepts the last published checkpoint instead. **The owner is never permanently locked out.**

These four properties hold under the trust assumptions above. They do not depend on the sequencer being honest; they depend only on the Portal program being correctly deployed and L1 being live.

## The challenge protocol

The sequencer's job is to publish the ER's state to L1 periodically as **checkpoint bonds**. Each checkpoint is a `(state_hash, bond)` tuple posted to L1 every \~30 seconds. The bond is collateral the sequencer forfeits if it publishes a dishonest checkpoint.

If any party — a challenger watching from outside, or the owner — sees a checkpoint they believe is wrong, they invoke the bisection protocol:

![NorthStar challenge protocol](/files/sLNeiDQjONelPQH5Oico)

The flow:

### 1. Sequencer posts checkpoint bond

Every \~30 seconds, the sequencer publishes `(state_hash, bond)` to L1. This is the public claim about the ER's state at that point. Until challenged, it's accepted as canonical after the fraud-proof window.

### 2. Challenger submits a challenge

Any party can call the Portal's `Challenge` instruction with `(checkpoint_id, alleged_correct_hash)`. The Portal records the challenge and pauses settlement for the disputed range.

### 3. Bisection protocol

The challenger and sequencer enter an interactive game:

* The Portal asks: "Of the two halves of the disputed range, which half do you disagree on?"
* Both parties answer (left or right half).
* The losing half is discarded; the disagreement narrows.
* Repeat until a single transition is isolated — `O(log n)` steps for a checkpoint covering `n` transitions.

This is the classical [bisection protocol](https://medium.com/offchainlabs/optimistic-rollup-vs-multi-round-fraud-proofs-and-bisection-protocols-on-arbitrum-7e036ea3b4ff) used by optimistic rollups: it isolates the first divergent step without requiring on-chain replay of every intermediate state.

### 4. ZK proof for the isolated transition

Once a single transaction is isolated, the prover generates a **succinct ZK proof** for that one transition. The Portal verifies the proof on-chain — cheap, because it's a single-tx proof, not the full session.

### 5. Outcome

| Verdict                     | Effect                                                                                                                                                                                           |
| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Sequencer was dishonest** | The sequencer's bond is **slashed** (forfeit to the protocol / challenger). The Portal substitutes the correct state for the disputed checkpoint. Settle-back proceeds with the corrected state. |
| **Sequencer was honest**    | The challenge is rejected. The challenger forfeits their challenge bond (anti-spam). The original checkpoint stands.                                                                             |

In either case, the dispute terminates in bounded time and leaves L1 with the correct state.

## What this composes to

For an end-user with assets in a session:

* **Liveness:** depends on the sequencer. If the sequencer is offline, the session pauses; the user retrieves assets via forced undelegation after TTL.
* **Correctness:** does not depend on the sequencer. Dishonest checkpoints get caught by the challenge protocol; the correct state is restored before settle-back finalizes.
* **Custody:** does not depend on the sequencer. The Portal's L1 write-lock + forced undelegation guarantee that assets always return to the owner's control.

This is the "validity-with-liveness-degradation" model: in the worst case the user waits longer, but their assets are never at risk of being stolen by a misbehaving operator.

## Failure modes

| Scenario                                         | Effect                                                                                              | Recovery                                                                       |
| ------------------------------------------------ | --------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ |
| Sequencer offline                                | Session stalls; in-flight ER txs unconfirmed.                                                       | Owner force-undelegates after TTL; settles to last published checkpoint.       |
| Sequencer publishes a bad checkpoint             | Challenge protocol triggers; sequencer's bond slashed; correct state restored.                      | No user action required if any honest challenger is watching.                  |
| Sequencer publishes nothing (silent withholding) | The fraud-proof window can't open without a checkpoint to challenge.                                | Owner force-undelegates after TTL; falls back to the last good checkpoint.     |
| Owner keypair compromised                        | Attacker can act as the owner — same as on L1. NorthStar provides no additional protection here.    | Standard key-rotation hygiene applies.                                         |
| L1 outage                                        | All session lifecycle ops (open / delegate / close) pause; ER execution continues until L1 returns. | Session resumes when L1 is back.                                               |
| Portal program bug                               | In principle catastrophic — the program is the security boundary.                                   | The Portal is audited and immutable; deployed bytecode is verifiable on-chain. |

## Implementation status

* **Portal L1 write-lock** — live on devnet.
* **Forced undelegation** — live on devnet (TTL-bound).
* **Atomic settle-back** — live on devnet.
* **Checkpoint bonds + bisection protocol** — specified in the [litepaper](https://github.com/mirrorworld-universe/reports); implementation tracked under the public roadmap. Devnet currently runs in honest-sequencer mode.
* **ZK proof verifier** — same.

The mature security model is the destination; the current devnet path is honest-sequencer with audited Portal bytecode. Production / mainnet brings the full fraud-proof game online.

## See also

* [Sessions](/concepts/sessions.md) — the lifecycle the security model protects.
* [Account delegation](/concepts/delegation.md) — the L1 write-lock primitive.
* [Settle-back guarantees](/concepts/settle-back.md) — atomicity model that depends on these properties.
* [ER topology](/architecture/er-topology.md) — where each component sits.


---

# Agent Instructions: 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:

```
GET https://docs.northstar.sonicsvm.org/architecture/security.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.