Papertrade: The House Always Wins
Can a pool funded by nothing but the losses of the people trading against it survive the people trading against it? We simulated it 27,360 times to find out.
Papertrade: The House Always Wins
Can a pool funded by nothing but the losses of the people trading against it survive the people trading against it? We simulated it 27,360 times to find out.
1. Introduction
Papertrade is a synthetic perpetual protocol built on HyperEVM, offering up to 1000x leverage with no slippage. This is possible because trades on Papertrade are not matched against other users; instead, every position is a synthetic swap between the trader and the LP, which starts at $0 and is funded entirely by trading activity.
When a user opens a position, the contract reads Hyperliquid's Best Bid and Offer (BBO) mid price through a precompile and locks that price as the entry. When the position is closed, the contract reads the BBO mid again in the next block and settles the resulting PnL directly against the LP. As no perpetual contract is opened, traders pay no funding; and because execution happens at the BBO mid rather than through an order book, there is no slippage regardless of trade size.
2. How Papertrade works
The synthetic trade
On most perpetual trading venues, your counterparty is another trader (an order book). On Papertrade, your counterparty is always the LP and your trades are always synthetic.
If you close at a loss your lost margin moves to the LP, but if you close at a profit, the protocol applies what it calls asymmetric impact to your realised gain. The asymmetric impact is a smooth scale factor applied on top of the raw gain. This scale factor is inversely proportional to the move a trader captures: the bigger the swing, the smaller the haircut - which incentivises users to chase large moves.
The formula for a winning close is:

baseRate, rateMultiplier, positionMultiplier, and referenceNotional are per-instrument governance parameters. As move increases, both term1 and term2 decrease, and the denominator approaches 1, meaning the trader keeps a larger share of their rawPnl. As move approaches zero, term1 and term2 tend to infinity and the adjustedPnl collapses to zero.
There is a second, subtler reason for this PnL curve shape. Because the haircut is steepest on the smallest moves, an attacker who briefly distorts the order book to engineer a small profitable close finds almost the entire gain consumed by the steepness of the curve.
The queue
Now the obvious problem. Since the LP starts at $0, what happens when the very first trade is a winner?
If a trader wins and the LP cannot cover the full payout (margin plus winnings), the margin is always returned, and the remaining winnings (after the asymmetric impact) are placed in a First In First Out (FIFO) queue. When the LP later receives money (from a loss or a liquidation), that money pays down the queue in order of arrival before it is allowed to grow the LP balance.
As long as traders keep coming back (and losing, filling up the LP), the protocol can keep paying winning trades.
The main concern is that a rational trader won't willingly trade against a pool that might not pay them, or an empty one. To counteract that, Papertrade pays its losing traders in $PAPER. Every dollar that moves into the LP from a loss or a liquidation mints the token. The rate is highest in the pool's earliest and most fragile days and decays as the LP grows, so the earliest losers mint far more per dollar than anyone who arrives later.

