Skip to content

feat(order_object): add native support for CONDITIONAL orders#77

Open
deividuvi wants to merge 2 commits intox10xchange:starknetfrom
deividuvi:feature/conditional-orders-support
Open

feat(order_object): add native support for CONDITIONAL orders#77
deividuvi wants to merge 2 commits intox10xchange:starknetfrom
deividuvi:feature/conditional-orders-support

Conversation

@deividuvi
Copy link
Copy Markdown

Summary

This PR adds first-class support for CONDITIONAL orders to the Python SDK by extending order_object.py.

The goal is to make conditional / stop orders a native SDK feature instead of relying on TPSL workarounds.

Changes

  • Introduced native OrderType.CONDITIONAL support
  • Added OrderConditionalTriggerParam for conditional trigger configuration
  • Updated create_order_object() to:
    • Validate conditional-specific parameters
    • Correctly serialize conditional triggers into the order payload
  • Preserved full backward compatibility with existing order types (LIMIT, MARKET, TPSL)

Motivation

Conditional orders are the primary mechanism used by the Extended exchange UI for stop-loss and protective exits.
Without native support, SDK users must rely on TPSL parent orders, which introduces complexity and edge cases.

This change enables:

  • Clean reduce-only stop-loss orders
  • Break-even protection
  • Trailing stop engines built directly on conditional orders

Notes

  • No breaking changes
  • No changes to public APIs outside order_object.py
  • Tested in live trading conditions on Extended mainnet

@deividuvi
Copy link
Copy Markdown
Author

Context / Motivation

In several trading flows (e.g. stop-loss, break-even, trailing exits), orders need to be created after an initial position is already open.

The current implementation in order_object.py hard-codes OrderType.LIMIT when instantiating NewOrderModel, which prevents creating OrderType.CONDITIONAL orders through the same path — even though the exchange natively supports them.

What this change does

This patch removes the hard-coded order type and allows NewOrderModel to accept and propagate any order type supported by the exchange (including CONDITIONAL), without altering existing behavior for limit/market orders.

Why it helps

This makes the SDK compatible with a broader class of strategies (e.g. post-entry SLs, trailing stops, risk-management automation) while remaining backward-compatible with existing usage.

Here you can see the sample code of the original file with the hardcode limitation:
order = NewOrderModel(
id=order_id,
market=market.name,
type=OrderType.LIMIT,
side=side,
qty=settlement_data.synthetic_amount_human.value,
price=price,
post_only=post_only,
time_in_force=time_in_force,
expiry_epoch_millis=to_epoch_millis(expire_time),
fee=fee_rate,
self_trade_protection_level=self_trade_protection_level,
nonce=Decimal(nonce),
cancel_id=previous_order_external_id,
settlement=settlement_data.settlement,
tp_sl_type=tp_sl_type,
take_profit=tp_trigger_model,
stop_loss=sl_trigger_model,
debugging_amounts=settlement_data.debugging_amounts,
builderFee=builder_fee,
builderId=builder_id,
reduce_only=reduce_only,
)

@deividuvi
Copy link
Copy Markdown
Author

Hi! I resolved the merge conflicts with the latest starknet branch and updated the implementation accordingly.

Everything should now be aligned with the current codebase, including TPSL handling and conditional orders support.

Could you please take another look?

@alexex10
Copy link
Copy Markdown
Contributor

hey. thx for the update! we will review it shortly. pls note that we're in the process of reworking the SDK (which also includes adding support for missing order type), so if we will identify misalignments between your PR and new approach/structure it might be easier for us to push our own implementation to avoid unnecessary iterations.

@deividuvi
Copy link
Copy Markdown
Author

Hi Alex, no worries. I´ll be happy to use your version when available. Keep it up!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants