Nexwest is a layer-one trading venue built around a fully onchain central limit order book. Every order, cancel, trade, and liquidation is executed by the chain and finalized in a single block. There is no offchain matching engine and no privileged market-maker queue.
The network is designed around one primitive: a shared book. Perpetuals and spot markets settle against the same margin account, the same collateral, and the same risk engine. A trader can move from a spot balance to a hedged perp position without a bridge, a second account, or a custody hop.
Why Nexwest exists
Most onchain venues split execution across an order book, a matching service, and a settlement layer. Each boundary adds latency, a trust assumption, and a different notion of account state. Nexwest collapses those boundaries:
- One state. Orders, positions, collateral, and balances live in the same authenticated state tree.
- One block finality. A filled order is final when the block is committed. There is no soft confirmation window.
- One account. Cross margin, isolated margin, and spot collateral share the same account object.
- One API. REST and WebSocket expose the same objects the chain uses internally.
Read this first
If you are new to the venue, start with the quickstart. If you are integrating, read the API overview and keep the order types page open.
The stack
| Layer | What it does | Where it is documented |
|---|---|---|
| Execution | Deterministic matching, margin, funding, and liquidation | Architecture |
| Consensus | Block production and one-block finality | Architecture |
| Settlement | USDC collateral and cross-margin accounting | Accounts |
| Access | REST, WebSocket, and signed exchange actions | API overview |
| Tooling | SDKs, indexers, oracles, and explorer APIs | Builders |
Core primitives
Markets
The order book
Price-time priority, maker/taker fees, and how the book is reconstructed from chain state.
Risk
Unified margin
Cross and isolated margin, maintenance thresholds, and the transfer margin rule.
Perps
Funding
How the funding rate is computed, capped, and settled every hour.
Liquidity
Vaults
Deposit into strategy vaults or run your own with onchain accounting.
Design principles
Execution is the product
The venue is optimized for the path between a signed order and a committed fill. Consensus, networking, and state access are tuned together rather than assembled from generic components. The result is a book that behaves like a centralized exchange while remaining verifiable onchain.
Risk is transparent
Margin requirements, funding payments, and liquidation prices are deterministic functions of onchain state. The documentation publishes the formulas, the parameters, and the edge cases. If a number appears in the UI, the same number can be derived from the API.
Builders are first-class
Every public object has a typed representation, a stable identifier, and a documented update stream. The API is not a second-class export of an internal service; it is the same interface the official frontend uses.
What you can do
- Trade perpetuals with up to 40x leverage, using cross or isolated margin.
- Provide liquidity through limit orders, vaults, or a market-making integration.
- Stake NXW to validators and earn protocol rewards.
- Build applications that read the book, stream fills, or route orders through builder codes.
- Query every position and balance with the same account address used by the frontend.
Next steps
- Create an account and connect a wallet.
- Deposit USDC and make your first trade.
- Read the API overview if you are integrating.
- Join the builder program if you are shipping a product.