Architecture Overview

Notional separates where trades execute from where margin is accounted for. External exchanges provide liquidity and execution. Notional keeps the account records: recognized collateral, pool-financed exchange margin, debt, account health, and withdrawal eligibility all resolve through the Notional ledger and risk engine. The shared USDC pool is what turns recognized collateral into usable exchange margin. Liquidity providers supply that pool; traders borrow from it when a position needs more exchange margin than their own USDC balance provides. Protocol caps limit how much credit the pool can extend. The result is one margin account above multiple exchanges, instead of separate collateral fragments trapped at each exchange.

​

Ledger and Risk Engine

External exchanges handle whether an order fills and which exchange rules apply. Notional applies the account and risk consequences of that execution. The ledger is the authoritative balance sheet. It records collateral, debt, open positions, funding, realized PnL, withdrawable balances, and the execution attributed to each account. The risk engine applies the same margin checks, credit limits, liquidation health, and withdrawal safety rules across markets and exchanges. This is what keeps margin from fragmenting. A user does not need one isolated margin account per market or per exchange. Notional can recognize collateral once, extend credit against it once, and apply risk controls to the whole account.

​

Fast State, Final State, and Bounded Authority

Trading state updates on the fast path, with roughly 30ms latency. If a fill happens, Notional updates positions, PnL, margin health, and liquidation monitoring without waiting for withdrawal finality. Custody-sensitive actions use final state. A withdrawal is accepted into the ledger as pending immediately, but funds are not sent to the account on the destination exchange until the configured withdrawal delay has elapsed and release checks pass. The current configured delay is 4 minutes, after which the queue service checks ready withdrawals on a short poll interval. The practical rule: trading can update before withdrawable balance updates. That delay is what gives Notional time to reconcile exchange execution, re-check account health, and block unsafe withdrawals before funds leave. The fast path is deliberately bounded. The low-latency operator path can place and cancel orders, receive fills, update account state, and start liquidations. It cannot freely withdraw user funds, move treasury assets, or change protocol parameters. The fast path is also constrained by collateral haircuts, debt caps, utilization caps, protocol leverage targets, open-interest caps, concentration limits, liquidations, and auto-deleveraging.

​

External Execution and Netting

Notional users trade through shared protocol-controlled exchange accounts. To the exchange, Notional can look like one trading account. Inside Notional, every user’s balances, positions, debt, and account health are tracked separately. If one Notional account is long 10 BTC-PERP and another is short 8 BTC-PERP, the exchange sees a net 2 BTC-PERP long position. Notional still records both users’ full positions and liquidates each account based on that account’s own health. This reduces duplicated exchange margin demand, but it also means user-level risk is enforced by Notional rather than delegated to the exchange. Adding an exchange does not change the core model. Notional still keeps one ledger, one credit system, one risk engine, and one reconciliation process. What changes is the external exchange that reports execution back into the ledger.