Order Type

Dinari abstracts most market-structure complexity behind a single set of order-placement APIs. This page explains the order types Dinari supports, the fields each requires, and how order type affects pricing and order controls.

For time-in-force behavior, see Time in Force. For how orders behave outside regular U.S. market hours, see Market Hours & Weekend Orders.

Order types

Dinari supports two order types across every order-placement surface and every asset type.

The order_type enum is exactly ["MARKET", "LIMIT"]. There are no stop, stop-limit, or trailing order types.

order_side is either BUY or SELL.

Where orders are placed

Every order flows through the same v2 OrderRequest → Order model. Creating an order produces an OrderRequest, which Dinari submits on-chain to create an Order. There are three ways to create one:

• Managed Orders — for accounts using a Dinari-managed wallet.
  POST /api/v2/accounts/{account_id}/order_requests/{market_buy | market_sell | limit_buy | limit_sell}
• Proxied Orders (EIP-155) — for accounts using a self-custodied wallet. Generate a permit, sign it, then either submit it on-chain yourself or have Dinari submit it for you.
  POST /api/v2/accounts/{account_id}/order_requests/eip155/permit
POST /api/v2/accounts/{account_id}/order_requests/eip155/submit
• Direct smart-contract calls — accounts using self-custodied wallets may also create and fulfill Orders by calling Dinari's EVM smart contracts directly.

Every order endpoint accepts either a single-name dShare (stock_id) or a Dinari Alloy (alloy_id). The flagship Alloy is the S&P Digital Markets 50 Index Token (SPDM), a rules-based index combining 35 U.S. public equities tied to digital markets with 15 leading digital assets.

Required fields by order type

Because not every order carries both a quantity and a notional value before it executes, each order shape requires different size fields.

Marketable limit pricing

When a market order cannot be routed as a plain market instruction — for example, outside regular U.S. market hours — Dinari converts it into a marketable limit order so it can route to available liquidity:

• Buys are priced at the latest ASK.
• Sells are priced at the latest BID.

Because the result is a limit order, it may fill fully, partially, or not at all. For market buys, any unfilled remainder is refunded. See Market Hours & Weekend Orders for exactly when this conversion happens.

Order controls and placement policy

Partner-configurable size controls bind differently depending on order type, because not every order carries both quantity and notional before it executes:

• A quantity cap does not constrain a market buy, since quantity is not known until the order fills.
• A notional cap does not constrain a market sell, since notional is not known until the order fills.
• Limit orders carry both a quantity and a derivable notional, so both caps apply.

If you expose size controls to your users, account for which cap actually binds each order type rather than assuming a single cap covers every order shape.

API reference

Create order — Managed wallet

Optional fields: recipient_account_id, client_order_id, payment_token_address, fee.

// Managed orders (Dinari-managed wallet)
await client.v2.accounts.orderRequests.createMarketBuy(accountID, {
  stock_id: stockID,
  payment_amount: 150.0,
});

await client.v2.accounts.orderRequests.createLimitBuy(accountID, {
  stock_id: stockID,
  asset_quantity: 1,
  limit_price: 1.5,
});

Create order — Proxied / EIP-155

Eip155OrderRequestPermitInput requires: chain_id, order_side, order_tif, order_type, payment_token.

Conditional fields: payment_token_quantity (market buys), asset_token_quantity (limit orders and market sells), limit_price (limit orders), and one of stock_id / token_id / alloy_id.

In the U.S. jurisdiction, orders must use USDC (live) or MockUSD (sandbox); the request cannot specify a custom payment_token.

resp = client.v2.accounts.order_requests.eip155.create_permit(
    account_id,
    chain_id="eip155:11155111",
    order_side="BUY",
    order_tif="DAY",
    order_type="MARKET",
    payment_token="0x...",
    payment_token_quantity=1.5,
    stock_id=stock_id,
)

Enums

Read an order

GET /api/v2/accounts/{account_id}/orders/{order_id}

Returns the Order, including order_type, order_tif, limit_price, asset_token_quantity, payment_token_quantity, fee, chain_id, transaction hashes, and order_request_id. Use the associated OrderFulfillment records to reconcile partial fills.

Cancel an order

POST .../orders/{order_id}/cancellation

Orders in PENDING_FILL, PENDING_ESCROW, FILLED, REJECTED, or CANCELLED cannot be cancelled. Cancellation is neither guaranteed nor immediate — confirm the result with Get Order by ID.

Timeouts

Order creation that cannot be submitted within roughly 15 seconds is auto-rejected with reject_message: "Order creation exceeded timeout. Please try again." This guards against stale pricing and can occur more often for managed wallets submitting many orders in a short window while awaiting signatures.