Polytraders Dev Guide
internal
v3 spine Phase 1 · Shared contracts 9 demo-wired · 0 shadow-ready · 0 production-live · 100 pending · 109 total 15/33 infra tasks the plan status board
HomeBy LayerExecution2.15 OrderAmendCancelManager

2.15 OrderAmendCancelManager

Execution ExecutionUtility AmendCancel PLANNED Spec ready capital · Direct P5 · Execution rails pending stub

Owns every amend and cancel operation against the CLOB for orders Polytraders has placed. Strategies do not cancel directly — they emit an OrderAdjustment intent which this bot validates, sequences, and submits via the EIP-712 v2 envelope. Maintains a strict monotonic intent sequence per order so cancels can never race amends.

v3 readiness

Docs27/27
donehow scored
Impl0/15
pendinghow scored
Backtest0/4
pendinghow scored
Runtime0/8
pendinghow scored

A bot is done when all four scores are. What does done mean?

1. Bot Identity

LayerExecution  Execution
Bot classExecutionUtility
AuthorityAmendCancel
StatusPLANNED
ReadinessSpec ready
Runs before
Runs afterexec.order_lifecycle_manager
Applies toContinuous
Default modeshadow
User-visibleYes
Developer ownerExecution pod

Operational profile

OwnershipExecution pod · on-call exec-oncall · #polytraders-exec · escalates to Head of Execution · P1
Latency budgetp50: 25ms · p99: 250ms
Modes supportedoffshadowadvisoryenforcedquarantine
Data freshnessmax_market_data_age_ms=5000 · max_orderbook_age_ms=5000 · on stale → Reject the adjustment with EXEC_AMEND_STALE_VIEW.
Human overrideyes · by Execution on-call · logs EXEC_AMEND_OVERRIDE · time-bound: Per incident · scope: Single order_id · second approval required

2. Purpose

Owns every amend and cancel operation against the CLOB for orders Polytraders has placed. Strategies do not cancel directly — they emit an OrderAdjustment intent which this bot validates, sequences, and submits via the EIP-712 v2 envelope. Maintains a strict monotonic intent sequence per order so cancels can never race amends.

3. Why This Bot Matters

  • Race conditions on cancel/amend

    Without a single sequencer, two strategies can race each other to amend the same order, producing inconsistent CLOB state.

  • Phantom cancels

    A cancel that fails silently leaves an order resting that strategy code believes has been killed; mismatched state causes self-trades and over-positioning.

  • Amend bypasses risk

    An 'amend size from 100 to 500' looks like a cancel-and-place but bypasses Risk if not routed through this bot.

No worked examples on this bot yet. Worked examples are optional but strongly recommended — they turn an abstract failure mode into something a developer can verify in a fixture.

4. Required Polymarket Inputs

InputSourceRequired?Use
CLOB v2 amend/cancel endpointsCLOBYesThe actual targets for the action.
Order ack/reject eventsWebSocketYesConfirm or fail each operation.

5. Required Internal Inputs

InputSourceRequired?Use
OrderAdjustment intentStrategy or runbookYesThe request to modify or cancel an order.
OrderLifecycleManager stateexec.order_lifecycle_managerYesSource of truth for order status before and after.
RiskVote pipelineRisk podYesAmends with non-zero new_size must pass Risk like any other OrderIntent.

6. Parameter Guide

ParameterDefaultWarningHardWhat it controls
amend_timeout_ms15001500ms3000msMaximum wait for an amend ack before retrying or escalating.
cancel_timeout_ms1500Maximum wait for a cancel ack before retrying or escalating.
max_inflight_per_order112Maximum concurrent amend/cancel operations per single order_id.

7. Detailed Parameter Instructions

amend_timeout_ms

What it means

Maximum wait for an amend ack before retrying or escalating.

Default

{ "amend_timeout_ms": 1500 }

Why this default matters

1.5s covers normal CLOB latency; longer timeouts hide real outages.

Threshold logic

ConditionAction
≤ 1500msNormal
> 1500msTIMEOUT — retry once, then escalate

Developer check

if (now - sent > p.amend_timeout_ms) retry_or_escalate();

User-facing English

We could not change this order in time and rolled it back.

cancel_timeout_ms

What it means

Maximum wait for a cancel ack before retrying or escalating.

Default

{ "cancel_timeout_ms": 1500 }

Why this default matters

Same reasoning as amend timeout.

Threshold logic

ConditionAction
≤ 1500msNormal
> 1500msTIMEOUT — retry once, then escalate

Developer check

if (now - sent > p.cancel_timeout_ms) retry_or_escalate();

User-facing English

We could not cancel this order in time.

max_inflight_per_order

What it means

Maximum concurrent amend/cancel operations per single order_id.

Default

{ "max_inflight_per_order": 1 }

Why this default matters

1 enforces strict serialisation per order — required to keep state consistent.

Threshold logic

ConditionAction
1Default — strict serialisation

Developer check

