Protocol direction

Novrinex L1 is planned as the settlement and execution network for Novrinex-operated markets. It follows the native venue build. Current customer orders do not execute on Novrinex L1.

The sequence matters because the exchange must establish real requirements for throughput, ordering, margin, liquidations, market data, recovery, and operator controls before those functions are committed to a network design.

From routed exchange to native venue

The live exchange already owns the customer order contract, canonical market catalogue, execution gateway, account view, fill ledger, and product distribution. External venues currently retain matching and settlement authority.

The native venue moves the following responsibilities to Novrinex:

core crypto order books;
matching and deterministic order priority;
margin and position accounting;
funding calculation and settlement;
liquidation and backstop execution;
insurance-fund accounting;
market-maker and API connectivity;
authoritative public market and account state.

BTC, ETH, and SOL perpetuals are the planned first markets. Long-tail and macro products follow only after the core venue meets liquidity, risk, legal, and operational thresholds.

Why a dedicated Layer 1

A perpetual venue produces a continuous stream of ordered actions and risk changes. New orders, cancellations, fills, funding, margin transfers, and liquidations must observe one consistent account state. Delay or disagreement can turn a small pricing event into bad debt.

Novrinex L1 is intended to give the exchange direct control over:

transaction ordering and finality;
execution latency and capacity;
deterministic risk actions;
data availability for markets and accounts;
validator and operator failure recovery;
protocol fees and security incentives;
builder access to exchange state.

These are design objectives. The consensus, validator, data-availability, execution, and bridging specifications have not been published.

Planned network responsibilities

Exchange state

The network will record orders, fills, positions, balances, margin, funding, liquidations, and insurance movements for Novrinex-operated markets.

Ordering and agreement

Validators or other approved infrastructure operators will agree on transaction order and resulting state. The testnet specification must define fault assumptions, finality, operator admission, slashing or equivalent enforcement, and recovery from unavailable or conflicting nodes.

Public data

Testnet scope includes an explorer, public market data, account-state access, and documented APIs. Traders and builders must be able to verify the state the exchange uses for execution and risk.

Builder access

Mainnet scope includes APIs for trading applications and approved market deployers. Permissioned deployment comes before any consideration of open market creation. Market data rights, oracle design, margin parameters, legal eligibility, and emergency controls remain market-specific gates.

Testnet release gates

Novrinex will publish the architecture before public testnet. Testnet release requires:

a functioning native matching and risk system;
measured throughput and latency under representative load;
deterministic replay and state-recovery testing;
validator and network fault testing;
oracle, liquidation, and bad-debt stress tests;
key-management and incident procedures;
independent security review;
a documented migration and rollback path for test markets.

Mainnet requires further restricted operation, contracted liquidity, legal approval, production monitoring, insurance capitalization, and independent audits.

External venues after native launch

Native execution does not require Novrinex to remove every external route. The gateway can retain supplementary markets where an external venue offers products or liquidity that the native venue does not yet support.

Each canonical market will still have one active preferred route. The market record and execution receipt will identify the applicable settlement system.

Protocol asset policy

Novrinex has not announced a protocol asset. Points carry no conversion or distribution commitment.

A protocol asset will be considered only if the operating network requires it for validator security, protocol fees, or another necessary function. Any proposal must follow working infrastructure and include published utility, supply, allocation, governance, treasury, and legal terms.

A mainnet does not by itself require a public asset. The security design will determine that decision.