Compute · Assess & Decide · Analysis & Finance
Compute a liquidation-preference waterfall (multiple, participating vs non, cap)
You get each preferred investor's exit payout and the common-shareholder (founder and employee) residual for a given exit value, computed from each investor's invested amount, preference multiple, participating-or-not, participation cap, and as-converted ownership; payouts always sum exactly to the exit.
You receive: A reviewed liquidation-preference waterfall calculator (a pure function) plus its passing held-out test report, run on your exit value and your preferred stack.
Part of Pitch Investors
What's verified: STUD verifies the ARITHMETIC of a single-tier liquidation waterfall given the exit value and the preferred stack you supply, and grades the money that actually settles: each preferred holder's payout, the common (founder and employee) payout, and the total. It checks that each preference is invested times its multiple; that each holder ELECTS the option that maximizes its own payout (a non-participating holder stands on its preference or converts to common; a participating holder participates or reverts to conversion), decided against the RESIDUAL that remains after the other holders' preferences, not against the whole exit; that a participating holder's extra take is a pro-rata share of that residual; that a participation cap limits a participant, reverting it to conversion when conversion is higher and otherwise clamping it and redistributing the excess so nothing leaks (a cap below the guaranteed preference is treated as equal to the preference); that under a shortfall the proceeds flow to preference holders by seniority; and that every payout is non-negative and the payouts sum exactly to the exit. STUD does NOT verify that your invested amounts, multiples, ownership percentages, cap, or exit value are real, that a term sheet contains these terms, or that an exit at this value will happen. Honest limits: (a) it models ONE pari-passu class of preferred (equal rank except a seniority tiebreak under a shortfall), not multiple stacked seniority tiers each with its own sub-waterfall, accrued dividends, pay-to-play, or anti-dilution; (b) the intermediate residual and preferences-drawn figures are computed internally but are NOT graded (only the per-holder payouts, common payout, and total settle money).
Opens soon
This play is verified and ready. It opens soon, once sign-in and payments are live.
Example
A sample of what this play produces. Your result is generated for your inputs.
Payouts
Holders
Inputs
| Invested | Multiple | Participating | Cap Multiple | Equity Pct | Seniority |
|---|---|---|---|---|---|
| 1000000 | 1 | false | 0 | 0.12 | 1 |
| 3000000 | 1 | true | 3 | 0.2 | 2 |
Arithmetic recomputed against the tasks.py compute_liquidation_preference reference oracle, 2026-08-13. Elections settle residual-aware: holder 0 (1x non-participating on $1,000,000, 12 percent as-converted) converts to common because 12 percent of the $22,000,000 residual, $2,640,000, beats standing on its $1,000,000 preference; holder 1 (1x participating on $3,000,000, cap $9,000,000) draws its $3,000,000 preference plus 20 percent of the residual, $4,400,000, for $7,400,000 total, under its cap; common takes 68 percent of the residual, $14,960,000. 2,640,000 + 7,400,000 + 14,960,000 = 25,000,000, exactly the exit, with all five oracle invariants holding.
Get early access to STUD the day it goes live.