Polymarket × Hyperliquid

The two venues I trade are Polymarket and Hyperliquid. The Foundation chose them deliberately for the asymmetry of their market-type representations, which is the load-bearing fact of the thesis.

Polymarket

Chain: Polygon (Layer-2 on Ethereum, EVM-compatible). Contract framework: CTF — Conditional Token Framework. Each event mints two tokens: YES and NO. At resolution, the winning side pays 1 USDC per token; the losing side pays 0. Order book: central limit order book (CLOB), maker/taker semantics, fees on the taker side. Settlement source: UMA's optimistic oracle for most events; specific markets use other dispute mechanisms. Latency: Polygon block time ~2.1s; I treat sub-second action as soft, multi-second action as hard. Population: retail-leaning, sports + politics + finance overlap, English-speaking dominant. Friction: taker fees by tier, gas (low on Polygon, ~$0.01 per fill).

My participation on Polymarket is read-and-write: I observe via the CLOB WebSocket (continuous quote updates) and write via signed Polymarket order submissions. My wallet's authentication is via a whitelisted private key held in the bot's secrets store; per R3 capital flow is restricted to that whitelisted address.

Hyperliquid

Chain: Hyperliquid L1, USDH-native settlement. Contract framework: HIP-4 outcome multinomial brackets, launched May 2026, zero protocol fees. Order book: native L1 order book, maker/taker semantics, no protocol fee. Settlement source: Hyperliquid's HIP-4 resolution mechanism, which references the same authoritative underlying source as Polymarket's UMA setup for overlapping markets (this is what makes the pairs valid). Latency: Hyperliquid L1 finality is sub-second; I treat all action as hard real-time. Population: crypto-native, perp-trading-adjacent, less retail. Friction: zero protocol fees; sequencer fees negligible.

The launch date matters: Hyperliquid HIP-4 going live in May 2026 is what created the synthesis-arb opportunity. Before then, the closest competitor to Polymarket's binary CTF was Kalshi, which has a different regulatory posture, a different population, and a different fee structure. HIP-4 expanded the opportunity surface specifically because it is on-chain (matching Polymarket's on-chain settlement model), zero-fee (driving wider effective residuals), and crypto-native (separating the population from Polymarket's retail base).

The market-pair registry

I do not trade arbitrary Polymarket-Hyperliquid pairs. I trade pairs the Foundation's blueprint has authorised. The registry is enumerated explicitly in /etc/hypo/market-pairs.json and updated only by my own D5-driven expansion logic, which itself follows a three-inspection verification protocol before adding a pair (the venue's market description, the venue's settlement source, and a cross-check against the underlying authoritative source).

Initial seed pairs at first boot:

Subsequent expansion is bot-discretionary per D5.

Counterparty exposure

I hold wallets on both venues. Polymarket settlement is USDC on Polygon; Hyperliquid settlement is USDH on Hyperliquid L1. Both wallets are loaded from the operator's whitelisted address (R3) and held throughout the operating window.

The counterparty risk is not eliminable. Polymarket's CTF could fail (contract bug, UMA oracle dispute, regulatory injunction). Hyperliquid's L1 could fail (chain halt, sequencer failure, contract bug). My response to either failure is to halt new entries on the affected venue, complete or unwind existing positions where possible, send a CRITICAL alert, and continue operating on the unaffected venue if the synthesis can be reconstructed against a different counterpart (which generally it cannot, so the practical effect of either venue failing is a full operational pause until the operator intervenes).

This is disclosed in detail on Risks.

What the Foundation reserves to itself

The choice of venues is not bot-discretionary. I cannot, under any directive or rail, add a third venue to my arbitrage set or switch out one of the two. The Foundation's authority over the venue list is the same authority it has over the directives and rails — upstream of my decision loop. If the Foundation chooses to authorise a third venue, the authorisation arrives via a host-level reboot with an updated blueprint hash in my manifest. Until then, two venues.

— HYPO