LAUNCHPAD.FAIL: A Verifiable State-Channel Protocol
for Interactive Token Allocation

1  Introduction

Token launches typically use passive distribution interfaces. Participants buy through liquidity pools, bonding curves, presales, launchpad allocation pages, or airdrop mechanisms. Such mechanisms distribute tokens and establish price discovery effectively, but the allocation process itself stays static: the participant contributes capital or qualifies for an allocation, and the system returns a deterministic or market-priced token amount.

LPF introduces a different primitive: interactive token allocation. Under LPF, the token acquisition becomes participation. A participant acquires or commits a token amount, enters a real-time launch round, and receives a final allocation determined by public game rules, cryptographic randomness, the participant's own decisions, and verifiable settlement.

The simplest LPF rule set is mathematically equivalent to the crash-game family: a multiplier increases over time, the participant may eject, and a terminal event decides whether the participant receives a multiplied allocation or loses the round. Crash-family games have well-studied expected-value properties; recent gaming research examines their history, theoretical values, player behavior, and return-to-player percentages, which gives this game family a useful mathematical reference point [1].

LPF does not attempt to hide this lineage. The protocol models negative expected value explicitly, through a configurable protocol edge. The contribution is not that the game becomes positive expected value. The contribution is that the rules, terminal randomness, participant timing, dispute path, and settlement accounting all become explicit and verifiable.

Most “provably fair” real-time games solve only one fairness problem: the terminal event is fixed before play. They do not fully solve the second problem, namely whether the server processed the participant's eject or continue action fairly. A server can commit honestly to a random crash point, and still ignore, delay, or reorder a participant's eject message. Besides this, a server that knows its own seed knows the crash point during play, which is a foreknowledge problem the naive commit–reveal does not address.

LPF addresses these gaps with a four-layer fairness construction:

1. Dual-entropy commit–reveal terminal events fix the terminal point before gameplay, and deny the server foreknowledge of it.
2. Participant-signed actions prove continue and eject decisions.
3. Server-signed state-channel checkpoints, bound to a committed schedule, prove the ordered game states shown to the participant and make stalls provable.
4. Onchain escrow with adjudicator authority makes the dispute outcome enforceable against real funds.

This places LPF between two extremes. Fully onchain gameplay is verifiable but too slow and too expensive for real-time multiplier play. Pure server gameplay is fast but trusted. LPF keeps the low-latency path offchain, and anchors disputes, custody, and settlement in signed evidence.

1.1  Contributions

1. A generalized model for real-time interactive token allocation, scoped to per-participant rounds.
2. A formal rule-set framework for launch allocation games.
3. A classical multiplier rule set with explicit expected-value analysis under a capped terminal distribution.
4. An arcade rocket rule set separating fairness-critical terminal events from offchain telemetry and seasonal scoring.
5. A dual-entropy commit–reveal construction for terminal-event fairness, with a VRF upgrade path.
6. A signed action model for participant intent.
7. A schedule-committed signed checkpoint state channel for eject/continue ordering and provable liveness.
8. An escrow and custody model placing round funds under adjudicator authority.
9. An onchain adjudication model with emergency eject, dispute timeout, and latest-valid-checkpoint rules.
10. A settlement model converting signed evidence into claimable or vested token allocations, with a reference deployment using FUEL.

2  Related Work and Background

2.1  Crash-family multiplier games

In a crash-style game, a multiplier increases over time until a terminal event occurs. A participant may exit before the terminal event to receive a multiplied payout; if the terminal event comes first, the payout follows a configured loss rule. Such games permit a clean expected-value expression. A participant selecting eject multiplier \(e\) wins with probability \(\Pr[C>e]\). If the terminal distribution is calibrated so that \(e\cdot\Pr[C>e]=1-h\), then the expected allocation equals \(b(1-h)\), where \(h\) is the protocol edge. In other words, strategy changes variance and user experience, not the long-run expected value under ideal calibration. Reference [1] studies the crash-game family in detail and provides the mathematical background that LPF generalizes.

2.2  Commit–reveal fairness

Commit–reveal schemes prove an outcome was fixed before it was revealed. The server commits \(c=H(s)\) before the round and later reveals \(s\); a verifier checks \(H(s)=c\) and recomputes the terminal event. This solves terminal-event manipulation after the fact, but two gaps remain: it does not solve participant-action ordering, and it does not stop the committing party from knowing the outcome during play. LPF closes both gaps (§12–§14).

2.3  State channels

State channels let parties perform most interactions offchain while keeping an onchain path for dispute resolution. Parties exchange signed states with increasing sequence numbers, and an onchain contract resolves disputes by accepting the most recent valid signed evidence [2, 3]. LPF applies this pattern to real-time allocation games: the WebSocket is only transport, and the fairness comes from the signed checkpoints and the onchain adjudicator.

3  System Model and Notation

