# 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: 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/real-time.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.