Once the LP fills its $5M cap, further trader losses route to $PAPER stakers rather than growing the pool. That is all the token detail this piece needs. What stakers actually earn on that stream, how the yield compares to the token's inflation, and whether holding $PAPER is economically rational, are the subject of a separate follow-up. Here the question is narrower, whether the pool itself survives.
3. Research Objective
While the protocol's economic architecture functions cohesively in theory, its long-term operational viability hinges on a critical, path-dependent assumption, that aggregate trader losses consistently outpace payouts to profitable counterparties.
Consequently, the central focus of this research is the structural sustainability of this mechanism. The underlying incentives exhibit intense reflexivity. The economic justification for minting $PAPER is entirely contingent upon LP solvency, yet the pool's solvency is inherently dependent on continuous trader liquidations.
We formally evaluate whether the LP can maintain structural solvency when funded exclusively by counterparty losses and bootstrapped entirely by token emissions, in a 1000x leverage environment. Whether the token that funds this is worth holding - how its yield compares to its inflation, and whether the incentive to lose survives as emission decays - is a separate question we take up in a follow-up.
Here the question is narrower: does the pool itself survive.
To rigorously stress-test the architecture, we simulated over 27,000 outcomes modelled on Hyperliquid's real trading data.
4. Data Acquisition and Leverage Reconstruction
The empirical data of this analysis rests on three distinct data streams extracted from Hyperliquid: historical state snapshots, discrete trade execution fills from Hydromancer, and per-position leverage records from the HyperTracker API.
The snapshot dataset spans approximately 238 days but contains a 53-day gap extending from late October to mid-December 2025. Because of that, trade execution fills were ingested to capture every BTC and ETH transaction from August 1, 2025 onward, ensuring continuity. Additionally, HyperTracker per-position leverage data was obtained to provide ground-truth leverage readings independent of the snapshot schedule.
Integrating these three data types required reconciling distinct structural limitations:
- State Snapshots. Provided a direct reading of account leverage but were limited to daily frequency. Consequently, intraday positions opened and closed between snapshots were omitted.
- Execution Fills. Provided a high-fidelity, comprehensive ledger of all Hyperliquid activity, but lacked explicit metadata regarding leverage.
- HyperTracker Positions. Provided per-position leverage at the time of opening. BTC coverage is complete across the full simulation window (August 2025 to May 2026); ETH coverage extends from August to December 2025, with the remaining period relying on drawdown-bound classification and snapshots.
5. Assumptions
- We keep only the trades we could confirm ran at maximum leverage (40x on BTC, 25x on ETH), on the premise that Paper's 1000x venue draws the high-risk crowd that Hyperliquid's serious traders are not part of. This is the study's load-bearing assumption: it selects the population most likely to lose, and therefore most likely to keep the LP solvent, so we read the full-grid solvency result as conditional on it and return to how much it depends on the analogue in Limitations.
- Hyperliquid imposes no maximum notional per trade; Papertrade caps opening notional at $10M. We rescale the notional distribution linearly so its 99.9th percentile maps to the cap, then clamp the residual tail at $10M - preserving the shape of the size distribution below the cap while respecting the protocol's ceiling.
- We model four levels of traction (25%, 50%, 75%, 100% of flow) by random subsampling, so lower flow is a random thinning of the same population with composition held fixed. A smaller or newer venue might draw a different mix, but absent data on what that mix would be, neutral subsampling is the conservative choice and preserves the size distribution at every level.
- Where Paper's documentation publishes a parameter, we hold it fixed; everything else is ours - including the four impact-curve knobs, which the documentation leaves as per-instrument governance parameters and which decide how much of a win a trader keeps. We flag plainly that this central curve is calibrated by us, not given, and show in Results that LP-level outcomes stay near-flat across all 45 impact-parameter combinations we sweep, so the verdict does not hinge on landing on the true values.
- We model BTC and ETH only, and treat the Hyperliquid prices in our data as the prices Paper would settle against - assuming the spread between a fill and the BBO mid, and the one-block lag between Paper's entry and exit reads, are negligible against the large moves that dominate this dataset.
- We model no trading fee or gas cost beyond the asymmetric-impact haircut, and treat a position as liquidated the moment its worst adverse move reaches the 5bps tolerance. Both choices are conservative for the LP: ignoring fees understates protocol income, and the liquidation mapping is, if anything, generous to the trader.
6. Limitations
Once-daily snapshots miss intraday positions. We argue these are negligible for this purpose, but it is an assumption, not a measurement.
Leverage reconstructed from fills is imprecise, particularly for cross-margin positions in the 53-day gap.
Behavioural analogue, not the real population. Max-leverage Hyperliquid traders are a proxy for Papertrade degens. Papertrade's own incentives (minting $PAPER on losses) would likely shift behaviour further toward risk than the source data shows.
No reflexive $PAPER price feedback. The simulation models the LP and emission mechanics, not the market price of $PAPER.
OI safety caps assumed non-binding. The $10M notional cap is enforced; the separate OI safety caps are assumed not to have bound in the simulated window.
7. Methodology
What we simulated
We implemented Papertrade's complete settlement mechanism and pushed all 3.6M trades through it in chronological order, day by day, from day 0 to day 289. The mechanics are exactly as described above under How Papertrade works. This section covers the parameters we had to pin down, and the modelling assumptions we layered on top.
Parameters, from the docs vs chosen by us
Every number in the simulation falls into one of two buckets. The first comes straight from Papertrade's documentation and is held fixed. The second is ours because the docs leave it open, and we had to estimate it.

