Parlays on HIP-4

Thanks to Jim and Benedict for their thoughtful comments and feedback.

HIP-4 brought forward a community proposal for Event Futures. The goal of the proposal was somewhat simple: expand the scope and shape of markets that can be deployed to Hyperliquid permissionlessly. In this post, we explore how parlays, a popular sports betting product, can be built on top of Event Futures.

Demand for non-linear payouts

People love the possibility of turning a little bit of money into a lot of money. The most common expression of this in crypto is the use of leverage with perps. As designed, HIP-4 is constrained to 1× margin, disallowing any leverage. Moreover, in prediction markets, allowing leverage doesn’t create infinite upside (there’s no space above 1), but it still shrinks the distance to liquidation and makes users vulnerable to instantaneous jumps in pricing (news, oracle ticks, resolution). For example, during resolution, there’s likely no liquidity to take on distressed positions before the price gaps to 0 or 1, leaving leveraged accounts with bad debt that the platform needs to eat. This is because no liquidator wants to take on a leveraged position at 0.2 if they already know the resolution will take the market down to 0. Isolated margin 1× eliminates these vulnerabilities and keeps the market structure simple and fair. However, this also makes for a less interesting and fun financial product. This is where parlays come in.

Parlays are a cleaner substitute for ‘leverage’ in prediction markets because they scale returns by combining edges as opposed to borrowing risk. Instead of taking a single binary bet and cranking up exposure, you place several 1× bets and link them together via an AND operator; the payout grows when all legs resolve to true, and boosts upside in proportion to how confident (and independent) the user’s views are. In short, parlays help traders compound their edge.

Moreover, parlays are path independent, unlike leverage. Volatile odds cannot ‘liquidate’ users. This is not just important from a payoff perspective, but it’s also super important from a UX perspective if non-professional traders are to engage with such products.

Multi-leg combos have crushed it in the sports betting world: accounting for >70% of all sportsbook revenues.

Having motivated why we think parlays are the right form factor when it comes to increasing the overall convexity and thus interest in prediction markets, we’ll try to build out a rough design for how parlays can be built on top of Event Futures.

First, let’s define a few important terms:

• A parlay is a composite bet that a trader makes wherein they win if and only if all the predicates in the parlay resolve to a yes. For example, if a user bets that: “Lakers will win their 2025/26 NBA season opener AND the Cavaliers will win their 2025/26 NBA season opener”, then both those singular markets have to resolve to a yes for the trader to win the parlay.
• Event Futures as presented in HIP-4 are markets that are settled via the resolution of one binary predicate. In this article, we’ll refer to Event Futures markets that rely on one atomic binary predicate as singles. Example: “Will LeBron score 30 in the Lakers’ 2025/26 NBA season opener?”. NB: If there was an Event Future market for “LeBron will score 30 in the Lakers’ 2025/26 NBA season opener AND the Lakers will win”, it would not be a single since it depends on two separate predicates and is thus non-atomic.
• Under our design, a parlay is a composite bet made up of multiple singles. To repeat: Parlays only support the AND operation over singles, i.e. a parlay resolves to a yes iff the individual singles ALL resolve to yes.

The most trivial way to construct parlays would be to deploy another Event Future that represents the composite like “NUGW AND LALW”. However, this creates a few problems:

• The number of possible parlays blows up very quickly. If we only consider parlays that are the combination of 2 predicates, we find that: If $n = 10$ then ${}^{n}C_{2}$ (total combinations from 10 markets using 2 predicates) $= 45$ but if $n = 100$ then ${}^{n}C_{2} = 4950$. Of course, not all combinations are of interest to traders but it illustrates just how quickly the number of parlay markets becomes untenable. It might not even be possible to deploy all 2-predicate parlays for $n = 1000$ on the HyperCore since the number of orderbooks required would be so large (~500,000).
• The more markets there are, the harder market discovery becomes for traders, leading to worse UX.
• More markets also fundamentally lead to more fragmentation of liquidity which leads to fewer people wanting to take on size in these markets.

Design

Clearly, we believe making composite Event Futures out of singles is a bad idea. So what’s the solution? We propose a framework for JIT parlay creation where users submit trade intents through the UI and liquidity providers compete to fill them. The markets are not deployed onchain but the liquidity providers can use the underlying singles to hedge their position.

The entire lifecycle of the trade would look something like:

• Trader constructs a parlay they want to buy on the frontend. The parlay is composed of Event Future singles.
• Once the parlay is constructed, the trader broadcasts their intent to trade the parlay along with their size to a set of liquidity providers.
• The liquidity providers can use the Event Futures as reference to build out a pricing model for the parlay.
• Each liquidity provider can provide a quote to the user within a predetermined time period.
• The liquidity provider supplying the best price wins the trader’s business.
• Let’s say price $p$ is the agreed upon price for the parlay. The trader wants $p$ to be as low as possible since their payoff per share is $1 - p$. On the other hand, the payoff for the liquidity provider is simply $p$.
• The max loss for each party is the inverse of their profit and is the amount of collateral the protocol will ask them to deposit in escrow during the trade. So, to confirm the trade, the liquidity provider would need to provide $q \times (1 - p)$ to an escrow contract and the trader would need to provide $q \times p$ to the escrow contract. Here, $q$ is the number of shares being traded.
• Once the collateral is escrowed, the trade is assumed to be executed and tokenized representations of the trade can be minted with a claim to the underlying upon resolution. NB: Tokenized versions of the trade can be minted for both the trader and the liquidity provider with conditional resolution. This becomes relevant when we want to allow the liquidity provider to cross-margin across markets to gain capital efficiency. The cross margin section proposes a system using the HyperEVM to increase capital efficiency.