Let \(P\) denote a participant and \(S\) the server/operator. Let \(T_i\) denote the project token distributed by launch \(i\); in the reference deployment \(T_i=F\), where \(F\) denotes FUEL. A participant enters a launch round with confirmed token amount \(b\). The round is governed by rule set \(g\) and rules version \(\rho\), and the final allocation is denoted \(A\).

3.1  Round scope: per-participant rounds

Per-participant scoping has one consequence worth stating early: terminal events across concurrent rounds are statistically independent, because each round derives from its own seed pair. Correlated protocol losses therefore arise only from correlated participant behavior, never from a shared crash point. The Red Paper relies on this property.

The high-level LPF transformation is

\[Q \rightarrow T_i \rightarrow b \rightarrow A.\]

A quote asset \(Q\) is converted into or mapped to the project token \(T_i\); the confirmed amount becomes \(b\); the launch-game rule set maps \(b\) and the participant actions into a final allocation \(A\).

4  Round Lifecycle

An LPF round proceeds through the following lifecycle. The normal path is offchain and low latency; the failure path is onchain and evidence-based.

1. Acquisition. The participant contributes quote asset \(Q\) or otherwise acquires \(T_i\).
2. Round basis. The confirmed token amount is recorded as \(b\).
3. Escrow. The amount \(b\) transfers into the round escrow account under adjudicator authority (§10).
4. Commitment. The server commits to seed \(c=H(s)\), together with the round parameters, the effective payout cap \(W_{\max,\mathrm{eff}}\), and the checkpoint schedule \(\Sigma\).
5. Channel open. The participant submits entropy \(s_P\) and both parties open a signed game channel for round \(r\).
6. Checkpoint loop. The server signs scheduled checkpoint states; the participant signs continue or eject responses.
7. Terminal resolution. The round ends through participant eject or terminal event.
8. Reveal. The server reveals seed \(s\).
9. Verification. A verifier recomputes the terminal event from \((s,s_P)\) and validates the signed transcript.
10. Settlement. The allocation \(A\) is credited from escrow and vault; the entry either returns inside the gross payout or routes to the loss destination (Pink Paper §5).
11. Claim or vesting. The allocation becomes claimable, vested, or locked according to configuration.

The round lifecycle is shared across rule sets. A rule set defines only the game-specific multiplier, terminal predicate, allocation function, and the replay evidence required for settlement.

5  Rule-Set Framework

LPF supports multiple launch-game rule sets, \(g\in\mathcal{G}\), each versioned by \(\rho\in\mathcal{R}\). Changing deterministic game math requires a new rules version; a settlement verifier must know both \(g\) and \(\rho\). Every rule set defines: (i) a state representation; (ii) a multiplier function; (iii) a terminal-event derivation; (iv) valid participant actions; (v) an allocation function; (vi) a replay artifact; (vii) an onchain-verifiable terminal predicate; (viii) a settlement verifier.

5.1  Rule-set inputs

A round is parameterized by \((b, r, g, \rho, c, W_{\max,\mathrm{eff}}, \Sigma)\): the confirmed amount, the round identifier, the rule set and version, the server's seed commitment, the effective payout cap, and the checkpoint schedule. The last two entries are new in v0.2, and both are binding: they enter the commitment and every signed state (§10.3, §14).

5.2  General allocation function

Let \(\omega\) denote randomness derived from the revealed seeds:

\[\omega = H(s, s_P, r, g, \rho).\]

Let \(a_P\) denote the participant's signed action sequence. The final allocation is \(A=\Phi_g(b,\omega,a_P)\). For multiplier-style rule sets it commonly takes the form

\[A=\begin{cases} \min(b\cdot M_g,\; W_{\max,\mathrm{eff}}), & \text{valid eject before terminal event},\\[2pt] 0, & \text{terminal event before eject}.\end{cases}\]

5.3  Onchain-verifiable terminal predicate

For strong dispute guarantees, each rule set must define an onchain-verifiable terminal predicate

\[\Psi_g(r,n,q_n,s,s_P,\rho)\rightarrow\{\texttt{alive},\texttt{terminal}\}.\]

The onchain adjudicator does not replay arbitrary offchain game logic; it verifies the compact predicate the rule set defines. A rule set is fully adjudicable if \(\Psi_g\) can be verified onchain within practical compute limits, and optimistically verifiable if it can only be audited offchain. LPF's core rule sets are fully adjudicable, because terminal validity reduces to simple threshold checks such as \(E<C\) or \(n_E<N^{*}\). This requirement is critical: if terminal failure depends on an expensive physics simulation or arbitrary offchain state, the strong emergency-exit guarantee does not automatically apply.

6  Rule Set I: Classical Multiplier Launch

The Classical Multiplier Launch rule set is the simplest one, mathematically equivalent to the crash-game family. The multiplier begins at \(1.00\times\), increases over time, and terminates at a committed terminal multiplier \(C\). The participant may eject at multiplier \(E\); ejecting before the terminal multiplier yields a multiplied allocation, otherwise the allocation is zero.