A liquidation threshold of 5bps means a position is treated as liquidated once its worst adverse move reaches 0.05%.
tailScaleUsd is the parameter that controls the shape of the emission decay, the larger it is, the more slowly minting ratchets down once the LP clears $2M.
stakerPct is the slice of protocol income peeled off for $PAPER stakers while the LP is under $5M.
Parameters we chose (and why):
The docs describe the impact curve's four knobs (baseRate, rateMultiplier, positionMultiplier, and referenceNotional) as per-instrument governance parameters but don't publish specific values, so the numbers we use are our own assumption of the most plausible configuration.
Two of the four curve knobs we fixed on algebraic grounds, because sweeping them adds scenarios without adding information:
rateMultiplier, fixed at 1,000. Sweeping it from 100 to 5,000 moves the results by under 3%.term1 = 1/(move × rateMult)only dominates for moves well below 0.1%, whereterm2has already driven scale ≈ 0, so the knob barely touches any move large enough to matter.positionMultiplier, fixed at $10M. Only the ratioreferenceNotional/positionMultiplierentersterm2, not the two values separately ($100K / $10M is the same 0.01 as $50K / $5M). Fixing one and sweeping the reference notional already covers the whole space.
That leaves three parameters we sweep, each centred on our most-likely assumed value:
baseRate [0.02, 0.03, 0.05, 0.07, 0.10]. This is the minimum share of any win the LP keeps. At 0.02 it keeps just 2% (generous to the trader) and at 0.10 it keeps at least 10% (better protected); our central assumption of 0.05 sits in the middle. We don't go below 2% as it would leave the LP almost unprotected, and we don't go above 10%, because past that the trader can't keep even 85% of a full 10% move, which stops being competitive against a real venue.
btcReferenceNotional [$75K, $100K, $125K]. This knob sets how tight the BTC curve is; lower values are more permissive (the trader keeps more of each win). We centre the sweep on our assumed $100K and move ±25% around it. The bottom of the range is set by safety. BTC's real spread on Hyperliquid is roughly 0.001%, and at a move that small the scale stays below 0.001 across all three values, which leaves an enormous margin against oracle-poke attacks (someone nudging the book to create a tiny profitable close). The top of the range is set by how attractive the curve still is to a trader. As BTC liquidates 80.0% of the time and pays off only 11.6% of the time in our data, the curve has to leave real money on the winning closes: at $75K a trader keeps more than 25% of a 0.30% move, a size a meaningful share of real BTC winners reach, while at $125K that threshold only arrives at a 0.48% move, which far fewer do. Past $125K the curve eats too much of the rare wins to stay worth trading.
ethReferenceNotional [$50K, $75K, $100K]. The same knob for ETH, except the sweep starts at our assumed $50K and only rises. The floor is set by two things. First, the ETH trader's odds are worse than the BTC trader's as ETH liquidates 91.5% of the time (versus 80.0% for BTC) and pays off only 6.7% of the time (versus 11.6%), even though the wins it does produce run noticeably larger. More frequent liquidations and rarer payoffs make the ETH trader's expected loss per trade larger than the BTC trader's, about $106 against $63 in our data, because the larger moves on the few winners don't make up for how often the position is wiped out. That worse EV is why we keep ETH's curve more permissive than BTC's. Second, against ETH's real Hyperliquid spread of ~0.005%, the scale at the spread stays just as negligible across $50K to $100K as it does on BTC, so oracle-poke risk isn't the binding constraint. What is binding is the LP, as dropping below $50K would improve the trader's EV only by deepening LP losses in the more volatile of the two markets.
The reason ETH is wiped more often than BTC is the size of the moves. The worst adverse move on a typical BTC max-leverage trade is around 0.22%, and on ETH around 0.41%, both far past the 0.05% liquidation line. Taken at their real Hyperliquid maximum of 40x on BTC and 25x on ETH, the same trades were liquidated only 7.8% and 6.1% of the time.


Modelling choices
Flow fractions. Among our 3.6M trades we simulate four flow levels - 25%, 50%, 75%, 100% - by random sampling; see assumption 3.
Start days. As some windows are far more volatile than others, sweeping the start date isolates how much the verdict depends on the luck of when the protocol goes live, that's why we simulated 38 launch dates, one every 7 days.
ADL worst-case. As Papertrade doesn't have ADL but our data does, we run the grid with auto-deleveraging off and on. Off, trades are replayed as-is. On, we use real Hyperliquid ADL data and see what happens if all the trades that got auto-deleveraged closed at the tip of that day's wick (the most the trader's PnL could have reached on a given day). This is a deliberate worst case.
Emission-based volume. This is the one assumption that feeds the mechanism back into trader behaviour, and it deserves spelling out. The main reason to trade into this LP at all is the $PAPER you mint by losing; as the LP matures past $2M and emission decays, that incentive weakens, so we could expect the flow to contract over time.

The full simulation code is available here.
8. Results
Unless a chart says otherwise, every figure in this section uses the default parameters (baseRate 5%, BTC reference notional $100k, ETH $50k) for legibility. The verdict rests on two facts.
The impact curve
.png)
.png)
These show the scale factor a winning trade keeps as a function of how far price moved, for every combination of baseRate and referenceNotional in the sweep. Tuning baseRate alone barely moves the curve (the left panels); adding the referenceNotional widens it into a band, but every curve keeps the same shape and the same broad level, and at larger moves they reconverge toward the cap. A 1% move keeps somewhere around 55 to 70% of the raw gain across the whole sweep; a 5% move keeps roughly 75 to 87%. The parameter choice shifts where in that band a trader lands.
The second fact is that the LP-level outcomes are nearly parameter-flat. The full-grid verdict below holds across all 45 impact-parameter combinations at once, so the default-parameter charts faithfully represent the whole grid. Plotting all 45 curves on every figure would just add ink. Where the parameter choice could in principle matter, we say so and fall back on the full-grid aggregates instead.
The survival rate
Across the full grid of 27,360 scenarios, spanning every parameter combination, every launch date, both ADL modes, and both volume models, the pool ends solvent in 100% of runs - for the max-leverage cohort this study models, which is by construction the population most prone to the losses that feed the pool.. Better than that, in more than 85% of scenarios the pool never has to queue a single winner as the LP absorbs the early losses fast enough that there is almost always cash on hand to pay whoever wins.

