Skip to main content

Debug SafetyFailure responses

  1. Capture the exact safety_failure variant before changing anything.
  2. Classify the failure as identity, request-shape, market-constraint, or account-state related.
  3. Repair the specific root cause rather than blindly rebuilding and resubmitting.
  4. Re-sign and re-encrypt the request when the payload changes.
  5. Recheck the resulting order, strategy, or trader state after the corrected request succeeds.

Classify the failure first

Failure familyTypical variantsFirst thing to inspect
identity or request-auth defectSignatureRecoveryMismatchsigning inputs, trader identity, session material
product or order-shape defectUnsupportedMarket, PriceNotMultipleOfTickSize, OrderAmountNotMultipleOfMinOrderSize, OrderTypeIncompatibleWithPricesymbol, price, amount, order-type fields
risk and margin defectNotEnoughCollateral, OMFLessThanIMF, MaxOrderNotionalBreached, MaxTakerPriceDeviationBreachedcollateral, leverage, notional size, mark-price context
account or strategy-state defectTraderNotFound, NoStrategies, StrategyNotFound, TooManyOrders, OrderNotFoundcurrent trader, strategy, and open-order state

Repair by class

  1. For signing failures, re-read Request Signing Reference and verify the trader, domain, nonce, timestamp, and optional session payload.
  2. For encryption-adjacent request handling, re-read Request Encryption Reference and rebuild the encrypted payload after the underlying request is fixed.
  3. For market-shape failures, re-read Product and Trading Specifications and Trading Safeties and Guards.
  4. For margin and solvency failures, re-read Margin Requirements and Price Feeds and Mark Price Inputs.
  5. For order-state failures, inspect the current order and account events before deciding whether the request is stale, duplicate, or aimed at the wrong strategy.

Do not conflate these with other error classes

  • SafetyFailure means the request was understood but rejected by validation or risk guards
  • replay-window and timestamp failures belong to the broader error system, not the safety_failure enum
  • service, rate-limit, and encryption failures have different recovery posture even if they appear during the same workflow

After you fix the root cause

  1. Rebuild the request payload.
  2. Re-sign it.
  3. Re-encrypt it when the submission path requires encrypted transport.
  4. Submit once and inspect the resulting event trail before deciding whether more repair is needed.

Boundary rule

This page is for structured SafetyFailure triage only. Use the broader error guides when the response class is not SafetyFailure.

Next routes

Last modified on April 12, 2026