Delaying orders is not the freedom Polymarket embodies
Delaying orders is not the freedom Polymarket embodies
2026-06-03 · Polymarket · 14 条相关讨论
Delaying orders is not the freedom Polymarket embodies
Delaying orders is not the freedom Polymarket embodies
"Sending the same order again while it's in the window will be rejected. "
"Sending the same order again while it's in the window will be rejected. "
YES thank you <@707597210845446214> This patches the most absolute biggest bug you have had!
YES thank you <@707597210845446214> This patches the most absolute biggest bug you have had!
Finally the taker delay will actually work
Finally the taker delay will actually work
I’m normally a cynic, but this is a major change and update that fixes SO SO much
I’m normally a cynic, but this is a major change and update that fixes SO SO much
You could previously just keep hot orders in the delay queue and cancel them, effectively bypassing the delay. This fixes that
You could previously just keep hot orders in the delay queue and cancel them, effectively bypassing the delay. This fixes that
🤑🤑🤑🤑🤑🤑
🤑🤑🤑🤑🤑🤑
It’s not mystical. You could just send orders before , and cancel when it was in the delay loop. Do that every 5 ms, and you always have a “primed” order that’s already sat in the delay loop for 245 of the 250 ms
It’s not mystical. You could just send orders before , and cancel when it was in the delay loop. Do that every 5 ms, and you always have a “primed” order that’s already sat in the delay loop for 245 of the 250 ms
Hi, polymarket team Thanks for the update — quick clarification on the new 250ms taker delay behavior: Once an API taker order enters the delay window and the 250ms period is over, is matching priority still based on when the order originally entered the delay window, or are orders within the same delay window processed together under a different priority rule? Just trying to better understand the updated order lifecycle behavior. Thanks!
Hi, polymarket team Thanks for the update — quick clarification on the new 250ms taker delay behavior: Once an API taker order enters the delay window and the 250ms period is over, is matching priority still based on when the order originally entered the delay window, or are orders within the same delay window processed together under a different priority rule? Just trying to better understand the updated order lifecycle behavior. Thanks!
I am confusing about the taker delay update. What happen if orderbook changes while waiting for 250ms pending? Orders will be executed against the updated orderbook?
I am confusing about the taker delay update. What happen if orderbook changes while waiting for 250ms pending? Orders will be executed against the updated orderbook?
what the fix?
what the fix?
so new clob update fix taker delay bypass finally? <:Bidensmile:1040247925420339251>
so new clob update fix taker delay bypass finally? <:Bidensmile:1040247925420339251>
giving a delayed status for a 250ms delay would be cringe and gay
giving a delayed status for a 250ms delay would be cringe and gay
asked before be but also not clear.. is intial buy ask remain the same? it will just take 250ms to process?
asked before be but also not clear.. is intial buy ask remain the same? it will just take 250ms to process?