When the pool does fall short, the shortfall is trivial and instant. Across all 27,360 runs the largest single unpaid amount ever recorded is $32k and the queue never holds more than 44 trades at once. Every instance of debt resolves within a single simulation day, and none survives to the end of a run.

Note: the scatter shows only the scenarios with default impact parameters (btcBaseRate 5%, btcReferenceNotional $100K, ethReferenceNotional $50K), where the maximum peak debt is ~$26.5K. The $32K value reported in Figure 5 corresponds to a more conservative parameter combination (btcBaseRate 2%, btcReferenceNotional $75K) that reduces the fee charged per trade, lengthens queue resolution, and increases peak debt. In all cases the debt is resolved within the same simulation day.
The reason debt is so rare is that the pool fills almost immediately. Starting from $0, it reaches the $5M cap within days. Launching on day 0 at full flow, the LP hits $5M in 2 days and even at a quarter of Hyperliquid's real max-leverage volume it gets there in roughly 7 days. Flow is the only thing that materially changes the speed, more traders means a faster fill. The impact-curve parameters barely move it, as the spread between the fastest and slowest parameter combination at a given launch date is a day or less.

Launch timing matters only at the edges, as we see below. Pools that go live into the most volatile stretch of the sample, late 2025, take a little longer to fill and account for almost all of the rare debt events, but they still reach the cap and still end solvent. The handful of scenarios that never reach $5M are late launches whose 290-day data window simply ends before the pool gets there, and even those finish with zero residual debt.

Turning on real Hyperliquid auto-deleveraging, our deliberately worst-case stress, leaves LP recovery visually unchanged as the pool is fed fast enough to absorb even the inflated winners. On the other hand, the pessimistic flow model, where trader volume contracts in lockstep with the fading $PAPER incentive, shrinks the entire economy around the pool (less volume, less $PAPER, smaller trader losses) without threatening survival. The LP still fills to $5M from every launch date.

So the first question is settled, a pool seeded at zero: a pool seeded at zero and funded by losses does stay solvent at 1000x leverage, and it hits its own cap within days, under every configuration we tested.
The trader's side
The trader loses, and the loss is the whole point. Net of every win, traders give up between $60M and $270M over the window in the base model, rising in step with flow, and between $50M and $122M under the pessimistic model. No flow level, launch date, or parameter setting produces a trader cohort that ends ahead in cash.

The size of the bleed is clearer in margin terms. Every position runs at 1000x, so the $350B of notional at full flow was opened against about $350M of posted margin, and traders lost $270M of it. That is close to 77 cents gone for every dollar of margin put up.

Across all eight flow and model cells, the trader's net loss equals the $5M LP plus cumulative staker fees. At full flow the $270M traders lost is the $5M held in the pool plus the $265M paid to stakers. Nothing leaks out of the system. Every dollar the trader gives up is a dollar the protocol keeps, and once the pool caps, a dollar the stakers keep. The curves tend towards 0 because the later the simulation starts, the fewer losses accumulate.
So in cash the house wins. The reason anyone plays is that the same dollar of loss mints $PAPER, and a cash-negative trader is not necessarily token-negative. Whether that token claim is worth enough to make losing rational, and who ends up capturing it, is the question the follow-up takes up.
9. Conclusions
The first thing the simulation settles is that the mechanism works. A counterparty pool seeded at zero, funded by nothing but trader losses, running positions at 1000x, is the kind of design that sounds like it should fail on contact with a volatile market but it does not. In every one of the 27,360 scenarios the pool stays solvent, and in all but a handful of late-launch runs it fills its $5m cap within days, and the rare moments when a winner cannot be paid resolve the same day.
What makes the design interesting is that losing early is rewarded, because the same loss mints $PAPER at the one-cent floor, and that token is a claim on every loss that comes after. The protocol turns its earliest and most loss-prone users into its equity holders. The people who fund the pool in its first weeks are the ones who own the largest and cheapest share of its future revenue. It is a recruitment mechanism wearing the clothes of a token, and the data shows it working.
A trader who understands this has a reason to show up first and lose on purpose, which is a strange sentence to write about a derivatives venue and the clearest sign the design is doing something new. Whether that claim actually pays, how the yield compares to the token's inflation, and when the flywheel holds or breaks, is what the follow-up measures. On the narrower question this piece set out to answer, the verdict is clean. The pool cannot be drained, it fills its cap within days, and it stays solvent under every configuration we tested.
The pool cannot be drained. Whether the token makes it worth filling is the next question.

