Systematic ETH Tail-Risk Trading on Polymarket

Executive Summary

I built and deployed a Python trading system for ETH binary and barrier markets on Polymarket. The system discovers active ETH strike markets, filters stale or unfillable CLOB books, prices outcomes using Binance-derived empirical move distributions, sizes exposure against an ETH-denominated risk budget, and reconciles orders, fills, and settlements into a local ledger.

The trading hypothesis is that short-window ETH upside tails are often priced above realized path probability. The strategy buys NO on selected upside strike markets and optionally uses expected profits to fund downside YES hedges, creating a portfolio-aware short digital / short one-touch overlay on a long ETH book.

This is not a passive yield product. It is a market-structure and execution case study: identify a venue-specific mispricing, model it, size it against portfolio constraints, and run the trading loop with auditability.

Market Structure

ETH holders have a yield problem. Staking and lending returns are modest, while many higher-yield alternatives change the exposure profile through restaking risk, LP inventory risk, leverage, or opaque structured products.

I wanted a more explicit expression. I am structurally long ETH, but I believe ETH usually grinds upward over weeks rather than repeatedly gapping through far out-of-the-money strikes over short windows. Prediction markets make that view tradable through listed ETH strike contracts:

• terminal digital markets, such as “ETH above X at expiry”;
• barrier / one-touch markets, such as “ETH reaches X before expiry”;
• downside strike markets, such as “ETH dips to X before expiry.”

Economically, the upside NO book behaves less like a vanilla covered call and more like selling cash-settled digital or one-touch exposure against long ETH inventory. That distinction matters because the loss profile is discontinuous around strikes and, for barrier markets, path-dependent.

Trading Rule

The discretionary view becomes parameters:

{
  "upside_no": [
    { "pct": 0.10, "weight": 0.2, "max_days_to_expiry": 2 },
    { "pct": 0.20, "weight": 0.3, "min_days_to_expiry": 20 },
    { "pct": 0.30, "weight": 0.5, "min_days_to_expiry": 20 }
  ],
  "downside_yes": [
    { "pct": -0.05, "weight": 0.6, "min_days_to_expiry": 20 },
    { "pct": -0.10, "weight": 0.4, "min_days_to_expiry": 20 }
  ],
  "hedge_buffer": 0.8,
  "downside_funding_fraction": 0.5
}

The bot never hardcodes absolute strikes. It derives targets from current ETH spot, then maps those targets onto whatever strike grid Polymarket actually lists. If the target lies between two fillable strikes, the bot linearly splits the bucket toward the closer strike. This keeps the strategy tied to the shape of the view rather than to one hand-picked market.

Within each strike and expiry window, APR is only a tie-breaker. The strike is chosen by target proximity and fillability. Price quality and model edge decide whether the opportunity is worth trading.

Pricing Layer

Headline APR is not enough. A very short-dated binary can show a large annualized return simply because time-to-expiry is small. The relevant question is whether the market-implied probability is wrong relative to ETH’s path distribution.

The pricing layer uses Binance ETH market data to estimate:

• terminal move distributions for digital “above/below at expiry” markets;
• intraperiod maximum and minimum excursions for barrier markets;
• horizon-specific jump behavior for 24-48 hour markets;
• regime-sensitive realized volatility so old low-volatility data does not dominate current-risk estimates.

For each outcome, the model converts strike, direction, market style, and time-to-expiry into a probability of winning. It then compares that probability with the market-implied price:

edge = model_probability_of_win - market_price
expected_return_on_cost = edge / market_price

For NO positions, the win probability is the probability that the upside condition does not occur. This lets the bot separate “high APR because the market is genuinely risky” from “high APR because the market is overpaying for an unlikely tail.”

Data and Venue Handling

The market-data work ended up being as important as the model. Prediction-market feeds are messy in ways that create false edge if handled naively:

• settled markets can remain in “active” event feeds;
• some Gamma markets have no CLOB book;
• stale asks can imply impossible returns;
• event slugs contain years and other numbers that can confuse strike parsers;
• multi-strike questions can look tradable unless rejected explicitly;
• barrier and terminal markets need different probability and hedge treatment.

The planner validates every market through the CLOB, requires usable top-of-book prices, rejects stale or unparseable markets, parses direction from the question text rather than the slug, and keeps market style explicit. Expected 404s from dead books are summarized rather than treated as hard failures.

Risk Model

The sizing invariant is the core risk control:

total upside NO cost <= hedge_buffer * ETH_appreciation_at_highest_resolved_strike

For terminal “above at expiry” markets, the hedge relationship is relatively clean: if the NO loses, ETH is above the strike at the same time the market settles, so the ETH inventory should have appreciated enough to fund the loss, subject to the hedge buffer.

