> For the complete documentation index, see [llms.txt](https://docs.optivalux.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.optivalux.com/technical/network-and-finality.md).

# Network & Finality

> **Current stage:** no network has been selected for public deployment, and nothing has been deployed to any public network, test or production. Public-network validation is **in development**. This page describes the validation approach and the concepts involved, not a final decision.

## Deployment sequence

Optivalux follows a fixed sequence:

1. **Local development network**: done. The Production V2 protocol has been deployed and exercised end to end locally.
2. **Public test network**: after a candidate network is validated.
3. **Integration and security validation** on that network.
4. **Production network**: only after an **external security audit** and **explicit written authorization**.

The protocol is written for standard EVM compatibility and contains no hard-coded network assumptions. Network identifiers, endpoints, confirmation depth and contract addresses come from configuration.

## What candidate-network validation covers

Before any public deployment, a candidate network is validated for:

| Area                     | What is checked                                                                                                                                                                                                                                     |
| ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **EVM compatibility**    | Standard EVM behaviour the contracts rely on, including standard contract-address derivation.                                                                                                                                                       |
| **Deployment behaviour** | The protocol's core components are deployed together in one atomic transaction and bind to each other at construction. The network must accept a transaction of that size, and the deployment must be verifiable against published, audited builds. |
| **Finality**             | How and when transactions become irreversible, and what that means for ownership-critical reads (see below).                                                                                                                                        |
| **RPC evidence**         | That the network's RPC endpoints provide the data needed to verify deployments and monitor state, including block tags and transaction receipts.                                                                                                    |
| **Fees**                 | Sustained fee levels at pilot volume. Fee handling and relaying policy are part of the deployment and service design and are not yet a fixed public commercial commitment.                                                                          |
| **Liveness**             | Operational record: outages, reorganisations, sequencer or validator behaviour, and how users can still get transactions included if an operator censors or stalls.                                                                                 |

Other selection criteria include settlement guarantees (for example, rollup versus sidechain), account and signing support, explorer and indexer infrastructure, and regulatory or data-residency considerations.

Some protocol timing values are expressed in blocks (for example, the freshness window for asymmetric authenticator signatures). These will be converted to wall-clock bounds and reviewed for the selected network, and adjusted before any public release if needed.

## Latest, safe and finalized

EVM networks commonly expose different levels of confidence about recent blocks. Where a network provides them, Optivalux treats these as distinct:

| Level         | Meaning                                                                 | Appropriate use                                                              |
| ------------- | ----------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
| **Latest**    | The most recent block the node has seen. May still be reorganised away. | Showing pending activity; never the basis for an ownership-critical decision |
| **Safe**      | A block considered unlikely to be reorganised under normal conditions.  | Most interface reads                                                         |
| **Finalized** | A block the network considers irreversible under its consensus rules.   | Ownership-critical decisions and reconciliation                              |

Exact semantics differ between network types, and the policy for which level each Optivalux read uses will be set once a network is selected.

Independent of these levels:

* **The indexer records block numbers and hashes**, handles reorganisations using a per-network confirmation depth, and reconciles its projection against chain state.
* **Ownership-critical decisions read the chain**, or verify that the projection is current, before relying on it.
* Applications show **pending** states rather than presenting unconfirmed changes as complete.

## Governance parameters

Before any public-network governance rehearsal, the governance multi-signature thresholds, time delays and the production notice period for voiding owned certificates must be set. They are not yet decided.

## What this page does not state

* It does not name a selected network. None has been selected.
* It does not claim that any public deployment has occurred.
* It does not state final finality or confirmation-depth values.

This page will be updated when a network decision is formally recorded in the protocol's architecture decisions.


---

# 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.optivalux.com/technical/network-and-finality.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.