Papertrade: The House Always Wins
Can a pool funded by nothing but the losses of the people trading against it survive the people trading against it? We simulated it 27,360 times to find out.

Papertrade: The House Always Wins
Can a pool funded by nothing but the losses of the people trading against it survive the people trading against it? We simulated it 27,360 times to find out.
1. Introduction
Papertrade is a synthetic perpetual protocol built on HyperEVM, offering up to 1000x leverage with no slippage. This is possible because trades on Papertrade are not matched against other users; instead, every position is a synthetic swap between the trader and the LP, which starts at $0 and is funded entirely by trading activity.
When a user opens a position, the contract reads Hyperliquid's Best Bid and Offer (BBO) mid price through a precompile and locks that price as the entry. When the position is closed, the contract reads the BBO mid again in the next block and settles the resulting PnL directly against the LP. As no perpetual contract is opened, traders pay no funding; and because execution happens at the BBO mid rather than through an order book, there is no slippage regardless of trade size.
2. How Papertrade works
The synthetic trade
On most perpetual trading venues, your counterparty is another trader (an order book). On Papertrade, your counterparty is always the LP and your trades are always synthetic.
If you close at a loss your lost margin moves to the LP, but if you close at a profit, the protocol applies what it calls asymmetric impact to your realised gain. The asymmetric impact is a smooth scale factor applied on top of the raw gain. This scale factor is inversely proportional to the move a trader captures: the bigger the swing, the smaller the haircut - which incentivises users to chase large moves.
The formula for a winning close is:

baseRate, rateMultiplier, positionMultiplier, and referenceNotional are per-instrument governance parameters. As move increases, both term1 and term2 decrease, and the denominator approaches 1, meaning the trader keeps a larger share of their rawPnl. As move approaches zero, term1 and term2 tend to infinity and the adjustedPnl collapses to zero.
There is a second, subtler reason for this PnL curve shape. Because the haircut is steepest on the smallest moves, an attacker who briefly distorts the order book to engineer a small profitable close finds almost the entire gain consumed by the steepness of the curve.
The queue
Now the obvious problem. Since the LP starts at $0, what happens when the very first trade is a winner?
If a trader wins and the LP cannot cover the full payout (margin plus winnings), the margin is always returned, and the remaining winnings (after the asymmetric impact) are placed in a First In First Out (FIFO) queue. When the LP later receives money (from a loss or a liquidation), that money pays down the queue in order of arrival before it is allowed to grow the LP balance.
As long as traders keep coming back (and losing, filling up the LP), the protocol can keep paying winning trades.
The main concern is that a rational trader won't willingly trade against a pool that might not pay them, or an empty one. To counteract that, Papertrade pays its losing traders in $PAPER. Every dollar that moves into the LP from a loss or a liquidation mints the token. The rate is highest in the pool's earliest and most fragile days and decays as the LP grows, so the earliest losers mint far more per dollar than anyone who arrives later.