if (inflight[order_id] >= p.max_inflight_per_order) reject_intent('EXEC_AMEND_INFLIGHT');

User-facing English

(Internal.)

8. Default Configuration

{
  "amend_timeout_ms": 1500,
  "cancel_timeout_ms": 1500,
  "max_inflight_per_order": 1
}

9. Implementation Flow

— not yet authored —

10. Reference Implementation

Pseudocode is language-agnostic. FETCH = read input. EMIT = produce output. IF/THEN/ELSE = decision. Translate directly to TypeScript, Python, Go, or Rust.

validate(adjustment)
if op == 'amend' and new_size > current.size:
  pass_through_risk(delta_intent)
seq = next_seq(order_id)
result = clob.send(adjustment, seq, eip712_v2_envelope())
wait_ack_or_timeout(p.amend_timeout_ms)
reconcile_with_lifecycle()
emit_report()

11. Wire Examples

Input — what arrives on the wire

{
  "intent_id": "adj_001",
  "order_id": "ord_xyz",
  "op": "amend",
  "new_size_usd": 50
}

Output — what the bot emits

{
  "intent_id": "adj_001",
  "order_id": "ord_xyz",
  "outcome": "ACK",
  "seq_id": 7,
  "reason_code": "EXEC_AMEND_OK"
}

12. Decision Logic

APPROVE

Sequence operations strictly per order_id.

RESHAPE_REQUIRED

This bot does not reshape orders.

REJECT

Reject if max_inflight_per_order is exceeded. Reject amends that would increase size without Risk approval. Surface every ack/timeout/reject as a structured ReportEnvelope.

WARNING_ONLY

No warn-only path defined.

13. Standard Decision Output

This bot returns a RiskVote object. See RiskVote schema.

{
  "intent_id": "adj_001",
  "order_id": "ord_xyz",
  "op": "amend",
  "new_size_usd": 50,
  "outcome": "ACK",
  "seq_id": 7,
  "reason_code": "EXEC_AMEND_OK"
}

14. Reason Codes

CodeSeverityMeaningActionUser-facing message
EXEC_AMEND_OKP2Exec Amend OkSee decision output and developer log for context.This change to your order was applied successfully.
EXEC_CANCEL_OKP2Exec Cancel OkSee decision output and developer log for context.This change to your order was applied successfully.
EXEC_AMEND_INFLIGHTP2Exec Amend InflightSee decision output and developer log for context.This change to your order was applied successfully.
EXEC_AMEND_UNKNOWNP2Exec Amend UnknownSee decision output and developer log for context.This change to your order was applied successfully.
EXEC_AMEND_TIMEOUTP2Exec Amend TimeoutSee decision output and developer log for context.This change to your order was applied successfully.
EXEC_CANCEL_TIMEOUTP2Exec Cancel TimeoutSee decision output and developer log for context.This change to your order was applied successfully.

15. Metrics & Logs

Metrics emitted

MetricTypeUnitLabelsMeaning
amend_ops_totalcountereventbot_idAmend ops total.
cancel_ops_totalcountereventbot_idCancel ops total.
amend_timeout_totalcountereventbot_idAmend timeout total.
cancel_timeout_totalcountereventbot_idCancel timeout total.
ack_latency_ms_histogramcountereventbot_idAck latency ms histogram.

Dashboards

  • 2.15 overview dashboard

16. Developer Reporting

"Per operation: order_id, op, seq_id, sent_ts_ms, acked_ts_ms, outcome, reason_code."

17. Plain-English Reporting

SituationUser-facing explanation
When this bot actsThis change to your order was applied successfully.
When this bot actsWe could not change this order in time and rolled it back.

18. Failure-Mode Block

main_failure_modeAn ack arriving after the timeout window: bot has already retried; CLOB has two operations applied.
false_positive_riskReporting cancel-failure when the cancel actually succeeded; mitigation: reconcile against OrderLifecycleManager before retrying.
false_negative_riskStrategy code bypassing the bot via direct CLOB calls; mitigation: outbound CLOB writes are restricted at the network layer to this bot's identity only.
safe_fallbackOn unrecoverable inconsistency, mark the order as QUARANTINED and escalate to the Execution on-call. Never silently retry past max_retries.
required_dependencies

19. Failure-Injection Recipes

ScenarioHow to injectExpected behaviourRecovery
Drop ack from CLOB and assert single retry then escalationDrop ack from CLOB and assert single retry then escalation.Bot detects within its latency budget and emits the corresponding reason code.Remove the injected fault; bot returns to healthy state within one debounce window.
Race two amends on the same order and assert second is rejected with INFLIGHTRace two amends on the same order and assert second is rejected with INFLIGHT.Bot detects within its latency budget and emits the corresponding reason code.Remove the injected fault; bot returns to healthy state within one debounce window.

20. State & Persistence

Per-order seq_id counter (durable). In-flight operation map (in-memory).

State stores

NameKindKeyValue shapeTTLDurability
order_amend_cancel_manager_statein-memory + fast KV mirrorbot_idPer-order seq_id counter (durable). In-flight operation map (in-memory).24hcrash-safe via KV mirror