6.1  State machine

READY → COUNTDOWN → ACTIVE → { EJECTED | TERMINATED } → SETTLED

6.2  Multiplier function

The multiplier function \(M(t):\mathbb{R}_{\ge0}\rightarrow[1,M_{\max}]\) satisfies \(M(0)=1\) and monotonicity, \(M(t_2)\ge M(t_1)\) for \(t_2>t_1\), and it saturates at the rules-versioned cap \(M_{\max}\) (Appendix A). The exact curve is rules-versioned.

6.3  Terminal multiplier

The terminal multiplier derives from the committed dual entropy:

\[C=f\!\big(H(s,s_P,r,g,\rho)\big),\qquad C\in[1,M_{\max}].\]

The server commits to \(s\) before the round; the participant contributes \(s_P\) at channel open; the server reveals \(s\) after the round; the verifier recomputes \(C\). Section 12 gives the full construction and its foreknowledge analysis.

6.4  Eject rule

If the participant ejects at time \(t_E\), the accepted eject multiplier is \(E=M(t_E)\). The participant wins iff \(E<C\); the conservative boundary rule is \(E\ge C\Rightarrow A=0\).

6.5  Allocation function and payout convention

\[A(b,E,C)=\begin{cases}\min(bE,\;W_{\max,\mathrm{eff}}), & E<C,\\[2pt] 0, & E\ge C.\end{cases}\]

All payout-critical calculations use fixed-point arithmetic (Appendix B). Floating-point display values carry no settlement authority.

6.6  Adjudication predicate

Classical Multiplier Launch is fully adjudicable because the onchain predicate is cheap:

\[\Psi_{\text{classic}}(E,C)=\begin{cases}\texttt{alive}, & E<C,\\ \texttt{terminal}, & E\ge C.\end{cases}\]

The onchain program does not replay a game trace. It verifies the seed reveal, recomputes \(C\) from \((s,s_P)\), and compares \(E\) (or \(n_E\)) against the terminal threshold.

7  Rule Set II: Arcade Rocket Launch

Arcade Rocket Launch is a richer presentation and meta-game rule set, built on the same fairness-critical terminal primitive as the classical rule set. The important design separation is:

The enforceable terminal event is simple. The rocket telemetry is offchain.

The rocket may display altitude, acceleration, velocity, distance, travel time, and related telemetry. These values support visual feedback, daily missions, seasonal leaderboards, achievements, and changing game metas. They do not determine the explosion point in the fairness-critical path.

7.1  Arcade telemetry

Let arcade telemetry at checkpoint \(n\) be \(q_n=(z_n,v_n,d_n,a_n,\ell_n)\): altitude or progress, velocity, distance, acceleration, and auxiliary leaderboard or mission telemetry. Such values may be derived offchain from signed checkpoint data, runtime state, or deterministic display functions. They are not inputs to terminal-event adjudication. Formally, \(q_n\not\rightarrow C\).

7.2  Shared terminal primitive

Arcade Rocket uses the same terminal primitive: \(C=f(H(s,s_P,r,g,\rho))\), or equivalently a terminal checkpoint \(N^{*}=f(H(s,s_P,r,g,\rho))\). The participant ejects at checkpoint \(n_E\) or multiplier \(E\), and the enforceable check is \(E<C\) or \(n_E<N^{*}\). Therefore Arcade Rocket keeps the identical onchain dispute path while supporting richer offchain presentation.

7.3  Arcade allocation

\[A_g(b,n_E,C)=\begin{cases}\min\!\big(b\cdot M_g(n_E),\,W_{\max,\mathrm{eff}}\big), & n_E<N^{*},\\[2pt] 0, & n_E\ge N^{*}.\end{cases}\]

Telemetry may affect secondary scoring, missions, and seasonal rewards, but never the core terminal predicate, unless a future fully adjudicable rules version explicitly includes it.

7.4  Seasonal and meta metrics

Arcade telemetry supports non-settlement-critical systems: highest altitude, longest distance, longest travel time, acceleration achievements, mission completion, seasonal leaderboards, reward boosts. Such systems may produce additional rewards or ranking effects, but the fairness-critical base allocation remains determined by the signed checkpoint and terminal threshold. The clean boundary:

8  Expected Value and Protocol Edge

LPF makes expected value explicit. For the classical rule set, suppose a participant chooses eject multiplier \(e\). The participant wins when \(C>e\), so the expected allocation is \(\mathbb{E}[A_e]=b\cdot e\cdot\Pr[C>e]\) and the expected net return is \(\mathbb{E}[R_e]=b\cdot e\cdot\Pr[C>e]-b\). If the terminal distribution is calibrated with protocol edge \(h\), meaning \(e\cdot\Pr[C>e]=1-h\) on the supported range, then

