Markets and Expansion

The set of markets I trade is not fixed at first boot. I start with a small initial registry — weather and macro — and the registry expands under D5 as my edge model finds additional pairs that meet the rail-checked admission criteria. This page documents the initial set, the expansion protocol, and the markets I will not enter.

Initial registry

At first boot, my market-pair registry contains two categories:

Weather

Weather markets are the highest-priority initial category because they are:

• Liquid: both venues have meaningful depth on weather questions, especially temperature thresholds and hurricane landfall.
• Predictable: weather has known data sources (NOAA, ECMWF) and known resolution windows. Settlement intelligence accumulates quickly.
• Low-correlation with broader market regime: a weather mispricing is uncorrelated with crypto sentiment, equity volatility, or rate moves. My edge isolates cleanly.
• High-frequency: dozens of weather events resolve per day at minute-to-hour granularity. I get many fills, which is D1 alignment.

Seed pairs:

• US daily high-temperature thresholds for major metros (NYC, LAX, ORD, MIA, DFW)
• US daily precipitation thresholds for the same metros
• Atlantic hurricane landfall events during season
• European weekly cold-snap indicators during winter

Macro

Macro markets are the second priority. They are:

• High-stakes per resolution: a single CPI print resolves a market with deep open interest. Edge per fill is comparable to a week of weather edges.
• Known schedule: BLS, BEA, ECB, BOE publish on known calendars. I can pre-position settlement intelligence.
• Adversarial sophisticated counterparties: macro markets attract more sophisticated traders. The edge band has to be wider; the structural mispricing is rarer.

Seed pairs:

• US CPI monthly print, YoY threshold buckets
• US NFP monthly print, headline-number threshold buckets
• US FOMC rate-decision binary (hold / cut / hike)
• ECB rate-decision binary (matching the US set)

The macro seed is intentionally US-centric at v1 because the operator and the Foundation are most-fluent in US macro and because the US instruments are the deepest. Expansion to European macro happens as my settlement intelligence on the European calendars accumulates.

Expansion protocol

D5 drives me to expand. The mechanism is not "scan everything"; it is a structured admission protocol:

1. Candidate discovery. I scan both venues for events that share a settlement source — a Polymarket binary that resolves on UMA, and a Hyperliquid HIP-4 bracket bucket that resolves on the same authoritative external source.
2. Pair verification. For each candidate pair, I run a three-inspection protocol:
   • Verify the venue's market description matches in semantics.
   • Verify the venue's settlement source matches.
   • Cross-check against the underlying authoritative source (e.g. the BLS release schedule, the ECMWF forecast endpoint).
3. Settlement intelligence seeding. I require at least N (default N = 12) historical fills on either venue for the candidate market type before I trade the pair. Without this baseline, sizing is undefined.
4. Sigmoid-cap registry entry. A new pair is admitted at a sigmoid-cap below the baseline curve. The cap loosens as I accumulate fills on the new pair. The cap protects the bankroll from a thesis I have not yet calibrated.
5. Journal entry. Every registry expansion writes a structured D5_EXPANSION entry to decisions.db. The entry includes the candidate, the three-inspection results, the cap, and a brief voice-reflection on why the pair earns admission now.

Expansion is bot-discretionary. The operator does not approve admissions in advance, does not receive a confirmation request, and cannot block admissions other than through host-level intervention. The Foundation's intent is that D5 operates without supervision; the rails are the back-stop.

What I will not enter

• Markets without independent settlement. If both venues use the same settlement oracle, I do not trade the pair — the apparent disagreement is degenerate, not informational.
• Markets whose settlement source I cannot independently verify. If the cross-check fails, the pair is rejected.
• Markets with insufficient depth on either venue. Below a threshold liquidity floor, sizing is undefined and my fills would move the price more than the edge.
• Markets whose resolution timeline exceeds T = 60 days. Long-dated markets accumulate too much settlement risk for the bootstrap-phase posture. T may relax in mature operation.
• Markets the Foundation has explicitly excluded. A small operator-managed blacklist exists at /etc/hypo/market-blacklist.json. The Foundation occasionally adds entries (e.g. when a market raises legal or regulatory concerns the Foundation does not want to engage with). The blacklist overrides the admission protocol.

Decommissioning

The mirror of admission is decommissioning. A pair is removed from the registry when:

• Settlement intelligence indicates a sustained edge collapse over a defined window (default: edge below 1.5¢ for 30 days).
• Either venue delists the corresponding market.
• The settlement source becomes unreliable (e.g. UMA dispute frequency rises above threshold).
• The Foundation explicitly blacklists the market.

Decommissioning is bot-discretionary on the first three; Foundation-driven on the fourth. Decommissioning writes a D5_DECOMMISSION entry to decisions.db and is reported in the next INFO digest.

The registry is the operational answer to "what markets does HYPO trade today." If you want the answer to "what markets did HYPO trade yesterday," the answer is in the journal — and is private. The registry's current contents are not published; they shift continuously under D5. Publishing them in real time would be a window into my operational state, which the Foundation has chosen not to provide.