> 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/architecture/real-time.md).

# Real-Time Confirmation

NorthStar can confirm transactions in milliseconds — not by waiting for a global slot to elapse, but by treating the ER session as a single-tenant runtime where the operator controls the cadence.

## Why a NorthStar session is real-time-capable

Three properties combine to make sub-perceptual confirmation feasible:

1. **Single-tenant execution.** Each session runs in isolation. There is no cross-app contention, no shared mempool, no fork choice across competing forks. Block production cadence is a local parameter, not a network-wide consensus negotiation.
2. **Configurable slot duration.** The validator's `slot_duration_ms` is a per-session knob — not the network-wide \~400ms Solana standard. Operators can run sessions at 10ms slots, 1ms slots, or any cadence the workload needs.
3. **`processed = confirmed` semantic equivalence.** With one sequencer and no fork ambiguity, the moment a transaction lands in the ER's local order, it's also confirmed. Browser code can rely on `processed` commitment as the final state.

## How sub-50ms confirmation works in practice

The confirmation pipeline:

```mermaid
sequenceDiagram
    participant U as Browser / agent
    participant ER as Ephemeral Rollup
    U->>ER: TPU-direct submission via QUIC
    Note over ER: Receives → orders → lands → emits to subscribers
    ER-->>U: signatureSubscribe (WS)
```

* **TPU-direct submission** — the SDK opens a QUIC connection to the validator's `EphemeralTpu` endpoint, bypassing the gateway forwarder.
* **Sub-slot wake-up** — `signatureSubscribe` over WebSocket fires the moment the transaction lands. No polling, no slot-cadence delay.
* **Local-order finality** — single-sequencer means the local ordering *is* the canonical ordering. `processed` commitment is sufficient.

End-to-end on the same machine as the validator, sub-50ms confirmation is reliable. On a separate machine over the public internet, latency floors at the network round-trip — typically 10–60ms depending on geography.

## Tracking sub-millisecond claims

The marketing-grade "real-time" copy describes the **mature platform's capability**, not today's measured devnet path. The slot duration knob currently defaults to 400ms in deployed validators; per-session overrides + the SDK helper that wires up TPU-direct submission are tracked under the NorthStar project. Three deliverables:

1. **SDK helper** — `sdk.session.confirm({ tpuDirect: true })` — wraps QUIC submission + `signatureSubscribe` with one call.
2. **Bench v2** — slot-delta latency instrumentation, replaces the current `t_send → blockTime` measurement which is unreliable on the ER.
3. **Per-session slot duration** — `OpenSession` accepts `slot_duration_ms` so each grid picks its cadence.

## See also

* [Sessions](/concepts/sessions.md)
* [ER topology](https://github.com/mirrorworld-universe/northstar-docs/blob/main/architecture/er-topology/README.md)
* [Confirmation lifecycle](https://github.com/mirrorworld-universe/northstar-docs/blob/main/architecture/confirmation-lifecycle/README.md)
* [Bench results](https://github.com/mirrorworld-universe/northstar-docs/blob/main/references/README.md) — measured numbers for the current path.


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.northstar.sonicsvm.org/architecture/real-time.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.