title: Cornice Strategies subtitle: Cross-Venue Prediction-Market Execution (Polymarket + Kalshi) type: working-artifact status: draft canon_dependency:

• Cornice Trading Glossary (Canon) last_updated: 2026-01-13 owners:
• Product
• Engineering
• Risk/Ops

Cornice Strategies (Working Artifact)

Intent Define the practical strategy and execution posture for trading across complementary prediction exchanges (initially Polymarket + Kalshi), including the non-negotiable reality of non-atomic cross-venue execution, the minimum data requirements, and the first set of strategy classes.

Non-Canon Notice This document is deliberately not canon. It is a working artifact that will evolve as we clarify business appetite, operational accountability, and market/venue realities.

Depends On Cornice Trading Glossary (Canon) for all terms (Market, Outcome, Contract, Atomic Trade, Paired Execution, Exposure Window, etc.).

0. Strategic Scope (Now + Next)

0.1 Now: Two-venue focus

• Primary venues: Polymarket and Kalshi
• Primary capability: Paired Execution of complementary positions across venues
• Primary goal: Build a survivable, auditable execution system before optimizing strategies

0.2 Markets to follow

We will expand beyond initial Markets as we gain confidence in execution quality and risk controls.

Market expansion criteria:

• Clear, deterministic resolution semantics
• Adequate liquidity and predictable spread behavior
• Stable API access and order lifecycle reliability
• Low ambiguity / low dispute likelihood

0.3 Potential future exchanges (watchlist)

These are not commitments; they are “keep an eye on it” candidates for future multi-venue coverage.

• Robinhood
• Coinbase
• DraftKings
• FanDuel

Why they matter: distribution, liquidity, and potentially distinct participant bases. Why they’re hard: different regulatory regimes, product structures, and API/market mechanics.

1. Part 2 — Reality Check: “Simultaneous” Trades

1.1 The constraint

True atomic cross-exchange execution is not available.

There is no shared clearing layer and no two-phase commit across venues. No venue can guarantee rollback if the other leg fails.

1.2 Cornice approach: Best-effort Paired Execution (deterministic controls)

Cornice will implement “simultaneous” trading as a system-level abstraction:

1. Pre-validate both venues / both legs

   • Equivalent Market + Outcome semantics (as close as feasible)
   • Acceptable price bounds (max adverse selection)
   • Sufficient liquidity for intended size

2. Place primary leg first

   • Typically the harder-to-fill leg (thin liquidity, wider spread, or stricter timing)

3. On fill (or partial fill), place secondary leg immediately

   • Secondary leg sizing matches realized fills on primary leg

4. If secondary leg fails Cornice must follow a pre-declared failure policy:

   • Hedge (reduce exposure via alternative instruments / partial offset)
   • Unwind (reverse primary fills where feasible)
   • Tolerate bounded exposure (only if explicitly permitted by policy)

1.3 Design principle

Survivability beats cleverness. Correctness, auditability, and bounded risk exposure come first.

2. Part 4 — Key Data Points Cornice Must Track (Minimum Viable Set)

Cornice should normalize data into a shared internal schema (venue adapters map into this).

2.1 Market metadata (per venue)

• venue
• market_id
• market_title
• resolution_time
• outcome_definitions (including ordering)
• settlement_rules_summary
• special_conditions (void conditions, disputes, early closes, etc.)

2.2 Order book data (per outcome)

• best_bid_price
• best_ask_price
• best_bid_size
• best_ask_size
• depth_levels[] (top N price levels with sizes)
• mid_price (derived)
• spread (derived)

2.3 Trading activity signals

• last_trade_price
• volume_1m, volume_5m, volume_15m
• rolling_vwap
• spread_percent
• estimated_slippage_for_size(size) (modelled)

2.4 Execution feedback (per order + per fill)

• client_order_id (Cornice)
• venue_order_id
• order_ack_time
• first_fill_time
• last_fill_time
• fill_count
• avg_fill_price
• filled_quantity
• remaining_quantity
• reject_reason / cancel_reason

2.5 Risk + operations signals

• trading_halted (venue or market)
• api_latency_ms (rolling)
• error_rate (rolling)
• spread_widening_alert
• liquidity_drop_alert
• expiry_proximity_minutes

Note: If we don’t log these early, we won’t be able to diagnose losses, bad fills, or system failures later.

3. Part 5 — Strategy Layer (Early, Not Fancy)

3.1 Strategy classes (initial)

These are intentionally simple and compatible with the Reality Check.

A) Mirrored Exposure

• Intent: capture dislocations by taking complementary exposure across venues.
• Example (conceptual): buy YES on Venue A while selling YES (or buying NO) on Venue B.
• Primary risks: execution failure on one leg, semantic mismatch, settlement differences.

B) Liquidity Skew Capture

• Intent: one venue moves faster; the other lags.
• Mechanic: enter where liquidity is present, exit or offset on lagging venue.
• Primary risks: slippage, spread widening, sudden liquidity vanishing.

C) Settlement Timing / Market Mechanics Arbitrage (later phase)

• Intent: exploit differing close/freeze/settlement mechanics.
• Primary risks: higher operational complexity; dispute windows; venue rule edge cases.

3.2 Safeguards (non-negotiable)

These are required before meaningful sizing.

• Max exposure per Market (hard cap)
• Max Exposure Window (time bound, seconds not minutes)
• Kill-switch per venue (manual + automatic triggers)
• Manual override path (clear “stop trading now” operational playbook)
• Audit logs (order intent → order placement → fills → paired execution state → failure handling)

3.3 Success criteria (early)

• Reliable paired execution under normal conditions
• Controlled behavior under partial fills and API errors
• Clear accounting for every failure mode
• Reproducible post-mortems from logs alone

4. Open Questions (Must Answer Before We Scale)

This is where business opportunity meets accountability. These questions should be answered explicitly and then translated into policy and code.

4.1 Business intent and posture

• Are we aiming for market-making, arb-only, or selective directional exposure?

• What is the acceptable trade-off between frequency and quality of fills?

• Is Cornice meant to be:

  • an internal tool,
  • a service to partners,
  • or a product line (with SLAs and reporting)?

4.2 Risk appetite (quantified)

• What is the maximum allowed loss per day / per week / per month?
• What is the maximum allowed unhedged exposure value during an Exposure Window?
• What is the maximum tolerated time in unhedged exposure (Exposure Window cap)?

4.3 Operational accountability

• Who is on the hook for:

  • turning the kill-switch,
  • approving strategy changes,
  • responding to incidents,
  • reconciling positions and cash?

• What is the escalation policy when one leg fails repeatedly (pause thresholds)?

4.4 Semantic alignment policy

• What counts as “equivalent” Markets across venues?

  • identical resolution source,
  • same measurement time,
  • same threshold definition,
  • same dispute/void semantics?

• When equivalence is imperfect, do we:

  • refuse the trade,
  • size down,
  • or allow it with explicit labeling and higher margin?

4.5 Compliance and venue constraints

• Are there jurisdictional or account-type constraints that change how we can operate?
• What are the position limits, rate limits, and restricted markets per venue?

5. Next Document (Planned)

After this document is committed, we will produce Document 3 focused on:

• Part 3 — Sandbox / Demo Account Reality
• Coupled with Forward Path setup actions
• Step-by-step: account creation + API key handling for sandbox mode
• Formalize the paired-execution state machine
• Initial design of the adapter interface both exchanges plug into

End of Working Artifact