Siebly.ioSiebly.io - Cryptocurrency Exchange SDKs
Reference

Execution Modes

Use one EXECUTION_MODE switch for runtime safety boundaries. The goal is to implement live-capable code paths while keeping exchange writes disabled by default.

Mode Contract

Allowed values are PUBLIC|READ_ONLY_PRIVATE|DRY_RUN_PRIVATE|DEMO|TESTNET|LIVE. Use this switch to select runtime capability; use runtime workflows for operational checks before any exchange write.

  • EXECUTION_MODE is the only execution-mode switch. Do not add parallel DRY_RUN, ENABLE_DEMO_TRADING, or ENABLE_LIVE_TRADING switches.
  • EXECUTION_MODE=DRY_RUN_PRIVATE is the default execution mode, where the implementation builds and logs final request objects and reconciliation decisions without submitting to the exchange. Always handle incoming account state events to keep internal account state in sync with exchange state, so the system is ready to execute live if requested by the user.
  • DEMO and TESTNET are write-capable only when the selected exchange supports the selected non-production venue.
  • LIVE is the production write-capable path. Implement it for order-capable prompts, but keep it disabled until explicit configuration and required runtime-workflow checks pass.
  • Use Runtime Workflows for startup readiness, recovery boundaries, and other operational checks.

Dry Run Is Not Paper Trading

DRY_RUN_PRIVATE produces request records. Paper Trading simulates execution side effects.

  • Dry-run output is useful for verifying request shape, rounding, context registration, and submitter gates.
  • Paper trading is useful for strategy evaluation and can model fills, positions, balances, fees, and PnL.
  • A project can have both, but they are different runtime behaviors and should be named separately.
  • A robust and reliable paper trading system is a major undertaking. It is not necessary for dry-run request planning, and it is not a substitute for testing with real exchange state and order interactions in demo, testnet, or live modes.