GitHub: https://github.com/abrownfox0/abrownfox001-twap60-prediction-trigger-system
YouTube walkthrough: https://www.youtube.com/watch?v=XzhugRL6BV4
Live profile: https://polymarket.com/@abrownfox001
Part 2 said settlement should stay pinned to 60s Chainlink TWAP even if the matching engine is replaced.
Part 3 is the layer that will move: how a taker order gets delayed, accepted, and filled.
1. Two Clocks Are About to Coexist
Clock A — live now
- crypto taker delay raised to 150ms on Sept 4
- delay-lock: once pending, cancel is not a free undo
- volume-tier CLOB rate limits
- current matching stack still carrying public “tech debt” comments
Clock B — expected later
- matching engine rewrite in Rust, targeted mid-to-late Q4
- early vendor/team talk of much faster p99 and much higher order/sec
- possible new ack / reject / websocket semantics
A 5m bot that treats these as one number will mis-attribute every fill.
2. What 150ms Means for a Mid-Band Engine
@abrownfox001 is not a last-look wick sniper. It still takes in the 45–55¢ band.
150ms still taxes the loop:
- the book can move after the decision and before the delay expires
- “scratch now” is not instant
- fill-minus-signal must be logged separately from TWAP-path error
- local RTT work hits a ceiling
TWAP60 already killed the last-tick thesis.
The longer taker delay kills the leftover “cancel if the next millisecond disagrees” habit.
3. What a Q4 CLOB Rewrite Could Change
If a new engine lands, expect the distribution of latency to move even if the official delay stays 150ms.
Things that can change without a strategy rewrite:
- p50 / p99 ack time
- open-order read lag
- cancel success rate
- 429 / reject codes
- websocket snapshot vs delta behavior
- how
Retry-Afteris applied
Things that should not change unless rules change:
- TWAP60 as the paid series
- 5m slot clock
- mid-band entry discipline
- scratch-versus-redeem state machine
If you buried delay assumptions inside signal.ts, the cutover will corrupt the model. Keep delay math in clob.ts / config.
4. Measurements That Survive a Rewrite
Log these on every live slot before Q4:
t_signal
t_submit
t_ack
t_fill
quoted_ask
fill_px
delay_ms_assumed
rate_limit_hits
scratch_spread
twap_open / twap_now
Then you can answer, after a cutover:
- Did
P(up)get worse? - Or did fill quality get worse?
- Or did RTDS go stale?
- Or did the new engine change p99 only?
Without that split, every outage becomes “the strategy died.”
5. Rate Limits Are Part of Latency
Volume tiers already punish cancel storms.
A rewrite that raises capacity does not give you permission to spray. It may even expose sloppy loops that the old engine queued into mush.
Keep:
- idempotent client order ids
-
Retry-Afterhandling - per-slot order caps
- no panic-cancel as risk management
6. What I Am Changing Now vs Later
Now
-
taker_delay_ms = 150in config - separate signal / submit / fill timestamps
- retune scratch on post-Sept 4 data
- refuse thin-book “breakeven” fantasies
When a new CLOB is announced live
- freeze strategy weights
- swap only the execution adapter
- paper or micro-size through the first week
- compare the measurement row above against the August/September baseline
Not now
- rewriting
P(up)because a benchmark slide said 10–20× p99 - turning the 5m bot into a maker-only book because delay exists
7. What Part 4 Covers
Latency is still a 5m CLOB problem.
Part 4 splits the product surface so Combos, US rails, and builder tooling do not get mixed into that CLOB adapter.
Links
- Repo: https://github.com/abrownfox0/abrownfox001-twap60-prediction-trigger-system
- Video: https://www.youtube.com/watch?v=XzhugRL6BV4
- Live activity: https://polymarket.com/@abrownfox001?tab=activity
Not financial advice. Delay values and engine rollouts can move — confirm against live docs.
If you have more questions, please feel free to contact me at any time: https://t.me/abrownfox001
My Polymarket Activity: https://polymarket.com/@abrownfox001?tab=activity
#Polymarket #CLOB #TradingBot #BTC #TWAP #AlgoTrading #PredictionMarkets
Top comments (0)