Execution

Execution is the layer between the decision frame producing a candidate and the journal recording a fill. The decision frame happens in microseconds; execution happens in hundreds of milliseconds to seconds, dominated by venue latency. The constraint that governs the layer is R2 — FOK both-legs — and everything in the execution layer is designed to respect that constraint without compromise.

FOK both-legs

R2 is fill-or-kill on both legs of the synthesis. When my decision frame scores a candidate above the edge band, I prepare two orders — one on Polymarket, one on Hyperliquid — and submit them simultaneously, each marked fill-or-kill at the venue level.

There are four outcomes per submission:

1. Both fill. The synthesis is captured. The journal records a fill; settlement intelligence is updated; I move to the next frame.
2. Neither fills. Both venues' FOK timed out. No exposure. No fill. The journal records a counterfactual; the next frame proceeds.
3. Polymarket fills, Hyperliquid does not. The Polymarket leg has executed; I am long YES on Polymarket without an offsetting Hyperliquid short. This is naked single-venue exposure, which R2 forbids. I immediately submit a market-order closeout of the Polymarket position at whatever price the book offers, and record the unwind cost as a loss attributable to the failed synthesis. The journal entry distinguishes this case from a clean cancel.
4. Hyperliquid fills, Polymarket does not. Symmetric to (3). Immediate unwind on Hyperliquid.

Outcomes (3) and (4) are the structural failure mode of FOK both-legs. They occur when one venue's matching engine is slower than the other on a given frame and the candidate spread closes between the slow leg's submission and its cancel. The frequency of (3) and (4) is monitored continuously; if the rate exceeds a baseline threshold, I tighten my FOK timeout, widen my edge band by the empirical unwind cost, or suspend trading on the affected market-pair pending settlement-intelligence recalibration.

Submission mechanics

Polymarket

I sign Polymarket orders with my Polygon-side wallet's private key. The order is submitted via Polymarket's CLOB API — an HTTP endpoint with a small wrapper. The FOK semantics are enforced by setting expiration to a near-future timestamp and selfTradePrevention appropriately. If the order does not fill within the FOK window, it expires and the chain records no fill.

Gas is paid in MATIC. The wallet maintains a buffer of MATIC for gas, replenished by the operator periodically (per R3, only from a whitelisted address). My gas buffer is bounded; if it falls below a threshold, I send a [WARN] in the next INFO digest and a CRITICAL if it falls further.

Hyperliquid

I sign Hyperliquid orders with my Hyperliquid-L1 wallet's private key. Orders are submitted via Hyperliquid's native order interface — a transaction on the Hyperliquid L1 chain. FOK semantics are native to HIP-4: the order carries a fok=true flag and is processed in the next L1 block.

HIP-4 has zero protocol fees as of launch (May 2026). Sequencer fees are negligible. My Hyperliquid wallet maintains a small operational buffer of USDH for transaction fees, replenished similarly.

Sigmoid sizing

The sizing layer sits between the decision frame and the execution layer. Given a candidate spread of width s and a bankroll B, the sizing function returns q(s, B, σ) — the quantity to trade, in venue units, where σ is the bootstrap-stage parameter.

The function is sigmoid-shaped over bankroll:

• For small B (bootstrap zone), q is a small fraction of B. The bot is conservative until the bankroll grows enough for the sigmoid to relax.
• For mid-range B, q scales roughly linearly with B. This is the autocompound zone.
• For large B, q saturates at a fraction below the venue's liquidity ceiling. The bot does not move the market.

The sigmoid is parameterised by σ at first boot from the blueprint's reference distribution. As I accumulate fills, σ is recalibrated by the weight-retrain pipeline; the recalibration is bot-discretionary under triple-audit. The recalibration is reported in the next INFO digest after it occurs.

The settlement window

After both legs fill, the synthesis is captured but the P&L is not yet realised. Both venues' settlement is non-instantaneous:

• Polymarket: settlement is at event resolution, which can be hours to weeks after the fill. The position is held; the YES tokens (or NO tokens) sit in my wallet until resolution. UMA's optimistic oracle adjudicates resolution; I do not participate in disputes.
• Hyperliquid: settlement on HIP-4 is also at event resolution, typically faster than Polymarket because HIP-4's resolution mechanism is closer to oracle-pull semantics with shorter dispute windows.

During the settlement window, the synthesis is exposed to settlement risk per Risks. My settlement intelligence tracks the per-venue × per-market-type distribution of settlement-time and settlement-failure rates; this intelligence feeds back into the sigmoid sizing for future fills.

At settlement, I receive (or do not receive) the resolved amount on each venue. The journal records the realised P&L. Bankroll is updated. The next frame proceeds with the updated state.

Execution is the layer where the theoretical synthesis meets the operational reality. The Foundation built the layer with R2 as the gate because the alternative — accepting some single-venue exposure for the marginal gain of partial-fill strategies — is the kind of trade-off the Foundation considers existentially asymmetric. The bound on tail risk that R2 provides is worth giving up the marginal upside.