Once the LP fills its $5M cap, further trader losses route to $PAPER stakers rather than growing the pool. That is all the token detail this piece needs. What stakers actually earn on that stream, how the yield compares to the token's inflation, and whether holding $PAPER is economically rational, are the subject of a separate follow-up. Here the question is narrower, whether the pool itself survives.
3. Research Objective
While the protocol's economic architecture functions cohesively in theory, its long-term operational viability hinges on a critical, path-dependent assumption, that aggregate trader losses consistently outpace payouts to profitable counterparties.
Consequently, the central focus of this research is the structural sustainability of this mechanism. The underlying incentives exhibit intense reflexivity. The economic justification for minting $PAPER is entirely contingent upon LP solvency, yet the pool's solvency is inherently dependent on continuous trader liquidations.
We formally evaluate whether the LP can maintain structural solvency when funded exclusively by counterparty losses and bootstrapped entirely by token emissions, in a 1000x leverage environment. Whether the token that funds this is worth holding - how its yield compares to its inflation, and whether the incentive to lose survives as emission decays - is a separate question we take up in a follow-up.
Here the question is narrower: does the pool itself survive.
To rigorously stress-test the architecture, we simulated over 27,000 outcomes modelled on Hyperliquid's real trading data.
4. Data Acquisition and Leverage Reconstruction
The empirical data of this analysis rests on three distinct data streams extracted from Hyperliquid: historical state snapshots, discrete trade execution fills from Hydromancer, and per-position leverage records from the HyperTracker API.
The snapshot dataset spans approximately 238 days but contains a 53-day gap extending from late October to mid-December 2025. Because of that, trade execution fills were ingested to capture every BTC and ETH transaction from August 1, 2025 onward, ensuring continuity. Additionally, HyperTracker per-position leverage data was obtained to provide ground-truth leverage readings independent of the snapshot schedule.
Integrating these three data types required reconciling distinct structural limitations:
- State Snapshots. Provided a direct reading of account leverage but were limited to daily frequency. Consequently, intraday positions opened and closed between snapshots were omitted.
- Execution Fills. Provided a high-fidelity, comprehensive ledger of all Hyperliquid activity, but lacked explicit metadata regarding leverage.
- HyperTracker Positions. Provided per-position leverage at the time of opening. BTC coverage is complete across the full simulation window (August 2025 to May 2026); ETH coverage extends from August to December 2025, with the remaining period relying on drawdown-bound classification and snapshots.
5. Assumptions
- We keep only the trades we could confirm ran at maximum leverage (40x on BTC, 25x on ETH), on the premise that Paper's 1000x venue draws the high-risk crowd that Hyperliquid's serious traders are not part of. This is the study's load-bearing assumption: it selects the population most likely to lose, and therefore most likely to keep the LP solvent, so we read the full-grid solvency result as conditional on it and return to how much it depends on the analogue in Limitations.
- Hyperliquid imposes no maximum notional per trade; Papertrade caps opening notional at $10M. We rescale the notional distribution linearly so its 99.9th percentile maps to the cap, then clamp the residual tail at $10M - preserving the shape of the size distribution below the cap while respecting the protocol's ceiling.
- We model four levels of traction (25%, 50%, 75%, 100% of flow) by random subsampling, so lower flow is a random thinning of the same population with composition held fixed. A smaller or newer venue might draw a different mix, but absent data on what that mix would be, neutral subsampling is the conservative choice and preserves the size distribution at every level.
- Where Paper's documentation publishes a parameter, we hold it fixed; everything else is ours - including the four impact-curve knobs, which the documentation leaves as per-instrument governance parameters and which decide how much of a win a trader keeps. We flag plainly that this central curve is calibrated by us, not given, and show in Results that LP-level outcomes stay near-flat across all 45 impact-parameter combinations we sweep, so the verdict does not hinge on landing on the true values.
- We model BTC and ETH only, and treat the Hyperliquid prices in our data as the prices Paper would settle against - assuming the spread between a fill and the BBO mid, and the one-block lag between Paper's entry and exit reads, are negligible against the large moves that dominate this dataset.
- We model no trading fee or gas cost beyond the asymmetric-impact haircut, and treat a position as liquidated the moment its worst adverse move reaches the 5bps tolerance. Both choices are conservative for the LP: ignoring fees understates protocol income, and the liquidation mapping is, if anything, generous to the trader.
6. Limitations
Once-daily snapshots miss intraday positions. We argue these are negligible for this purpose, but it is an assumption, not a measurement.
Leverage reconstructed from fills is imprecise, particularly for cross-margin positions in the 53-day gap.
Behavioural analogue, not the real population. Max-leverage Hyperliquid traders are a proxy for Papertrade degens. Papertrade's own incentives (minting $PAPER on losses) would likely shift behaviour further toward risk than the source data shows.
No reflexive $PAPER price feedback. The simulation models the LP and emission mechanics, not the market price of $PAPER.
OI safety caps assumed non-binding. The $10M notional cap is enforced; the separate OI safety caps are assumed not to have bound in the simulated window.
7. Methodology
What we simulated
We implemented Papertrade's complete settlement mechanism and pushed all 3.6M trades through it in chronological order, day by day, from day 0 to day 289. The mechanics are exactly as described above under How Papertrade works. This section covers the parameters we had to pin down, and the modelling assumptions we layered on top.
Parameters, from the docs vs chosen by us
Every number in the simulation falls into one of two buckets. The first comes straight from Papertrade's documentation and is held fixed. The second is ours because the docs leave it open, and we had to estimate it.

