DiffusalOptionsOrderBook

DiffusalOptionsOrderBook is the on-chain order coordination contract for the limit order flow. The current integration model is signature-first: makers sign typed data, a caller submits the signed payload on-chain, and the contract stores compact order data keyed by orderId.

The current implementation also uses these deployed contracts:

DiffusalOrderBookAuth for typed-data hashing and signature recovery
DiffusalOrderBookCoordinator for signed-order validation and execution-tick preparation
DiffusalOrderBookExecutor for position, collateral, and fee effects

It does three things:

registers signed orders (event + compact storage)
tracks fill/cancel state
orchestrates settlement by order IDs

Key Functions

Signed Placement Entry Points

placeOrderWithSignature(
  bytes32 seriesId,
  uint256 portfolioId,
  bool isBuy,
  uint32 tick,
  uint128 size,
  uint32 expiry,
  uint256 nonce,
  uint256 deadline,
  bytes signature
) returns (bytes32 orderId)

placeOrderWithSeriesParamsWithSignature(
  bytes32 seriesId,
  uint256 portfolioId,
  bool isBuy,
  uint32 tick,
  uint128 size,
  uint32 expiry,
  SeriesParams seriesParams,
  uint256 nonce,
  uint256 deadline,
  bytes signature
) returns (bytes32 orderId)

placeOrderWithSignature(...) is the primary placement path for current integrations. Use placeOrderWithSeriesParamsWithSignature(...) when the signed order may need to lazily create the series on first placement.

Signed Cancel / Invalidate

cancelOrderWithSignature(bytes32 orderId, uint256 nonce, uint256 deadline, bytes signature)

invalidateOrder(OrderTypes.Order order, bytes32 orderId)

cancelOrderWithSignature(...) is the primary cancellation path for signed-order integrations. cancelOrderById(...) remains available as a direct maker-call alternative when the maker wallet is submitting the cancellation transaction itself.

Lower-Level Direct Registration

These direct write functions are still available, but they are not the recommended default integration path for current app or API-driven flows:

registerOrderInPortfolio(...)
registerOrderInPortfolioWithSeriesParams(...)
cancelOrderById(...)

Settle Matches

settleMatchByOrderId(bytes32 makerOrderId, bytes32 takerOrderId, uint128 fillAmount)

Settlement is operator-gated and uses stored order data. It delegates execution logic to DiffusalOrderBookExecutor.

Important Events

OrderRegistered
OrderCancelled
MatchSettled
Trade
FeesCollected
ExecutorUpdated

Core State

orderFilled(orderId) tracks cumulative fill amount
orderPortfolioId(orderId) tracks portfolio routing
storedOrder(orderId) returns compact order metadata
unorderedNonceBitmap(owner, wordPos) tracks consumed signature nonces
executor() returns delegated execution contract

Owner Controls

setOperator(address, bool)
setFees(int256 makerFeeBps, uint256 takerFeeBps)
setFeeCollector(address)
setMarginCalculator(address)
setExecutor(address)

Integration Notes

Primary maker workflow: sign PlaceOrder typed data, then call placeOrderWithSignature(...).
Use the authenticated managed order placement reference when you want the API to return the exact typed_data payload or relay-ready calldata.
If the series may not exist yet, use placeOrderWithSeriesParamsWithSignature(...) so placement and lazy series creation happen atomically.
Direct registration functions remain available for low-level integrations, but the signature-first path is the canonical current flow.
Off-chain matcher should treat orderId as canonical identifier.
Use order registration events for orderbook reconstruction.
Use orderFilled + cancellation/invalidation state for residual size.