Skip to content

Security and trust

Using a financial network means relying on several distinct systems. Novrinex documents these trust boundaries separately so that an interface, oracle, builder, or bridged asset is not mistaken for the authority over every part of a trade.

The owner address controls capital and permissions. Connecting a wallet proves control of that address; it does not place an order or move funds without a separate signed action.

Trading keys can be restricted by permission, subaccount, market, maximum notional, expiry height, and nonce. A trade-only key cannot withdraw, although it can still cause financial loss by opening, closing, or cancelling exposure. Revoke a key immediately after suspected compromise.

Validators establish transaction order and independently run Novrinex Core. The committed network state is authoritative for native balances, orders, fills, positions, margin, funding, liquidations, insurance, and builder markets.

Consensus cannot bypass the financial rules. A proposed block must satisfy FairFlow ordering, authorization, accounting, margin, and state-transition checks before honest validators commit it.

Perpetual markets depend on prices that originate outside the Novrinex order book. Each oracle feed names its reporters, weights, quorum, staleness limit, deviation policy, purpose, pause behavior, and recovery requirement.

Reporters submit signed observations. Validators verify and aggregate those observations during execution; they do not make live external API calls while processing a block.

If the feed lacks enough current agreement, the dependent market stops accepting new exposure while risk-reducing actions remain available.

A bridged settlement asset inherits risks from its source asset, source chain, bridge contracts, signers or operators, destination issuance, and emergency controls.

Novrinex can verify that network custody and the Core ledger move together during a deposit or withdrawal. It cannot remove a flaw in the external asset or bridge. Asset limits and monitoring therefore remain part of the market’s risk policy.

A builder controls its market definition within protocol limits and can pause markets it owns. The builder does not control trader funds or the Core accounting and risk engines.

Each builder exchange publishes its owner, settlement asset, oracle, fees, exposure limits, risk domain, insurance, and pause state. Separate financial accounts prevent one builder from drawing on unrelated collateral or insurance.

Governance manages network parameters, upgrades, builder policy, and defined market-recovery actions. High-impact authority is narrow, visible, delayed where practical, and protected through multi-party operational controls.

A state change that would invalidate existing financial records requires an explicit, deterministic migration applied by the network at an agreed height.

An RPC node, indexer, API, WebSocket service, explorer, backend, or frontend can be stale or unavailable. It cannot rewrite committed network state.

Clients retain block and cursor context, detect gaps, and reconcile against a healthy indexer or direct node query. A conflict resolves in favor of the committed network result.

  • Confirm the novrinex.com domain before connecting or signing.
  • Read the network, market, amount, permission, expiry, and destination in every request.
  • Never share a seed phrase, private key, recovery code, or unencrypted credential export.
  • Give trading applications only the permissions they require.
  • Test a new deposit, withdrawal, or bridge route with a small amount.
  • Check the authoritative order and position state after an interrupted submission.
  • Keep enough network gas to revoke permissions or move capital when necessary.