Protocol interfaces
Applications connect to Novrinex through a versioned protocol interface. The interface covers the complete path from constructing a signed action to reading its committed result.
State-changing messages are submitted as transactions. Direct queries read the network’s authoritative state. Events let indexers and applications follow each change in order as blocks are committed.
Transactions
Section titled “Transactions”Trading messages place and cancel orders, move collateral, and manage trading keys. Market-operation messages publish oracle observations, apply funding, cover deficits, and trigger liquidations. Builder messages create exchanges and markets, adjust bounded caps, manage pauses, and open builder-domain subaccounts.
Every message names its signer and the relevant account, subaccount, market, order, or builder object. Financial requests include a durable request ID. A client can retry an identical payload and recover the stored result without creating a second action.
Messages are defined with versioned Protobuf schemas, giving supported clients the same field meanings and integer precision across languages.
Authoritative queries
Section titled “Authoritative queries”A node can return market parameters, an order-book snapshot, an individual order, subaccount balances and positions, request receipts, builder exchanges, and builder markets.
These direct queries read committed network state. A REST response or WebSocket update produced by an indexer includes its block height and cursor so the application can determine which committed state it represents.
Order simulation
Section titled “Order simulation”Simulation runs an order against a copy of current Core state without committing it. It follows the same authorization, oracle, risk-domain, margin, matching, settlement, and final reconciliation path as execution.
The result states whether the order would be accepted and reports the reason, required margin, and available collateral. Applications can use it for order review and clear rejection messages.
Simulation is a view of a particular state height. The book, mark price, collateral, or market limits can change before the signed transaction reaches a block.
Events
Section titled “Events”Committed events describe order acceptance, resting quantity, cancellations, fills, balance and position changes, oracle prices, funding intervals, liquidations, insurance movements, and builder actions.
Each event carries a schema version and a canonical position in the block. Consumers process known versions explicitly and stop on an unknown one instead of guessing how to interpret changed financial data.
Builder capabilities
Section titled “Builder capabilities”A registered builder can read network state, submit native actions, create parameterized markets, request bounded cap increases, pause owned markets, and receive its configured revenue share.
The capability belongs to the builder exchange and is preserved in network state. It never exposes direct writes to the ledger, margin engine, oracle internals, transaction-ordering policy, or validator process.
Changing the meaning of a transaction, query, event, or builder capability requires an explicit protocol and schema version. Clients can therefore identify the rules that produced any financial record they consume.