DEV Community

ABROWNFOX001
ABROWNFOX001

Posted on

How I’m Preparing My Polymarket Bot for Combos (RFQ, Multi-Leg Risk & Collateral Return)

Polymarket Combos introduce a new execution venue: multi-leg positions priced through RFQ instead of the normal CLOB.

My core system is still focused on BTC 5-minute directional trading under Chainlink TWAP. I’m not turning it into a sports parlay bot overnight. But ignoring Combos entirely would be a mistake — the position model, capital mechanics, and RFQ flow will matter more as the product expands.

Here’s how I’m preparing the stack.

  1. Treat Combos as a Separate Execution Venue

The first design decision: do not bolt Combos into the existing CLOB order path.

CLOB logic assumes:
Continuous book
Resting or taker orders
Single-market conditionId / token IDs

Combos assume:
RFQ request → short quote window → acceptance → optional Last Look
Derived multi-leg YES/NO position IDs
Different timing and failure modes

So I’m isolating Combo support behind its own module:

execution/
clob/ # existing BTC 5m path
combos/ # new RFQ client + state machine
positions/ # unified position & residual tracking

This keeps the TWAP directional engine clean while letting me experiment with Combos without contaminating core slot logic.

  1. RFQ State Machine First

The timing constraints are strict:

~400 ms quote submission window (makers)
~10 s user acceptance window
~1 s Last Look confirmation

I’m implementing an explicit state machine:

Idle
→ RequestCreated
→ QuotesReceived
→ QuoteSelected
→ AcceptanceSigned
→ LastLookPending (optional)
→ Executed / Rejected / Expired

Every transition is logged with timestamps. If a step misses its window, the flow terminates cleanly instead of retrying blindly.

For a directional BTC bot this is mostly defensive infrastructure today. For any future multi-leg or sports quoting work, it is mandatory.

  1. Position Accounting for Multi-Leg Exposure

Single-market bots can think in terms of one Up/Down pair per slot.

Combos require:
Leg-level tracking
Derived Combo YES/NO IDs
Residual positions after partial resolution or collateral return

I’m extending the position ledger so every Combo is stored as:

Parent Combo ID
List of legs (market + side)
Current residual exposure
Locked vs returned collateral

Without this, PnL and risk reports become fiction as soon as legs start resolving at different times.

  1. Collateral Return Awareness

Quoting or holding Combos can lock pUSD across many related legs.

Collateral Return frees capital that is no longer required while preserving unmatched residual risk. I’m adding:

Periodic scan for returnable exposure
Plan inspection before execution
Confirmation loop until truncated: false
Clear separation between returned pUSD and remaining residual positions

Even if I don’t quote Combos heavily at first, understanding this flow is necessary before sizing any multi-leg inventory.

  1. Risk Limits Specific to Multi-Leg Products

I’m adding Combo-specific guards:

Max legs per Combo
Max total notional in open Combos
Max correlation / overlapping legs across Combos
Hard block on entering Combos when BTC 5m exposure is already high
Separate daily loss budget for experimental Combo flow

The goal is to prevent a side experiment from damaging the main TWAP strategy’s capital.

  1. What I’m Explicitly Not Doing Yet

Full automated sports Combo generation
Blind copying of multi-leg retail flow
Treating RFQ quotes as “fair” without my own pricing check
Merging Combo PnL into the BTC 5m performance metrics

Combos are still a different product with different edge sources and different liquidity behavior. I’m preparing the plumbing first.

  1. Practical Preparation Checklist

[x] Separate Combo execution module
[x] RFQ state machine with hard timeouts
[x] Extended position ledger (legs + residuals)
[ ] Collateral Return plan/execute loop tested on small size
[ ] Unified risk view: BTC 5m + Combo exposure
[ ] Logging that can reconstruct any Combo decision path
[ ] Feature flag so Combo trading can be disabled instantly

  1. Why This Matters for a TWAP-Focused Bot

Even if 95% of my volume stays on BTC 5-minute markets, platform changes compound:

New position types appear in the same wallet
Capital efficiency features change how much is truly available
Future markets may support combinatorial structures beyond sports
RFQ-style flows may show up in other products

Preparing cleanly now is cheaper than refactoring under pressure later.

Summary

I’m not rewriting the core directional engine for Combos.

I’m doing the boring but necessary work:

Isolate the new venue
Implement the RFQ lifecycle correctly
Track multi-leg and residual risk properly
Respect Collateral Return
Keep the main BTC TWAP strategy protected behind hard limits

That’s how I’m preparing for the change — infrastructure first, experiments second, size last.

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 #Combos #RFQ #TradingBot #MarketMaking #AlgoTrading #PredictionMarkets

Top comments (0)