# Features

# Amplified Liquidity

The Nekuti matching engine supports multi-way matching between related instruments. This means that whenever an order is created on an instrument, it can match with orders on related markets, allowing liquidity to be amplified across all related instruments.

# Instrument Types

• Spot
• Futures
• Expiry Type
• Termed
• Perpetual

# Settlement Type

• Base currency settled (Linear)
• Quote currency settled (Inverse)
• Any other currency settled (Quanto)

# Supported order types

• Market
• Limit [default]
• Stop (Market or Limit [default if stop price is present])
• MarkedPrice
• LastPrice
• IndexPrice
• LastWithinMark

# Time in Force

• Day
• GoodTillCancel [default]
• ImmediateOrCancel
• FillOrKill

# Fill Type

• Reduce Only
• Post only
• Close
• None [default]

# Visibility Type

• Visible [default]
• Hidden
• Iceberg

# Risk Limit

Users can control their risk limits for each instrument. Higher risk limits can trigger increased margin requirements, subject to margin configuration. The engine rejects an order if it would result in the total risk on this instrument being higher than the current risk limit.

# Margin Calculation

Initial margin is the margin required for an order to be approved. While the order is in the order book, the initial margin requirement for this order is “locked”, meaning that this quantity cannot be withdrawn from the asset balance nor can it be used to provide margin for another order or leveraged instrument.

For unleveraged spots, this is simply the amount of the base currency needed for the order (bought or sold).

For leveraged futures, this is the notional value amount of the order in the settlement currency divided by the maximum permitted leverage ratio.

Additionally for leveraged futures, existing positions lock up a portion of the balance for maintenance margin. The calculation of maintenance margin takes into account both the cost of the position (increases required margin) and the potential losses incurred by the position at any given time (reduces available balance).

Opposite positions in the market do not cancel each other in margin calculations. We always consider the maximum margin requirement between the long and the short stakes as the overall margin requirement for an account.

Positive unrealised p&l incurred by open positions also do not increase the available balance.

The engine rejects an order that would bring the overall margin requirement above the available balance.

Once the market moves past the price at which an account balance + unrealised losses is equal to the margin requirement, a liquidation workflow is triggered.

# Liquidation

The liquidation procedure involves 4 steps but can stop after each step if the account’s balance becomes sufficient to cover the margin requirements of the remaining orders and positions.

If the Risk Limit for any instrument can be lowered such that the maintenance margin level is reduced, the engine will automatically do so, then check if the account is solvent with the new maintenance margin

If there are open orders, cancel them, then check if the account is solvent

If there are positions that can be closed on the exchange in a way that allows reducing the risk limit to bring the account back to solvency, then close them.

Transfer all remaining positions and balances to the insurance fund account (or liquidation account)

# Persistence / Recovery

The command stream is persisted in a binary format in one or several pre-configured locations. When the application restarts, it first reads and replays the existing command files in that location in chronological order. This means that by the time the application is ready to accept new inputs, it’s in the exact same state as it was when it last went down.

Additionally, the application generates snapshots of its state at pre-configured intervals. If snapshots are present, the application will first find the latest snapshot and reinflate the state from that snapshot, before reading the command files that came after this last snapshot. Snapshotting greatly speeds up the engine startup time. Snapshots are generated in parallel by a secondary “read-model” in order to avoid stop-the-world events on the core engine.