Nexwest is a purpose-built layer one for trading. Consensus, execution, and networking are designed together so that a signed order can be matched, risk-checked, and committed in one block.
The two layers
| Layer | Responsibility | Interface |
|---|---|---|
| Consensus | Orders transactions, produces blocks, finalizes state | NexBFT |
| Execution | Matches orders, updates margin, settles funding and liquidations | Deterministic state transition |
The execution layer is split into two namespaces that share the same state root:
- Core — perpetuals, spot, margin, funding, liquidations, vaults, and staking.
- EVM — a general-purpose contract environment that can read Core state through precompiles and write actions through a system contract.
One chain, two execution surfaces
The EVM is not a separate chain. It is secured by the same validator set and commits in the same block as Core. An EVM transaction and a Core order can be ordered deterministically relative to each other.
Consensus
NexBFT is a pipelined BFT protocol derived from HotStuff. Validators are weighted by staked NXW. A block is final when a quorum of more than two-thirds of stake signs it; there is no probabilistic confirmation window and no reorg.
- Block time: 0.2 seconds median, 0.9 seconds at the 99th percentile.
- Finality: one block.
- Validator set: fixed per epoch; epochs rotate every 100,000 rounds.
- Slashing: available for double-signing and invalid state transitions; not automatic for downtime.
Execution
Every block applies a deterministic transition function:
- Apply consensus-ordered actions.
- Match orders in price-time priority.
- Update positions, margin, and funding.
- Process liquidations and vault transfers.
- Commit the new state root.
The engine is single-threaded per market but markets execute in parallel where they do not touch the same account. This keeps ordering simple while allowing throughput to scale with the number of independent markets.
Latency
End-to-end latency is measured from the moment a signed order is sent to the moment the client receives the committed response.
| Path | Median | p99 |
|---|---|---|
| Co-located client → committed fill | 0.2s | 0.9s |
| Public internet → committed fill | 0.4s | 1.4s |
| REST read → response | 80ms | 250ms |
| WebSocket update → client | 40ms | 120ms |
Throughput
Mainnet currently sustains about 200,000 orders per second. The bottleneck is execution, not consensus; the networking stack is designed to scale further as execution is optimized.
State model
The state is an authenticated Merkle tree. Each account has:
- a nonce,
- a USDC balance,
- an optional spot balance map,
- open orders,
- cross and isolated positions,
- vault and staking entries.
The API exposes the same objects. There is no separate indexer required to answer “what is my position?”; the answer is a state proof away.