Security and control model
Novrinex’s current security model separates custody, trading authority, and execution records. Traders retain their main wallet and withdrawal authority. Novrinex stores scoped credentials for server-side trading and maintains an auditable record of every submitted command.
Trade-only authorization still carries financial risk. A compromised credential may be unable to withdraw, while remaining able to open, close, or cancel positions.
Capital custody
Section titled “Capital custody”Current funds remain in:
- the user’s connected wallet;
- a user-attributable Orderly trading account;
- the user’s Hyperliquid account;
- per-position collateral controlled by Ostium contracts.
The combined portfolio is an observed account view. Novrinex does not pool these balances and does not use one customer’s capital to support another customer’s trading.
Wallets, venues, and onchain contracts remain authoritative for current balances and positions.
Authentication
Section titled “Authentication”Wallet login proves control of the connected address through a signed authentication message. Authentication does not authorize an order, transfer funds, or grant indefinite access to the wallet.
Private capital, order, and authorization endpoints require an authenticated Novrinex session and enforce account ownership.
Execution authorization
Section titled “Execution authorization”Each current market group uses a route-specific, trade-only grant:
| Market group | Authorization | Withdrawal access |
|---|---|---|
| Crypto markets | Scoped trading key approved by the wallet | None |
| Global markets | Named account agent approved by the wallet | None |
| Wallet-collateral markets | Contract allowance and delegated trading permission | Payout destination remains the trader |
Private credential material is encrypted at rest. The encryption key is supplied by the deployment secret manager rather than stored in the application database. Authorizations are checked against the active route and can be revoked.
Deposits, withdrawals, bridges, settlements, and unrestricted transfers continue to require the user’s wallet or the route’s main-account authorization.
Durable execution
Section titled “Durable execution”Novrinex commits an order command before external submission. The record contains ownership, complete economic terms, capital plan, route, idempotency key, state transitions, and external identifiers.
The system commits the executing state before the network request. It commits the resulting state before publishing the account update. This ordering lets Novrinex resume or reconcile work after a process or network interruption.
Exact retries return the existing command. A timed-out mutation is not silently retried against the same or another venue.
Reconciliation
Section titled “Reconciliation”An external identifier or transaction hash links the Novrinex command to authoritative route state. Order-book routes reconcile against order and fill APIs. Contract routes also inspect onchain position state after the initial transaction is mined.
A successful transaction receipt can mean that a request was accepted for processing. It does not always mean that the position has opened or closed. Novrinex keeps the order pending until the route’s final state confirms the result.
Failure policy
Section titled “Failure policy”New exposure fails closed when Novrinex lacks required authentication, current relevant capital, valid authorization, live price data, or a healthy execution route.
An unresolved command becomes Unknown or Reconciling. Duplicate submission remains blocked until the authoritative lookup completes. Queued Market orders expire rather than executing against stale context.
Failure of Novrinex does not freeze the external venue. Existing positions can continue to gain or lose value, receive funding, or be liquidated.
Verified execution ledger
Section titled “Verified execution ledger”Novrinex rebuilds trade history from source-tagged venue and onchain records. Writes are idempotent by user, source, and provider order identifier. Each venue can fail independently without discarding already reconciled events from another route.
The ledger distinguishes user trades from forced liquidations. It supplies account history, creator performance, fee and referral records, and the proposed Points calculation source.
Operational controls
Section titled “Operational controls”Production controls include route-specific execution switches, authorization revocation, bounded execution workers, stale-data limits, order expiry, duplicate prevention, price-deviation limits, and reconciliation alerts.
Planned and continuing work includes independent security reviews, recovery exercises, authorization-rotation procedures, discrepancy alerting, incident response, and security assessment of the native venue and L1 before release.
User responsibilities
Section titled “User responsibilities”- Verify the
novrinex.comdomain before connecting or signing. - Read the requested network, contract, amount, permission, and expiry.
- Never share a seed phrase, private key, recovery code, or unencrypted export.
- Keep wallet software and the signing device updated.
- Revoke trading authorization if a device, session, or account may be compromised.
- Test a new deposit, bridge, and withdrawal route with a small amount.
- Confirm positions and trade history after any interrupted order.
- Contact Novrinex Support with the Novrinex order identifier and transaction hash when reporting execution issues.