However, the liquidity provider is now exposed to the short leg of these markets. This is where the underlying singles come in; the liquidity provider can use singles to construct the right trade to hedge out their risk. Although the risk hedge is rarely going to be perfect, they can price the parlay in such a way to make the expected payoff worth the opportunity cost for them.

Example

Below we’ll go through the entire trade lifecycle for a user trading NUGW ∧ LALW including some of the math surrounding hedging for liquidity providers:

Singles definition:

• NUGW (Nuggets win): $p_{\text{nugw}} = 0.60$
• LALW (Lakers win): $p_{\text{lalw}} = 0.50$

Assuming independence of the two games, we get:

If the liquidity provider quotes 0.40 to the user since their fair for the market is also 0.30, they’re effectively able to charge a premium because they take on risk and provide the user convexity that would be hard for the user to replicate if they were simply trading the singles.

Quote + size: The market maker quotes $p_{\text{parlay}} = 0.40$. User spends $100 to mint: $q = 100/0.40 = 250$ shares, with a max payout of $250 (2.5× return).

Collateral escrowed (1× isolated, fully collateralized):

• User (long): $100
• Maker (short): $q \times (1 - p) = 250 \times 0.6 = \$150$

Hedging:
While the maker may use singles to price the market, they can also set up hedged positions to reduce their max loss in the case that the parlay plays out. For example, if the Lakers are playing before the Nuggets and end up winning then the maker can hedge out their risk by going long NUGW. Assuming NUGW stays at 0.6, if the maker chooses to long 250 shares of NUGW, they stand to make $(1 - 0.6) \times 250 = 100$, reducing their loss in the case that the trader wins from $150 to $50.

This example is of course overly simplistic but just goes to show how the underlying single and the parlay can go hand in hand to enable liquidity providers to give users completely new trading experiences. However, there is one glaring issue with this design with respect to liquidity provider capital efficiency that we’ll talk about in the next section.

Cross Margin

Fully collateralized, 1× isolated parlays are simple and safe, but capital-inefficient for makers who hedge with singles. Without cross-margin, a maker must post the parlay’s worst-case loss and separately fund hedges—even when those hedges probably shrink the portfolio’s worst-case P&L. A cross-margin vault fixes this by recognizing offsetting risk and extending secured credit up to the initial-margin relief created by the hedge, subject to buffers. Here’s how it works:

• Portfolio view: Margin is computed on the maker’s whole portfolio (short parlay legs + singles hedges), and the account’s required maintenance margin (MM) is set to the portfolio worst-case loss across relevant outcomes, plus buffers. Initial margin (IM) is sized ≥ MM.
• Secured credit against IM relief: When a new hedge reduces the portfolio’s worst-case loss, the vault may extend secured credit up to that IM relief (minus a haircut/buffer). Credit is only usable inside the cross-margin account.
• No leverage beyond the worst case: Even with credit, the account always holds enough collateral to cover the portfolio’s maximum possible payout to winners in all scenarios.
• Settlement priority: Any secured credit is repaid from realized P&L before collateral is releasable.

Extending the NUGW ∧ LALW to allow for cross-margin we get:

• Trade: User buys $q = 250$ shares of NUGW ∧ LALW at $p = 0.40$
  • User escrows $q \times p = \$100$
  • Maker escrows $q \times (1 - p) = 250 \times 0.60 = \$150$
• After LALW resolves YES: (first game completes), the parlay now pays YES if NUGW resolves YES. Suppose NUGW still trades at 0.60. If the maker buys $x = 250$ NUGW at 0.60, portfolio outcomes are:
  • If NUGW = YES: parlay loss = $150, hedge gain = $100
  • If NUGW = NO: parlay gain = $100, hedge loss = $150
  • Result: The hedge reduces worst-case from $150 to $50, so IM relief = $100. The vault can therefore extend up to $100 of secured credit (less buffers) to fund the hedge.
• How funds flow: The maker needs $150 to buy 250 NUGW at 0.60. The vault can:
  • lend (inside the account) $100 secured credit, and
  • require $50 from the maker.

The cross-margining logic can be extended by an underlying graph structure that draws correlations between Event Futures, such as partitions, mutual exclusivity, and implications. A margin engine can utilize the graph to efficiently calculate maintenance margin requirements and enhance capital efficiency.

Such a protocol needs to be built on the HyperEVM and interact with the HyperCore through the CoreWriter, since it’s not feasible to update the Event Futures metadata and store the relations on the HyperCore. The proposed graph structure would also grow on the order of $O(n^2)$, where $n$ is the number of markets, which may even be better computed offchain and accessed onchain via coprocessors.

A Note from the Authors

HIP-4 opens a new design space for builders to create net new financial products. This article is meant to showcase that interest and potential. By providing a rough design for how a popular sports betting product can be replicated on top of Event Futures, we aim to demonstrate just one of the many new and interesting financial products in the home of all of finance.

If you’d be interested in jamming around this design space more, feel free to reach out to us via Twitter DMs! (Our Twitters are linked at the top of this post.)