Skip to main content
The shape of it: rest a bid on a few venues, and the moment one gets hit, sell the same size across the deepest venues you have. You earn the spread; SORY finds the best place to take the other side. Everything here uses one client, because it is one symbol.

Why it is only this long

The order updates itself

order.filled is live. You hold the object place() gave you and read it — no lookup, no bookkeeping.

The hedge picks its own venue

A market order across HEDGE_ON walks the merged book and takes the cheapest liquidity, wherever it is.

Fees are in the comparison

fee_offset on the hedge venues means “cheapest” accounts for what each one charges you.

Dead venues drop out

A venue that stops publishing leaves the book on its own, so the hedge never routes into a stale price.
Keep the two sets apart. If you rest a bid on a venue and then send a sell there, you can trade against yourself. Some venues prevent it on the same account and some do not, so the reliable fix is the one above: hedge only on venues you are not quoting on.Overlapping them is fine only if you have confirmed that venue’s self-trade prevention yourself.

Picking up after a restart

SORY keeps nothing on disk. Ask the venues what you still have working:
Cancel them and re-quote, or adopt them — either way you are looking at the truth rather than a file that might be stale.

Before you point it at real money

Every path runs — quoting, the fill loop, routing the hedge, per-venue rounding — and nothing is sent. Watch the printed hedges for a while first.
post_only and time_in_force are refused on any venue that has not proven it supports them, rather than sent without. Check the venues table before you rely on either.