A liquidation threshold of 5bps means a position is treated as liquidated once its worst adverse move reaches 0.05%.
tailScaleUsd is the parameter that controls the shape of the emission decay, the larger it is, the more slowly minting ratchets down once the LP clears $2M.
stakerPct is the slice of protocol income peeled off for $PAPER stakers while the LP is under $5M.
Parameters we chose (and why):
The docs describe the impact curve's four knobs (baseRate, rateMultiplier, positionMultiplier, and referenceNotional) as per-instrument governance parameters but don't publish specific values, so the numbers we use are our own assumption of the most plausible configuration.
Two of the four curve knobs we fixed on algebraic grounds, because sweeping them adds scenarios without adding information:
rateMultiplier, fixed at 1,000. Sweeping it from 100 to 5,000 moves the results by under 3%.term1 = 1/(move × rateMult)only dominates for moves well below 0.1%, whereterm2has already driven scale ≈ 0, so the knob barely touches any move large enough to matter.positionMultiplier, fixed at $10M. Only the ratioreferenceNotional/positionMultiplierentersterm2, not the two values separately ($100K / $10M is the same 0.01 as $50K / $5M). Fixing one and sweeping the reference notional already covers the whole space.
That leaves three parameters we sweep, each centred on our most-likely assumed value:
baseRate [0.02, 0.03, 0.05, 0.07, 0.10]. This is the minimum share of any win the LP keeps. At 0.02 it keeps just 2% (generous to the trader) and at 0.10 it keeps at least 10% (better protected); our central assumption of 0.05 sits in the middle. We don't go below 2% as it would leave the LP almost unprotected, and we don't go above 10%, because past that the trader can't keep even 85% of a full 10% move, which stops being competitive against a real venue.
btcReferenceNotional [$75K, $100K, $125K]. This knob sets how tight the BTC curve is; lower values are more permissive (the trader keeps more of each win). We centre the sweep on our assumed $100K and move ±25% around it. The bottom of the range is set by safety. BTC's real spread on Hyperliquid is roughly 0.001%, and at a move that small the scale stays below 0.001 across all three values, which leaves an enormous margin against oracle-poke attacks (someone nudging the book to create a tiny profitable close). The top of the range is set by how attractive the curve still is to a trader. As BTC liquidates 80.0% of the time and pays off only 11.6% of the time in our data, the curve has to leave real money on the winning closes: at $75K a trader keeps more than 25% of a 0.30% move, a size a meaningful share of real BTC winners reach, while at $125K that threshold only arrives at a 0.48% move, which far fewer do. Past $125K the curve eats too much of the rare wins to stay worth trading.
ethReferenceNotional [$50K, $75K, $100K]. The same knob for ETH, except the sweep starts at our assumed $50K and only rises. The floor is set by two things. First, the ETH trader's odds are worse than the BTC trader's as ETH liquidates 91.5% of the time (versus 80.0% for BTC) and pays off only 6.7% of the time (versus 11.6%), even though the wins it does produce run noticeably larger. More frequent liquidations and rarer payoffs make the ETH trader's expected loss per trade larger than the BTC trader's, about $106 against $63 in our data, because the larger moves on the few winners don't make up for how often the position is wiped out. That worse EV is why we keep ETH's curve more permissive than BTC's. Second, against ETH's real Hyperliquid spread of ~0.005%, the scale at the spread stays just as negligible across $50K to $100K as it does on BTC, so oracle-poke risk isn't the binding constraint. What is binding is the LP, as dropping below $50K would improve the trader's EV only by deepening LP losses in the more volatile of the two markets.
The reason ETH is wiped more often than BTC is the size of the moves. The worst adverse move on a typical BTC max-leverage trade is around 0.22%, and on ETH around 0.41%, both far past the 0.05% liquidation line. Taken at their real Hyperliquid maximum of 40x on BTC and 25x on ETH, the same trades were liquidated only 7.8% and 6.1% of the time.


Modelling choices
Flow fractions. Among our 3.6M trades we simulate four flow levels - 25%, 50%, 75%, 100% - by random sampling; see assumption 3.
Start days. As some windows are far more volatile than others, sweeping the start date isolates how much the verdict depends on the luck of when the protocol goes live, that's why we simulated 38 launch dates, one every 7 days.
ADL worst-case. As Papertrade doesn't have ADL but our data does, we run the grid with auto-deleveraging off and on. Off, trades are replayed as-is. On, we use real Hyperliquid ADL data and see what happens if all the trades that got auto-deleveraged closed at the tip of that day's wick (the most the trader's PnL could have reached on a given day). This is a deliberate worst case.
Emission-based volume. This is the one assumption that feeds the mechanism back into trader behaviour, and it deserves spelling out. The main reason to trade into this LP at all is the $PAPER you mint by losing; as the LP matures past $2M and emission decays, that incentive weakens, so we could expect the flow to contract over time.

The full simulation code is available here.
8. Results
Unless a chart says otherwise, every figure in this section uses the default parameters (baseRate 5%, BTC reference notional $100k, ETH $50k) for legibility. The verdict rests on two facts.
The impact curve
.png)
.png)
These show the scale factor a winning trade keeps as a function of how far price moved, for every combination of baseRate and referenceNotional in the sweep. Tuning baseRate alone barely moves the curve (the left panels); adding the referenceNotional widens it into a band, but every curve keeps the same shape and the same broad level, and at larger moves they reconverge toward the cap. A 1% move keeps somewhere around 55 to 70% of the raw gain across the whole sweep; a 5% move keeps roughly 75 to 87%. The parameter choice shifts where in that band a trader lands.
The second fact is that the LP-level outcomes are nearly parameter-flat. The full-grid verdict below holds across all 45 impact-parameter combinations at once, so the default-parameter charts faithfully represent the whole grid. Plotting all 45 curves on every figure would just add ink. Where the parameter choice could in principle matter, we say so and fall back on the full-grid aggregates instead.
The survival rate
Across the full grid of 27,360 scenarios, spanning every parameter combination, every launch date, both ADL modes, and both volume models, the pool ends solvent in 100% of runs - for the max-leverage cohort this study models, which is by construction the population most prone to the losses that feed the pool.. Better than that, in more than 85% of scenarios the pool never has to queue a single winner as the LP absorbs the early losses fast enough that there is almost always cash on hand to pay whoever wins.

