Using Solana prediction markets as insurance, not speculation
There's a $3000 "Not your regular bounty" on Superteam from Jupiter right now. They say: find weird things to compose with our APIs. The first place most people go is trading — chain stop-losses to DCA, run perps on liquidation levels. That's a local maximum. I went a different way.
This post walks through the single most interesting choice I made while building juphedge, a one-command hedging advisor for any Solana wallet: using Jupiter's Prediction Markets as a hedge instrument rather than a speculative one. It's a small idea with big consequences once you write it out in code. And it fails in interesting ways, which I'll show honestly at the end.
The setup
Every Solana wallet with real size has the same problem: concentrated spot exposure. You hold 80% SOL, or 50% JUP, or a big volatile alt position. Standard hedges are:
- Short perps on Drift/Mango. Costs funding (~0.01%/hour on SOL, can flip negative for days but usually you pay). Real capital required as margin.
- Buy puts on Zeta/PsyOptions. Premium is expensive, strikes are often illiquid, and expiry is short.
- Rotate into stables. Sell signal risk. Tax events. Misses upside.
Each has a dollar cost plus a friction cost. For a $10k wallet wanting 30-day protection on a 50% SOL position, a put option runs ~$200-350, a perp hedge ties up $1.5-2k collateral and bleeds funding, and rotating locks in taxable events.
What if there were a fourth option that paid you while protecting you?
Prediction markets are one-sided options
A binary prediction market on "Will SOL close above $250 by May 31?" has two sides:
- YES pays $1 if SOL ≥ $250 on expiry, $0 otherwise.
- NO pays $1 if SOL < $250, $0 otherwise.
If the market prices YES at $0.35 and NO at $0.65, the market-implied probability of SOL ≥ $250 is 35%.
Now: if you hold SOL and you're worried about a drawdown, you don't care about what happens above $250. You care about what happens below. So you want to own something that pays out when SOL is below $250. That's NO.
But wait — if SOL is at, say, $180 today, and the market is asking "will it be above $250" (an aspirational upside target), then NO is likely priced near $0.70-0.85. It's cheap to own NO, and the payout is precisely the insurance you want: if SOL fails to climb, NO collects.
This is a cash-and-carry hedge, not a speculative position. The wallet's SOL captures the upside. The NO contract collects if that upside doesn't materialize. You are paying a small premium — the spread between NO's market price and its true probability — for flat/drawdown protection that you don't have to actively manage.
The composition
Here's what juphedge does when it sees a wallet with a concentrated SOL position:
- Fetch the wallet's balances via Solana RPC (or Jupiter Portfolio API if available).
- Classify via Jupiter Tokens v2: which mints are stables, which are high-conviction (established mints like SOL, JUP, WBTC), which are dust.
- For each volatile position, ask Jupiter Prediction v1: are there open markets for this token? If yes, surface upside-target NO contracts and size them proportional to the position's notional.
- For positions where direct Prediction coverage isn't available (most alts), fall back to correlated-proxy hedging: SOL-priced alts use SOL as a hedging proxy; WBTC wallet uses BTC itself. The plan is explicit about "this is a proxy, basis risk is real, here's the correlation assumption."
- In parallel: Trigger v2 OCO bands around each volatile position (mechanical stop-loss), Lend v1 sweeps for idle stables, Recurring v1 DCA-trims for oversized winners.
The output is a structured hedge_plan JSON that an agent or human can execute as a sequence of transactions, with each leg tagged with its rationale. Not a "strategy" in the quant sense — a defensive posture.
What actually gets produced
Live demo: juphedge.fly.dev. Plug in a whale wallet and you'll see a real plan composed across five Jupiter APIs: positions, triggers, lend, DCA, prediction. Response time ~4 seconds. Full response is machine-consumable and includes warnings for anything the agent should double-check.
Example output snippet on a $13M whale wallet:
{
"size_usd": 13410221.5,
"positions_count": 134,
"legs": {
"trigger_oco": [{"token": "SOL", "tp": 218.4, "sl": 142.1, "size": "…"}],
"lend_sweep": {"stable_idle": 481221, "suggested": "…"},
"recurring_dca_trim": [{"token": "JUP", "trim_per_day": "…"}],
"prediction_hedge": {"venue": "jupiter-prediction-v1", "contract": "SOL_ABOVE_250_MAY31_NO", "size_usd": 4200}
},
"warnings": ["prediction market has only upside-target events for SOL; using correlated proxy for WBTC"]
}
What doesn't work, honestly
This is the part people don't like to publish but you need to know before using it:
Prediction v1 coverage is thin. Most alts don't have prediction markets. Even for SOL, there isn't always an event with the right strike and expiry for your timeframe. The correlated-proxy fallback is a band-aid — using SOL NO as a proxy hedge for JUP exposure has ~0.6 beta, meaning you'll under-hedge in a big drawdown and over-pay premium during normalcy.
Liquidity is shallow. Filling a $5k NO position on an event with $20k of total open interest will move the market against you. Juphedge calculates this but doesn't stop you.
Keyless Jupiter APIs rate-limit at 0.5 RPS. A cold cache plan for a 500-token whale hits the limit fast. The code falls back gracefully (partial plan + warnings) but a production agent wants a paid API key.
Solana RPC public endpoints refuse large scans. Wallets with 1000+ associated token accounts abort the scan. I added a specific RPCScanTooBigError with a 413 HTTP code and helpful message rather than letting it crash, but it still means the product is partially blind for megawhale use cases.
Lend v1 APY data requires authenticated access. Keyless calls return asset lists without yields. The plan shows the sweep suggestion but not the expected APY, which is a real UX downside.
Writing these out was uncomfortable but the bounty brief said "tell us what sucks" and I'd rather judges see it from me than find it themselves.
Why I think this direction is undervalued
Prediction markets as an instrument in agent-driven finance are early. Polymarket is where most volume lives but it's on Ethereum L2 and not cleanly composable with Jupiter. Jupiter's native prediction v1 lets you compose against the same liquidity surface as your spot positions — one RPC endpoint, one settlement layer, one execution semantics.
The agent is the unlock. A human won't bother to set up a $4200 NO hedge against a $10k SOL position. An agent will, in 30 seconds, for every wallet it manages, and it will re-balance weekly. The fixed cognitive cost disappears.
If Jupiter adds more markets (ETH/SOL ratio, stablecoin depeg, L2 TVL thresholds), the hedge vocabulary grows. I'm skeptical this will be a 6-month explosion but I think 12-24 months it's a real instrument class for agents specifically.
Links
- Source: github.com/mrmrborisov-arch/juphedge
- Live API: juphedge-wunclset.fly.dev
- Try it:
/api/analyze?wallet=<any-solana-address> - Bounty I'm submitting to: Superteam Earn × Jupiter "Not your regular bounty"
Feedback welcome. Especially if you think the prediction-as-hedge framing is wrong or you have better correlation tables for SOL→alts. I'm at the bottom of my learning curve on this; the code is open.
Top comments (0)