For barrier markets, the risk is different. ETH can touch the strike, lock in a NO loss, and then mean-revert before the portfolio is marked or hedged. The bot therefore treats barrier NO exposure as path-dependent short gamma. In practice, that means barrier markets should be sized more conservatively, paired with an automatic ETH/perp hedge when spot approaches the barrier, or excluded when the available hedge capacity assumes terminal settlement.

Downside YES bets are funded from expected NO profits, not from the primary upside-risk budget. This shifts the exposure from purely linear long ETH toward a long ETH book with dampening rebates around selected downside strikes.

Funding Controls

The trading capital is separated from the ETH inventory. The ETH book defines hedge capacity; the deployable dollar float defines what can actually be put to work today.

The Aave monitoring layer I am building around the bot tracks collateral value, debt, health factor, and LTV. If funding risk starts to dominate, the bot can pause new rolls, reserve profits for debt service, or reduce exposure. In a selloff, the upside NO book should be moving toward a winning outcome, but that does not remove liquidation risk. The funding monitor is what prevents a good relative-value trade from becoming a bad balance-sheet trade.

There is also a long-duration allocation rule. If annual ETH strike markets are available at rates that clear Aave borrow cost plus liquidity, slippage, and tail-risk buffers, the bot can allocate a small portion of excess profits to far-out annual NO markets. Otherwise, the capital stays reserved for debt service, rolling daily markets, or ETH accumulation.

Implementation Snapshot

The bot is built as a trading system rather than a one-off script. Plans are serialized with stable leg IDs, every order intent is recorded, fills and settlements are reconciled back into the ledger, and private-key handling uses an encrypted Ethereum V3 keystore rather than a raw key. Execution accounting also includes referral/rebate treatment so edge is measured net of avoidable venue costs.

Exposure Surface

The strategy does not remove ETH beta. It reshapes it.

The chart below is a synthetic 25 WETH-equivalent planner run. It is normalized to return on ETH notional, before depth, slippage, fees, and funding. The point is the shape: the prediction-market overlay adds carry in flat, down, and moderate-up paths while preserving positive combined exposure through the modeled terminal upside-loss region.

The full dashboard output also includes per-leg allocation, settlement timeline, and a time-by-price heatmap: the full dashboard render.

Failure Modes

One stress case makes the barrier risk concrete: ETH trades from spot to a +30% barrier intramonth, triggers one-touch NO losses, and then mean-reverts before month-end. Terminal ETH appreciation would no longer fund the barrier loss. The system has to either hedge dynamically near the barrier or size that exposure as path-dependent short gamma from the start.

Results

I separate results into live-system validation and historical simulation.

Live Pilot

The live pilot is not evidence of a production Sharpe yet. It is evidence that the full trading loop works: market discovery, plan generation, order placement, fills, settlement reconciliation, capital recycling, and ledger accounting.

I do not treat the annualized figure as a capacity estimate. It is shown only to illustrate short-duration capital turnover in the daily roll. The production questions are executable depth, adverse selection, fees, slippage, settlement latency, and capacity.

Monthly Simulator, February-May 2026

The monthly simulator applies the same hedge math to the February-May 2026 monthly book. It excludes daily markets and reports results before slippage, fees, and depth constraints, so I treat it as directional evidence rather than a production backtest.

The simulator produced +52.90% Polymarket ROI over four months on cost staked, or roughly +158.71% annualized on deployed prediction-market capital. On the average ETH notional in the simulator, the incremental overlay return was about +58.04% over four months, or roughly +174.12% simple annualized.

May is the cleanest example of the intended exposure. ETH sold off, but the prediction-market book more than offset the inventory drawdown, leaving the combined book positive for the month. That is the target behavior: stay long ETH while using the prediction-market overlay to harvest tail-risk mispricings and dampen adverse paths.

Capacity and Net Returns

The headline returns are not the same thing as scalable edge. A production version has to report expected return net of spread, fees, rebates, slippage, funding, and failed-fill probability. The next execution layer sizes from CLOB depth, computes weighted-average entry price, and reports capacity as a first class output rather than assuming top-of-book liquidity is available at size.

Next Iteration

The next version focuses on making theoretical edge closer to executable edge:

• integrate the Binance pricing model directly into execution thresholds;
• walk CLOB depth and size by expected fill quality;
• separate barrier and terminal markets in both pricing and hedge logic;
• add path-dependent Monte Carlo for daily rolls plus monthly books;
• finish Aave debt-service automation and annual-market allocation rules;
• report capacity, slippage, fee/rebate impact, and mark-to-market drawdown.

Why This Is Relevant

This is the kind of work I care about: finding fragmented or under-modeled crypto market structure, turning it into a quantified strategy, building the infrastructure to trade it safely, and improving the system as real fills expose the difference between theoretical and executable edge.

The project required trading judgment, market-data hygiene, probability modeling, portfolio-aware risk sizing, execution accounting, and operational discipline. That combination is what makes the case study valuable: it is not just a bot, and it is not just a backtest. It is a concrete example of taking an edge from idea to live trading system.