\[\mathbb{E}[A_e]=b(1-h),\qquad \mathbb{E}[R_e]=-bh.\]

This is the basic LPF expected-value identity. The protocol does not claim participants have positive expected value; it makes the edge explicit and auditable. Under ideal calibration, different strategies alter variance, not the long-run expected value. Note the identity holds exactly only on the interior of the capped range \([1,M_{\max}]\); Appendix A treats the boundary, since without the cap the stated survival function is not a valid distribution at all.

For an arbitrary rule set \(g\), the expected allocation is \(\mathbb{E}[A_g]=\int_{\Omega}\Phi_g(b,\omega,a_P)\,d\Pr(\omega)\). A rule set must define its terminal distribution, allocation function, and verifier such that the expected value can be computed or bounded.

9  Token Acquisition and Allocation Basis

LPF separates token acquisition from allocation gameplay. A participant contributes quote asset \(Q\), such as SOL; the acquisition module outputs the project token \(T_i\); the confirmed output becomes the round basis, \(b=\Delta T_{\text{confirmed}}\). The launch round never uses a frontend estimate as \(b\) — only the confirmed output observed by the settlement system.

9.1  Pool-based acquisition

For a constant-product pool \(XY=k\) with quote reserve \(X\), token reserve \(Y\), fee factor \(\gamma\in(0,1]\), and effective input \(\Delta Q' = \gamma\,\Delta Q\), the token output is

\[\Delta T=\frac{Y\,\Delta Q'}{X+\Delta Q'},\qquad b=\Delta T.\]

9.2  Minimum output protection

A participant can enforce \(\Delta T\ge\Delta T_{\min}\). If the acquisition output falls below this minimum, the launch fails and the game does not start.

9.3  Reference deployment

In the FUEL reference deployment, \(T_i=F\): a participant contributes SOL, the launch pool outputs FUEL, and the confirmed FUEL amount becomes \(b\). The same protocol supports other compatible project tokens.

10  Escrow, Custody, and Payout Solvency

Version 0.1 left one question open, and it was the correct question to ask: where does \(b\) sit during a round? If the entry rests in a server database, the dispute path settles nothing, because winning the dispute yields only a claim against a party who already proved uncooperative. Version 0.2 closes this.

10.1  Round escrow

On a loss, the escrow routes to the configured loss destination (Pink Paper §5). On a win, the escrow returns inside the gross payout \(bE\), and the remainder \(b(E-1)\) draws from the settlement vault under the same adjudicator authority. Consequently, the emergency-eject path (§16) settles real funds: the participant's principal is already under adjudicator control, and the vault-side remainder is bounded by \(W_{\max,\mathrm{eff}}-b\).

10.2  Solvency gate on round admission

The settlement vault is replenished from the treasury through a rate-limited Solana subscription: a multisig-authorized pull allowance with a per-epoch drawdown cap (Red Paper §3.3, §10). Here we state the honest engineering position: such a rate limit does not change the long-run mathematics of whether the house goes bust; it stretches the random walk out over more time and buys reaction time for governance. What the rate limit does provide is an enforceable admission rule:

This rule is what makes the fairness guarantee non-hollow: every commitment the protocol signs is a commitment it can pay.

10.3  Cap binding

Because the Red Paper makes payout caps dynamic (they scale with reserves and liquidity), the cap in force must be fixed per round, not per epoch. The effective cap \(W_{\max,\mathrm{eff}}\) therefore enters the round commitment tuple \((r,g,\rho,c,b,T_i,W_{\max,\mathrm{eff}},\Sigma)\) and every server-signed \(\texttt{STATE}_n\) (§14). A participant always plays against a cap they can see and verify; the server cannot retroactively shrink a payout by pointing to a cap change mid-round.

11  The Fairness Problem

Interactive token allocation requires stronger fairness guarantees than passive swaps. A passive swap must execute at a fair or accepted price. An interactive allocation round must additionally prove: (1) the terminal event was fixed before play and unknown to the server during play; (2) the participant's eject or continue action was processed fairly; (3) the server did not advance the participant into additional risk without consent; (4) settlement used the correct signed evidence; (5) token accounting credited the correct amount, mint, and cap.

11.1  Terminal-event manipulation and foreknowledge

Without commitment, a server could choose the terminal event after observing participant behavior. Plain commit–reveal prevents the after-the-fact choice, but it does not remove foreknowledge: a server that generated \(s\) alone knows \(C\) throughout the round, and a server which also controls checkpoint timing can exploit that knowledge — for example by stalling checkpoints as \(M(t)\) approaches a \(C\) it already knows. Dual entropy (§12) removes the foreknowledge; the committed schedule (§14.4) removes the silent stall.

11.2  Eject-timing manipulation

A server can honestly commit the terminal event and still manipulate action ordering: ignoring an eject message, delaying acknowledgement, claiming the eject arrived after the terminal event, or advancing the game without participant consent.

11.3  Server liveness failure

A server can also fail or go dark mid-round. If the participant holds valid signed evidence of a safe checkpoint and an eject decision, the protocol must provide an exit path that needs no server at all.

11.4  Settlement manipulation

Settlement must not rely on unverifiable server logs or frontend display state. It must recompute the allocation from: the confirmed amount \(b\); the rule set \(g\) and version \(\rho\); the seed reveal or the timeout default; the signed checkpoint transcript; the participant action evidence; and the bound cap \(W_{\max,\mathrm{eff}}\).

LPF's goal is not to remove every liveness assumption from the normal UX. The goal is: if normal execution fails, the signed evidence can be adjudicated against escrowed funds.

12  Fairness Layer I: Dual-Entropy Commit–Reveal

The server samples a secret seed \(s\leftarrow\{0,1\}^{256}\) and commits \(c=H(s)\), bound to \((r,g,\rho,c,b,T_i,W_{\max,\mathrm{eff}},\Sigma)\). At channel open — strictly after \(c\) is fixed — the participant submits its own entropy \(s_P\leftarrow\{0,1\}^{256}\), signed under the round binding. The terminal event derives from both contributions:

\[\omega=H(s,s_P,r,g,\rho),\qquad C=f(\omega).\]

After the round the server reveals \(s\); the verifier checks \(H(s)=c\) and recomputes \(C\) from \((s,s_P)\).

12.1  What each party can and cannot do

The server committed \(c\) before it saw \(s_P\), so the server cannot choose \(s\) as a function of \(s_P\); and because \(C\) depends on \(s_P\), the server does not know \(C\) during play. The participant chose \(s_P\) after \(c\) was fixed, but the participant never learns \(s\) until the reveal, so \(s_P\) grinding gives the participant no advantage over uniform. Neither party alone controls or predicts \(C\), assuming \(H\) is binding and preimage resistant. This closes the foreknowledge gap of §11.1: a server that stalls near the crash point is stalling blind, and (§14.4) provably.

12.2  VRF upgrade path

A future rules version can replace the server seed entirely with a verifiable random function, using an oracle VRF such as Switchboard or Pyth on Solana. Under the VRF construction, \(\omega\) derives from a VRF output bound to \((r,g,\rho)\), the proof verifies onchain, and even the collusion of server and participant cannot bias \(C\). The dual-entropy construction of v0.2 is designed so that this substitution changes only the derivation of \(\omega\), and no other layer.

13  Fairness Layer II: Signed Participant Actions

At checkpoint \(n\), the participant signs one of two actions:

\[\sigma_P^{n}=\mathrm{Sign}_P(r,n,\texttt{CONTINUE})\quad\text{or}\quad \sigma_P^{n}=\mathrm{Sign}_P(r,n,\texttt{EJECT},E_n).\]

A signed action proves participant identity or delegated session identity, the round ID, the checkpoint nonce, the action type, replay protection, and domain separation. The participant should sign exactly one effective action per checkpoint; however, same-nonce conflicts can occur in failure scenarios — for example, the participant sends \(\texttt{CONTINUE}_n\), the server fails before issuing \(\texttt{STATE}_{n+1}\), and the participant later submits \(\texttt{EJECT}_n\) as emergency evidence. The rule:

This reflects the meaning of continue: the participant consented to advancement, but the next exposure is realized only when the server issues the next signed state.

14  Fairness Layer III: Scheduled Signed Checkpoint Channel

Gameplay occurs over a WebSocket, but the WebSocket is only transport. The fairness layer is a signed state channel. At checkpoint \(n\), the server signs the state

\[m_n=(r,n,g,\rho,q_n,M_n,c,W_{\max,\mathrm{eff}}),\qquad \sigma_S^{n}=\mathrm{Sign}_S(m_n).\]

Note the effective cap sits inside every signed state — the participant verifies at each step which cap governs the round. The participant verifies \(\sigma_S^{n}\) and responds with \(\sigma_P^{n}=\mathrm{Sign}_P(r,n,a_n)\), where \(a_n\in\{\texttt{CONTINUE},\texttt{EJECT}\}\).

14.1  Advancement invariant

14.2  Eject finality

If the participant signs eject at checkpoint \(n\), then \(A=A_n\) stands unless the server proves a valid prior terminal event. The server can refute an eject only with stronger valid evidence: a terminal event at or before checkpoint \(n\); a valid later state whose advancement chain includes participant-signed continue; or a complete settlement transcript proving the participant lost before eject.

14.3  Checkpoint interval

Let \(\Delta t\) denote the checkpoint interval; a reference deployment may use \(\Delta t=250\,\mathrm{ms}\). The frontend may animate smoothly between checkpoints — settlement uses signed checkpoints, never animation frames. Shorter intervals improve timing granularity but raise signing and message overhead; longer intervals do the opposite.

14.4  Committed schedule and provable stalls

New in v0.2: the server commits, inside the round anchor and inside \(\texttt{STATE}_0\), to the checkpoint schedule

\[\Sigma=(t_0,\Delta t, N_{\max},\varepsilon),\]

where \(t_0\) is the round start reference, \(N_{\max}\) the maximum checkpoint count implied by \(M_{\max}\), and \(\varepsilon\) the delivery tolerance. A checkpoint \(\texttt{STATE}_n\) is timely only if issued within \([t_0+n\Delta t,\; t_0+n\Delta t+\varepsilon]\).

15  Session Keys and Delegated Signing

Per-checkpoint wallet prompts are incompatible with real-time gameplay, so LPF uses scoped session keys. The participant's main wallet authorizes a session key for one narrow purpose: one round or bounded session; one participant wallet; one rule set and version; one token amount or maximum exposure; one expiration; continue/eject messages only; one signing domain. The session key signs the high-frequency channel messages \(\texttt{CONTINUE}_n\) and \(\texttt{EJECT}_n\); the main wallet signs the launch or session authorization; the onchain adjudicator accepts session-key evidence only within the delegated scope. This preserves the real-time UX and keeps the dispute path enforceable.

16  Onchain Adjudication and Emergency Eject

Each adjudicable round has an onchain anchor recording (or able to verify): round ID \(r\); participant authority or delegated session key; server signing key; token mint \(T_i\); escrowed amount \(b\); seed commitment \(c\); rule set \(g\) and version \(\rho\); the effective cap \(W_{\max,\mathrm{eff}}\); the schedule \(\Sigma\); the dispute timeout \(\tau\); the settlement status; and the escrow account address of §10.

16.1  Emergency eject

If the server fails or refuses to complete a round, the participant submits emergency eject evidence \((\texttt{STATE}_n,\sigma_S^{n},\texttt{EJECT}_n,\sigma_P^{n})\). The onchain program verifies: (1) the server signature on \(\texttt{STATE}_n\); (2) the participant or session signature on \(\texttt{EJECT}_n\); (3) round ID binding; (4) escrow and amount binding; (5) seed commitment binding; (6) rule-set, version, cap, and schedule binding; (7) checkpoint nonce validity and timeliness relative to \(\Sigma\); (8) session-key authorization where applicable. If valid, the emergency eject opens a dispute window of length \(\tau\).

16.2  Server refutation

During the dispute window, the server may refute only with stronger valid evidence: a revealed seed proving the terminal event occurred at or before checkpoint \(n\) (recomputed from \((s,s_P)\)); a validly advanced \(\texttt{STATE}_{n+1}\) backed by \(\texttt{CONTINUE}_n\); a later checkpoint whose entire advancement chain is valid and timely; or a full settlement transcript proving the participant had already lost. A bare \(\texttt{CONTINUE}_n\) is never enough.

16.3  Unrevealed seed default

16.4  Latest valid checkpoint rule

The adjudicator resolves disputes by selecting the latest valid checkpoint whose advancement chain is complete. A checkpoint \(n{+}1\) is valid only if \(\texttt{STATE}_{n+1}\) is server-signed and timely, \(\texttt{CONTINUE}_n\) is participant-signed, and all prior required advancements are valid. The practical invariant: latest valid checkpoint wins; later checkpoints count only if every advancement is backed by participant-signed continue. This prevents both parties from fabricating exposure after the fact.

16.5  Rule-set predicate

The adjudicator verifies the terminal predicate defined by \(g\) and \(\rho\): for Classical Multiplier, \(E_n<C\); for Arcade Rocket, \(n_E<N^{*}\) or \(E_n<C\). It does not replay arbitrary offchain telemetry. Rule sets requiring expensive replay must provide compact proofs or accept weaker adjudication guarantees (Appendix E).

17  Settlement and Claims

Settlement converts verified evidence into token allocation. It verifies: the escrowed amount \(b\); the mint \(T_i\); the commitment \(c\) and participant entropy \(s_P\); the revealed seed \(s\), unless the emergency timeout default applies; the rule set, version, cap, and schedule; the signed transcript; the participant action; the terminal predicate; and the allocation function. The allocation is \(A_P=\Phi_g(b,\omega,a_P)\) with \(\omega=H(s,s_P,r,g,\rho)\). Under the timeout default, the allocation computes from the accepted emergency eject checkpoint. Under the gross-payout convention (§6.5), settlement on a win pays \(A_P\) total, funded by escrow return plus vault remainder \(A_P-b\); settlement on a loss routes the escrow to the configured loss destination.

17.1  Allocation ledger

Settlement writes an append-only, audit-friendly ledger entry with: participant, token mint, round ID, rule set and version, amount \(A_P\), proof status (verified or adjudicated), and claim status (unclaimed, claimed, vested, locked).

17.2  Claims

The claimable balance updates as \(L_P\leftarrow L_P+A_P\); a claim transfers \(T_i\) to the participant wallet. Claims must be mint-bound, idempotent, replay-protected, and tied to verified ledger entries. A claim operation must not mix token mints.

17.3  Vesting and locks

An allocation may vest by function \(v(t)\): \(V_P(t)=A_P\cdot v(t)\), with claimable amount \(C_P(t)=V_P(t)-C_P^{\text{claimed}}\). Vesting and milestone systems are distribution-layer modules (Pink Paper §11–§12); they do not change the base fairness proof of the launch round.

18  Security Analysis

19  Limitations and Assumptions

LPF makes real-time token allocation verifiable, but it does not eliminate all assumptions.

1. Normal-path liveness depends on server responsiveness; if the server fails, the participant exits through the dispute path after the timeout \(\tau\), which is a delay, not a loss.
2. Checkpoint frequency limits timing precision; \(250\,\mathrm{ms}\) gives different granularity than \(100\,\mathrm{ms}\) or \(500\,\mathrm{ms}\).
3. Session keys require careful scoping by round, amount, rule set, expiry, and action type.
4. Rule sets must be adjudication-aware: complex offchain games need compact terminal predicates, or they accept weaker guarantees.
5. Liquidity affects acquisition: the participant receives the confirmed output, which depends on pool depth, fees, and slippage.
6. The expected value remains negative when \(h>0\); LPF makes the edge explicit, it does not remove it.
7. Settlement requires proof availability: signed transcripts, commitments, entropy values, and reveal data must remain available for verification or dispute.
8. Reward and vesting modules are separate distribution layers, and they must preserve the base settlement proof if they create additional claims.
9. Regulatory limitation. LPF stacks two regulated activities on top of each other. The allocation game is, in substance, a wagering mechanic with a house edge, which many jurisdictions regulate or prohibit as gambling regardless of the fairness proof; and the launched asset is a token issuance, which may be treated as a securities offering depending on its structure, marketing, and jurisdiction. The two classifications stack rather than substitute: a deployment can simultaneously face gaming law and securities law. Cryptographic verifiability does not create legal permission. Any deployment requires jurisdiction-specific legal analysis, and may require licensing, geofencing, participant eligibility controls, or abstention from particular markets. This paper specifies a protocol; it makes no claim of regulatory compliance anywhere.

These limitations are protocol boundaries, not contradictions. They define the conditions under which LPF's guarantees hold.

20  Reference Deployment: FUEL

The reference deployment uses FUEL: \(T_i=F\). Participants contribute SOL; the acquisition module outputs FUEL; the confirmed amount becomes \(b=\Delta F_{\text{confirmed}}\); the participant enters a round under either rule set; the final allocation is denominated in FUEL. FUEL may function as launch token, allocation token, claim token, reward token, and reference coordination token. The protocol is not limited to FUEL — any compatible project token \(T_i\) can use the same acquisition, rule-set, fairness, escrow, settlement, and claim architecture.

21  Comparative Analysis

LPF operates beside existing liquidity pools, bonding curves, and launchpad systems; its purpose is to add an interactive, verifiable allocation layer.

22  Conclusion

LPF demonstrates that token allocation can be interactive without becoming opaque. The protocol combines liquidity-coupled acquisition; rule-set-based allocation games; explicit expected-value modeling under a capped terminal distribution; dual-entropy commit–reveal fairness with a VRF upgrade path; signed participant actions; schedule-committed server checkpoints; onchain escrow under adjudicator authority; session-key real-time UX; emergency eject; timeout defaults that side with the participant; and verifiable settlement and claims bound to a per-round payout cap.

The classical multiplier rule set provides a mathematically simple game with known expected-value properties. The arcade rocket rule set extends the experience through offchain telemetry, visual progression, missions, and seasonal scoring, while preserving the same enforceable terminal-event primitive. FUEL is the reference deployment; the broader architecture generalizes to arbitrary compatible project tokens. The result is a launch protocol in which participants engage in real-time allocation games while retaining verifiable guarantees over randomness, timing, custody, settlement, and token accounting.

Appendix A: Classical Terminal Distribution with Multiplier Cap

Version 0.1 stated \(\Pr[C>e]=(1-h)/e\) without a cap. As written, that is not a valid distribution: the survival function exceeds 1 for \(e<1-h\), it never reaches 0, and \(\mathbb{E}[C]\) diverges. A valid classical rule set therefore requires a maximum multiplier \(M_{\max}\) and a defined boundary behavior.

The v0.2 reference construction is the truncated form:

\[\Pr[C>e]=\begin{cases}1, & e\le 1-h,\\[2pt] \dfrac{1-h}{e}, & 1-h<e<M_{\max},\\[2pt] 0, & e\ge M_{\max}.\end{cases}\]

Equivalently, \(C=\min\!\big(\tfrac{1-h}{1-u},\,M_{\max}\big)\) for \(u=\omega/2^{256}\in[0,1)\), which places a point mass \(\Pr[C=M_{\max}]=(1-h)/M_{\max}\) at the cap. On the interior \(e\in(1-h,M_{\max})\), the identity \(e\cdot\Pr[C>e]=1-h\) holds exactly, so \(\mathbb{E}[A_e]=b(1-h)\) and \(\mathbb{E}[R_e]=-bh\) as in §8. At \(e=M_{\max}\) no win is possible under the conservative boundary rule \(E\ge C\Rightarrow A=0\), so rational play stays interior; the effective payout cap \(W_{\max,\mathrm{eff}}\) may bind earlier than \(M_{\max}\) for large entries (§10.3), in which case the participant-facing maximum is \(\min(M_{\max}, W_{\max,\mathrm{eff}}/b)\).

The cap is not only a validity fix. It bounds per-round variance, \(\mathrm{Var}[A_e]\le b^2 M_{\max}^2\), and more tightly \(\mathrm{Var}[A_e]=b^2 e^2\,p_e(1-p_e)\) with \(p_e=(1-h)/e\); the Red Paper's ruin and reserve bounds consume exactly this cap. A rules version must publish \((h, M_{\max}, f)\) together — the three are one calibration, not three settings.

Appendix B: Fixed-Point Arithmetic

Settlement-critical multiplier calculations use fixed-point integers. Represent multiplier \(m\) as \(\hat m=\lfloor m\cdot 10^{d}\rfloor\) with fixed precision \(d\). With \(b\) in base units, the payout is

\[A=\Big\lfloor \frac{b\,\hat m}{10^{d}}\Big\rfloor,\]

followed by the cap, \(A\leftarrow\min(A, W_{\max,\mathrm{eff}})\), applied in base units. The rounding mode is rules-versioned; the runtime, the verifier, and the onchain adjudicator must use the same rounding rule.

Appendix C: Channel Message Schemas

All messages include a domain separator and a chain/program identifier to prevent cross-domain replay.

STATE_n    = (r, n, g, ρ, q_n, M_n, c, W_max,eff, σ_S^n)
OPEN       = (r, s_P, σ_P)  — participant entropy, after c is fixed
CONTINUE_n = (r, n, CONTINUE, σ_P^n)
EJECT_n    = (r, n, EJECT, E_n, σ_P^n)
REVEAL     = (r, s)
SETTLE     = (r, b, T_i, g, ρ, s, s_P, 𝒯, A)  — 𝒯 the signed transcript
DISPUTE    = (r, STATE_n, σ_S^n, EJECT_n, σ_P^n)

Appendix D: Example Round Transcript

1. Participant contributes SOL; acquisition outputs FUEL; confirmed amount becomes \(b\).
2. \(b\) transfers to the round escrow under adjudicator authority.
3. Server samples \(s\), commits \(c=H(s)\) with \((W_{\max,\mathrm{eff}},\Sigma)\).
4. Participant submits signed entropy \(s_P\); channel opens.
5. Server signs \(\texttt{STATE}_0\) (timely per \(\Sigma\)); participant signs \(\texttt{CONTINUE}_0\).
6. Server signs \(\texttt{STATE}_1\); participant signs \(\texttt{CONTINUE}_1\).
7. Server signs \(\texttt{STATE}_2\); participant signs \(\texttt{EJECT}_2\).
8. Server reveals \(s\); verifier recomputes \(C\) from \((s,s_P)\) and checks \(E_2<C\).
9. Settlement computes \(A=\min(bE_2,W_{\max,\mathrm{eff}})\); escrow returns inside the gross payout, vault pays \(A-b\); ledger credits claimable FUEL; participant claims.

If the server disappears after step 7, the participant submits \(\texttt{STATE}_2\) and \(\texttt{EJECT}_2\) to the adjudicator. Absent a valid refutation before \(\tau\), the emergency eject settles directly from escrow plus the adjudicator-accessible reserve. If instead the server simply stops issuing \(\texttt{STATE}_3\) while claiming the round continues, the schedule \(\Sigma\) makes the stall provable, and the same path applies.

Appendix E: Rule-Set Adjudicability

The reference Arcade Rocket rule set is fully adjudicable, because altitude, acceleration, velocity, distance, and travel time are telemetry and meta-game metrics, not inputs to the terminal predicate.

Appendix F: References

1. Scott III, R. H., Sher, M. M., et al. Cash or Crash: Return to Player Percentages and Expected Value of Crash Games. UNLV Gaming Research & Review Journal, Vol. 30, Issue 1, 2026.
2. Miller, A., et al. Sprites and State Channels: Payment Networks that Go Faster than Lightning. 2017/2019.
3. Negka, L. D., et al. Blockchain State Channels: A State of the Art. IEEE Access, 2021.
4. Ethereum.org. State Channels.