Application integration
A Novrinex application gives traders a way to interact with shared markets. It can shape the order-entry experience and organize market data, but the signed transaction and committed network state remain the basis of every financial result.
The Novrinex exchange follows this model itself. Its interface and backend use the same protocol available to another compatible application.
Constructing an action
Section titled “Constructing an action”The application turns a trader’s instruction into a versioned protocol message. The fields with financial meaning remain visible to the signer: account, subaccount, market, direction, price, quantity, trading key, nonce, and request ID.
A trading key can authorize the application to place and cancel orders within a narrow scope. Withdrawal and key-management permissions remain separate.
Estimating the result
Section titled “Estimating the result”Before signing, the application can simulate the order against a specific network height. Simulation runs the normal authorization, oracle, risk, margin, matching, settlement, and reconciliation checks without changing state.
The result reports acceptance or rejection, the reason, required margin, and available collateral. It is an estimate because the book, prices, or account can change before the transaction is included.
Submission and finality
Section titled “Submission and finality”The signed transaction is submitted to a healthy RPC node and propagated across the network. Receipt means the transaction entered the submission path; it does not mean the order traded.
The authoritative result arrives after validators include and finalize it in a block. The request ID connects the original instruction with its receipt, events, order, and fills.
The interface should distinguish received, pending, accepted, partially filled, resting, rejected, cancelled, and expired states. A successful network submission must never be displayed as an execution.
Account and market data
Section titled “Account and market data”Indexers consume committed blocks and create the views an application needs for market history and portfolios. REST endpoints serve snapshots and searches. WebSocket connections begin with a snapshot and then stream changes in canonical order.
Every view includes its block height or cursor. The application can therefore tell whether a displayed balance and a market update describe the same point in network history.
Reconciliation
Section titled “Reconciliation”Connections fail, messages arrive late, and local caches become stale. The application periodically compares its projection with a trusted indexer or direct node query.
After detecting a gap, it stops applying later updates until it has replayed the missing range or loaded a fresh snapshot. If the local balance, position, or order conflicts with committed state, the network result wins.
This recovery rule also applies after an interrupted submission. The application looks up the durable request receipt before asking the trader to try again. An exact retry recovers the recorded result without creating a duplicate order.