# Systematic ETH Tail-Risk Trading on Polymarket

> A trading system that prices ETH strike markets on Polymarket against a Binance-derived move distribution, sizes exposure to an ETH risk budget, and runs the full discovery-to-settlement loop.

- Canonical URL: https://blog.eggtech.io/posts/eth-tail-risk-polymarket
- Markdown URL: https://blog.eggtech.io/posts/eth-tail-risk-polymarket/index.md
- Published: 2026-06-29
- Updated: 2026-06-29
- Author: Kai Aldag
- Reading time: 12 min read
- Tags: trading, quant, crypto

---

## 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:

```json
{
  "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:

```text
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:

```text
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

| Area | Current implementation |
|---|---|
| Language | Python |
| Market data | Polymarket Gamma + CLOB, Binance ETH candles |
| Pricing | Empirical terminal and excursion distributions |
| Risk | ETH-equivalent inventory, hedge buffer, market-style controls |
| Funding | Aave LTV / health-factor monitor in progress |
| Storage | SQLite order, fill, settlement, and capital ledger |
| Execution | Plan generation, capital scaling, signer/funder-compatible flow |
| Accounting | Fee and rebate treatment included in realized edge |
| Next | Depth-aware sizing, Monte Carlo, barrier-specific hedging |

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.

| ETH path | ETH inventory | Prediction-market overlay | Combined effect |
|---|---:|---:|---|
| Slow grind up | Gains | Upside NOs likely win | Carry plus ETH beta |
| Sharp upside through terminal strikes | Gains a lot | NOs lose | Designed to remain positive after hedge buffer |
| Barrier touch then reversal | May give back gains | NO can lose permanently | Requires smaller sizing or dynamic hedge |
| Flat | Mostly unchanged | NOs likely win | Carry without needing ETH appreciation |
| Moderate down month | Loses | NOs win; downside YES may win | Drawdown is partially dampened |
| Severe selloff | Loses materially | NOs win | Helps service debt, but funding risk must be controlled |

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.

![Normalized ETH tail-risk payoff](/images/eth-tail-risk-polymarket/case-study-exposure-curve.png)

The full dashboard output also includes per-leg allocation, settlement timeline,
and a time-by-price heatmap: [the full dashboard render](/images/eth-tail-risk-polymarket/case-study-hypothetical-dashboard.png).

## Failure Modes

| Failure mode | Why it matters | Mitigation |
|---|---|---|
| Barrier touch then reversal | NO loses but ETH hedge may not remain profitable | Separate barrier sizing; dynamic spot/perp hedge near barrier |
| Liquidity disappears | Model edge may be untradeable at size | Walk CLOB depth before sizing; cap order size by fill quality |
| Stale or misparsed markets | False edge from bad data | Market-state filters, CLOB validation, question-text parser |
| Fat tails / volatility regime shift | Historical distribution can underprice jump risk | Regime filters, wider buffers, lower exposure around events |
| Aave funding risk | Stablecoin debt can dominate strategy risk in selloffs | Low LTV, pause rules, health-factor triggers, profit reservation |
| Settlement ambiguity | Market condition may not match modeled condition | Explicit market-style parser and manual override path |
| Capacity limits | High APR can vanish at meaningful size | Report executable depth, fill quality, and capacity estimate |

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.

| Metric | Value |
|---|---:|
| Settled positions | 32 |
| Wins / losses | 32 / 0 |
| Win rate | 100.00% |
| Return on settled filled cost | +0.80% |
| Capital-weighted annualized turnover return | +337.88% |

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.

| Month | ETH spot move | Polymarket ROI on cost | Combined return on ETH notional | Wins / legs |
|---|---:|---:|---:|---:|
| February 2026 | +0.93% | +72.41% | +21.24% | 5 / 6 |
| March 2026 | +7.12% | +23.35% | +13.49% | 4 / 8 |
| April 2026 | +7.18% | +1.40% | +7.52% | 3 / 8 |
| May 2026 | -11.17% | +99.97% | +18.64% | 8 / 8 |
| Aggregate | n/a | +52.90% | +60.80% | 20 / 30 |

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.