Cold-start recovery

Cold-start hydrates from fast KV; missing keys default to safe fallback.

On restart

All in-flight decisions are re-evaluated; no bot decision is trusted across restart without re-emit.

21. Concurrency & Idempotency

AspectSpecification
Execution modelStrict per-order serialisation. Concurrent across distinct order_ids.
Max in-flight32
Idempotency keyorder_intent_id
Replay-safeTrue
DeduplicationBy idempotency_key within a 60s window.
Ordering guaranteesPer-market_id FIFO; cross-market unordered.
Per-call timeout (ms)250
Backpressure strategyBounded queue; oldest-dropped with metric increment when full.
Locking / mutual exclusionPer-market_id mutex; no global locks.

22. Dependencies

Depends on (must run first)

Requires (graph.requires)

exec.order_lifecycle_manager

ConsumesOrderAdjustment OrderLifecycleState
EmitsReportEnvelope(kind=ExecutionReport)
Blocks ordersno

23. Security Surfaces

Only this bot's identity has CLOB write permission for amend/cancel.

Signing surface

Reads pending signed orders; never signs on user behalf.

Abuse vectors considered

  • EIP-712 v2 signature required for every operation.

Mitigations

  • Rate-limit per source
  • Audit-log every override
  • Require role-based authz on admin paths

24. Polymarket V2 Compatibility

AspectValue
CLOB versionV2
Collateral assetpUSD
EIP-712 Exchange domain version2
Aware of builderCode fieldyes
Aware of negative-risk marketsyes
Multi-chain readyyes
SDK usedPolymarket CLOB V2 SDK
Settlement contractCTFExchangeV2
NotesNative CLOB v2 amend/cancel endpoints; EIP-712 v2 envelope with builderCode.

25. Versioning & Migration

FieldValue
current0.1.0
contract_version1.0.0
last_breaking_changenone
deprecation_window_days30

26. Acceptance Tests

Unit Tests

TestSetupExpected result
Cancel of an unknown order_id returns EXEC_AMEND_UNKNOWN.Synthetic fixture per template.Behaviour matches the rule described in the test name.
Concurrent amend on the same order_id returns EXEC_AMEND_INFLIGHT for the second one.Synthetic fixture per template.Behaviour matches the rule described in the test name.

Integration Tests

TestExpected result
Replay 1000 amend/cancel ops through a fixture CLOB; assert every op produces exactly one ReportEnvelope.End-to-end behaviour matches the spec without manual intervention.

Property Tests

PropertyRequired behaviour
seq_id is strictly increasing per (order_id).Always true across all generated inputs.

27. Operational Runbook

If timeouts spike: inspect CLOB v2 latency; enable verbose ack-trace logging; consider widening timeouts only as a temporary measure.

On-call actions

AlertFirst stepDiagnosisMitigationEscalate to
2.15_anomalyOpen the bot's reporting page and confirm the alert is real (not a metric hiccup).Inspect developer log entries for the affected market_id over the last 30 minutes.Force-clear via Admin UI if the rule is clearly stale; otherwise leave engaged and notify owner.Execution pod

Manual overrides

  • polytraders bot pause 2.15 — Disables the bot's enforcement layer; downstream consumers fall back to safe defaults.

Healthcheck

GET /healthz/order_amend_cancel_manager → 200 if last successful evaluation < 60s ago.

28. Promotion Gates

A bot does not advance to the next readiness state until every gate below is green. Gates are observable from production data — no subjective sign-off.

Promote to Shadow

GateHow measuredThreshold
Stubagainst fixture CLOB.Documented threshold met for the full window.

Promote to Limited live

GateHow measuredThreshold
Shadow14 days mirrored against live state.Documented threshold met for the full window.
Advisory7 days.Documented threshold met for the full window.

Promote to General live

GateHow measuredThreshold
Enforcedevery cancel/amend in the system routes through this bot.Documented threshold met for the full window.

29. Developer Checklist

Ready-to-ship score: 27/27 sections complete · 100%

RequirementStatus
Purpose defined✓ done
Required inputs listed✓ done
Parameters defined✓ done
Defaults defined✓ done
Warning thresholds defined✓ done
Hard thresholds defined✓ done
Safe fallback defined✓ done
Structured output defined✓ done
Developer log defined✓ done
Plain-English explanation✓ done
Unit tests defined✓ done
Integration tests defined✓ done
Property tests defined✓ done
Failure-mode block complete✓ done
Reference implementation pseudocode✓ done
Wire examples (input + output)✓ done
Reason codes listed✓ done
Metrics & logs defined✓ done
State & persistence defined✓ done
Concurrency & idempotency defined✓ done
Dependencies declared✓ done
Security surfaces declared✓ done
Polymarket V2 compatibility declared✓ done
Version & migration history declared✓ done
Operational runbook defined✓ done
Promotion gates defined✓ done
Failure-injection recipes defined✓ done