When the pool does fall short, the shortfall is trivial and instant. Across all 27,360 runs the largest single unpaid amount ever recorded is $32k and the queue never holds more than 44 trades at once. Every instance of debt resolves within a single simulation day, and none survives to the end of a run.

Note: the scatter shows only the scenarios with default impact parameters (btcBaseRate 5%, btcReferenceNotional $100K, ethReferenceNotional $50K), where the maximum peak debt is ~$26.5K. The $32K value reported in Figure 5 corresponds to a more conservative parameter combination (btcBaseRate 2%, btcReferenceNotional $75K) that reduces the fee charged per trade, lengthens queue resolution, and increases peak debt. In all cases the debt is resolved within the same simulation day.
The reason debt is so rare is that the pool fills almost immediately. Starting from $0, it reaches the $5M cap within days. Launching on day 0 at full flow, the LP hits $5M in 2 days and even at a quarter of Hyperliquid's real max-leverage volume it gets there in roughly 7 days. Flow is the only thing that materially changes the speed, more traders means a faster fill. The impact-curve parameters barely move it, as the spread between the fastest and slowest parameter combination at a given launch date is a day or less.

Launch timing matters only at the edges, as we see below. Pools that go live into the most volatile stretch of the sample, late 2025, take a little longer to fill and account for almost all of the rare debt events, but they still reach the cap and still end solvent. The handful of scenarios that never reach $5M are late launches whose 290-day data window simply ends before the pool gets there, and even those finish with zero residual debt.

Turning on real Hyperliquid auto-deleveraging, our deliberately worst-case stress, leaves LP recovery visually unchanged as the pool is fed fast enough to absorb even the inflated winners. On the other hand, the pessimistic flow model, where trader volume contracts in lockstep with the fading $PAPER incentive, shrinks the entire economy around the pool (less volume, less $PAPER, smaller trader losses) without threatening survival. The LP still fills to $5M from every launch date.

So the first question is settled, a pool seeded at zero: a pool seeded at zero and funded by losses does stay solvent at 1000x leverage, and it hits its own cap within days, under every configuration we tested.
The trader's side
The trader loses, and the loss is the whole point. Net of every win, traders give up between $60M and $270M over the window in the base model, rising in step with flow, and between $50M and $122M under the pessimistic model. No flow level, launch date, or parameter setting produces a trader cohort that ends ahead in cash.

The size of the bleed is clearer in margin terms. Every position runs at 1000x, so the $350B of notional at full flow was opened against about $350M of posted margin, and traders lost $270M of it. That is close to 77 cents gone for every dollar of margin put up.

Across all eight flow and model cells, the trader's net loss equals the $5M LP plus cumulative staker fees. At full flow the $270M traders lost is the $5M held in the pool plus the $265M paid to stakers. Nothing leaks out of the system. Every dollar the trader gives up is a dollar the protocol keeps, and once the pool caps, a dollar the stakers keep. The curves tend towards 0 because the later the simulation starts, the fewer losses accumulate.
So in cash the house wins. The reason anyone plays is that the same dollar of loss mints $PAPER, and a cash-negative trader is not necessarily token-negative. Whether that token claim is worth enough to make losing rational, and who ends up capturing it, is the question the follow-up takes up.
9. Conclusions
The first thing the simulation settles is that the mechanism works. A counterparty pool seeded at zero, funded by nothing but trader losses, running positions at 1000x, is the kind of design that sounds like it should fail on contact with a volatile market but it does not. In every one of the 27,360 scenarios the pool stays solvent, and in all but a handful of late-launch runs it fills its $5m cap within days, and the rare moments when a winner cannot be paid resolve the same day.
What makes the design interesting is that losing early is rewarded, because the same loss mints $PAPER at the one-cent floor, and that token is a claim on every loss that comes after. The protocol turns its earliest and most loss-prone users into its equity holders. The people who fund the pool in its first weeks are the ones who own the largest and cheapest share of its future revenue. It is a recruitment mechanism wearing the clothes of a token, and the data shows it working.
A trader who understands this has a reason to show up first and lose on purpose, which is a strange sentence to write about a derivatives venue and the clearest sign the design is doing something new. Whether that claim actually pays, how the yield compares to the token's inflation, and when the flywheel holds or breaks, is what the follow-up measures. On the narrower question this piece set out to answer, the verdict is clean. The pool cannot be drained, it fills its cap within days, and it stays solvent under every configuration we tested.
The pool cannot be drained. Whether the token makes it worth filling is the next question.