There is no universal PKO bounty-to-chips conversion. Build a branch ledger instead: put complete continuation values—including every future prize and bounty path except the current immediate cash B and any explicitly isolated incremental progressive-transfer term H—in F, W, and L. For a closed heads-up decision with one win branch and a nonzero denominator, the algebraic break-even crossing is q* = (F − L) / (W + B + H − L).
In the constructed example below, F = 120, W = 165, L = 0, B = 50, and H = 0, all in the same synthetic value units. The exact threshold is 120 / 215 = 24 / 43 = 55.81%. Removing the immediate bounty gives 120 / 165 = 8 / 11 = 72.73%. That comparison shows how an input changes a model; it is not a recommendation to call with 55.81% card equity.
Disclosure: GTO Solutions AS publishes GTO Gecko and this article. The branch-value method, inputs, chart, calculator, and verification bundle were created for this article. They are an off-table planning model, not financial advice, tournament advice, or a PKO solver. The worked numbers are synthetic and do not represent a customer, operator, hand history, or product output.
Before using the calculator
- Read the event rules. The bounty split, side-pot award, rounding, and winner treatment can differ by operator and event.
- Choose the same declared value unit for every branch. Do not add cash dollars to raw tournament chips.
- List every material branch. Multiway pots, ties, side pots, and survival-with-chips outcomes need more than one win/lose percentage.
- Keep
Hvisible. It is the optional incremental effect of the current progressive transfer excluded fromW, not cash already received or a catch-all for later bounties.
Separate Three Kinds of Value Before You Count a Bounty
A PKO decision can move three different ledgers. Collapsing them into “pot plus bounty” hides the largest assumptions.
- Complete continuation value.
F,W, andLmodel the whole future path after folding, winning, or losing: ordinary prizes, the existing bounty path, and later knockout opportunities. They exclude only the current immediate cashBand an incremental progressive-transfer effect deliberately isolated inH. A declared ICM calculation can supply the ordinary-prize component; our ICM guide supplies the background. Gilbert's primary paper, The Independent Chip Model and Risk Aversion, formalizes ICM as a model for expected value in poker tournaments and demonstrates why even a fair chip bet can change that modeled value. - Immediate bounty cash.
Bis cash the operator actually pays you in the modeled branch. It belongs only in branches where you both eliminate an eligible player and receive that bounty under the event's rules. - Isolated progressive-transfer effect.
His an optional estimate of the incremental effect of the amount newly added to your own bounty. It is not the displayed addition itself or a container for future bounty value omitted fromF,W, orL. If the continuation values already include this incremental transfer, setH = 0.
This is a measurement rule as much as a formula. If F, W, and L are in dollars of modeled continuation value, then B and H must also be in dollars. If they are normalized units, everything must use that normalization. A chip-to-cash shortcut that ignores stack distribution, payouts, and bounty paths does not make unlike units comparable.
The distinction matches one documented operator implementation. PokerStars' current knockout help page, accessed September 4, 2026, says that in its described PKO structure an eliminator receives 50% of the opponent's bounty as cash and the remaining 50% is added to the eliminator's bounty. Its broader tournament-types page, accessed the same day, calls those percentages typical and tells players to check the lobby for exceptions. In that described structure, eliminating a player shown with a $100 bounty can make B = $50; it does not make H = $50 automatically.
This page handles the pre-elimination PKO decision. If a mystery-bounty token has already been earned, our mystery-bounty timing study owns the separate question of drawing now or waiting under a stated finite-pool mechanism.
The Two-Branch Threshold
For the narrow case with exactly two mutually exclusive outcomes—win the relevant pot and receive its bounty, or lose—define:
q: probability of the modeled win-and-eliminate branch;F: complete continuation value after folding, including all later prize and bounty paths;W: complete post-decision continuation value after winning, including all later prize and bounty paths and already net of the decision cost, but excluding currentBand any incremental transfer isolated inH;L: complete post-decision continuation value after losing, including every future path that remains and already net of the decision cost, but excluding currentBand any isolatedH;B: immediate cash bounty in the win-and-eliminate branch;H: optional incremental effect of the current progressive transfer, used only when that effect is excluded fromW.
The two alternatives are:
EV(fold) = F
EV(play) = q(W + B + H) + (1 − q)L
Set them equal and solve for q:
q* = (F − L) / (W + B + H − L)
Let D = W + B + H − L. The equality q* = (F − L) / D is defined when D ≠ 0. In the usual case D > 0, play has at least as much modeled value as folding when q ≥ q*; if D < 0, the inequality reverses to q ≤ q*. If D = 0, probability drops out: compare L with F, with every q tying only when they are equal. A crossing below 0 or above 1 is outside the feasible probability interval; report the resulting dominance or review the inputs instead of clamping it into a normal poker threshold. The two stated branches must still exhaust the outcomes.
W and L are complete values of the states reached after choosing to play. Do not subtract the call, add the pot, or credit the won chips again if the continuation model already priced that state. Doing so would count the wager or award twice.
In a truly closed, heads-up all-in where a clean win always eliminates the covered opponent, q may be derived from showdown equity after treating ties explicitly. In most other spots, it is a branch probability, not a hand-equity label. Fold equity, a surviving opponent, or a side pot can each create more branches.
Worked Example: Immediate Bounty Worth 50 Units
Consider a synthetic, heads-up, closed-action comparison. A separate tournament model has already converted every complete continuation outcome—including any existing-bounty and later-knockout paths—into the same value unit:
| Input | Value | Included | Excluded |
|---|---|---|---|
F | 120 | Complete future path after fold | Current B and isolated H |
W | 165 | Complete future path after win | Current B and isolated H |
L | 0 | Complete future path after loss | Current B and isolated H |
B | 50 | Cash paid now on elimination | Progressive transfer |
H | 0 | No transfer increment isolated from W | Displayed amount added to hero's bounty |
The fold branch is worth 120. The successful play branch is worth 165 + 50 + 0 = 215; the loss branch is worth zero. Therefore:
EV(play) = q × 215 + (1 − q) × 0
q* = 120 / 215 = 24 / 43 = 0.55813953… = 55.81%
At a hypothetical branch probability of 60%, the model gives EV(play) = 0.60 × 215 = 129, nine units above folding. Without the immediate bounty, the threshold would be 120 / 165 = 8 / 11 = 72.73%. Both statements are arithmetic conditional on the five inputs. Neither validates those inputs or says a 60%-equity hand should be played.
Use the offline-capable branch-value calculator to change the inputs. Start with a zero-isolated-transfer baseline at H = 0, then add clearly labeled negative or positive incremental cases only if you have a defensible model for the current transfer.
Why the Progressive Half Is Not $50 of Cash
Under the PokerStars example above, half of an eliminated player's bounty goes to the eliminator's account and half increases the bounty displayed on the eliminator. Those transfers have different owners and different timing. The first is immediate cash to you. The second makes you a larger target; whether any of it later becomes money for you depends on future tournament branches and the applicable winner, elimination, split, and cancellation rules.
For this reason, H should be only the incremental modeled effect of the new transfer not already captured in W, not the face amount transferred. A useful audit is to publish at least two runs:
- zero-isolated-transfer baseline: set
H = 0without calling it a lower or upper bound; - declared transfer-effect cases: supply model-derived negative and/or positive values of
Hand explain their horizon, tournament state, and treatment of the current added amount.
Zero is a baseline, not a bound or automatically a conservative estimate. A future-state model could assign positive value if the transfer may later return to you, or negative value if the larger target changes opponents' incentives in a way that reduces your modeled continuation value. The sign must come from the declared model rather than the word “bounty.”
Do not put the same progressive transfer into both W and H. F, W, and L must always include existing-bounty value and every later prize or knockout path. If W also includes the incremental effect of this new transfer, set H = 0; otherwise isolate only that increment in H. That is the model's main double-counting check.
Even the cash split is not universal. A published WSOP Circuit $400 Progressive Knockout structure sheet, accessed September 4, 2026, allocates $100 of the entry to non-value bounty chips, sends part of an eliminated bounty to cash, adds another part to the winner's bounty with $25 rounding, and states its own split-pot and final-winner treatment. That is evidence for that event's rules, not permission to transplant them into another lobby.
Build a Branch Ledger for Multiway and Side-Pot Hands
A single win percentage breaks down in multiway pots because “best hand,” “wins a pot,” and “earns a bounty” can describe different players. PokerStars' current tournament rules, accessed September 4, 2026, define the bounty's “relevant pot” as the pot in which the bounty player was all-in for their final chips. Their published example awards one short player's bounty to the main-and-side-pot winner and a different player's bounty to the winner of a later side pot; the best hand overall cannot collect a bounty from a player they did not cover. Identical winning hands split the relevant bounty under that ruleset.
Model that structure with a ledger instead of one enlarged pot. First construct the actual main and side pots, record who is eligible for each, and apply the operator's showdown and bounty-award order. Only then enumerate the settlements that can really occur; do not manufacture a Cartesian product of pot-result labels.
| Branch | Actual settlement and eligibility | Probability | Complete continuation value | Immediate bounties | Isolated transfer effect |
|---|---|---|---|---|---|
| Branch 1 | First distinct legal pot settlement and its bounty recipients | p₁ | T₁ | B₁ | H₁ |
| Branch 2 | Next distinct settlement after applying pot eligibility and showdown order | p₂ | T₂ | B₂ | H₂ |
| Branch 3 | Next distinct settlement, including survival or elimination and zero bounties where applicable | p₃ | T₃ | B₃ | H₃ |
| Branch 4 | Final distinct settlement needed to exhaust this hand's modeled outcomes | p₄ | T₄ | B₄ | H₄ |
Folding remains the separate comparator worth F. The four rows above are placeholders, not presumed combinations; add, split, or remove rows to match the legal settlements of the actual hand. Then calculate Σ pᵢ(Tᵢ + Bᵢ + Hᵢ) and verify that Σ pᵢ = 1. If a tie has nonzero probability, split the affected row into operator-specific tie sub-branches before summing; do not bury split and rounding rules inside an average bounty. The probabilities are joint outcome probabilities derived from actual pot eligibility and showdown order. They must respect card removal, ties, stack coverage, folds, and which side pots each player can win. Adding two heads-up equities will generally not produce them.
Freeze one accounting baseline across the ledger. Every Tᵢ must include the complete future path, including the existing bounty and later knockout opportunities. Hᵢ contains only the incremental effect of the new progressive transfer if that effect was deliberately excluded from Tᵢ; otherwise set Hᵢ = 0. Mixing those conventions across rows creates either an omission or double counting.
Also separate “wins the pot” from “eliminates the player.” If the target covers you, doubling through them does not earn their bounty. If a third player wins the target's relevant pot, you may win a side pot and still receive no bounty. The branch ledger makes those zeroes explicit.
How the Threshold Moves
Holding F = 120, W = 165, L = 0, and H = 0 fixed, the table varies only immediate bounty cash. This is a sensitivity study, not four estimates of one real hand.
Narrow screen? Scroll the chart horizontally to compare all four immediate-bounty cases.
B changed. The table is the complete text equivalent; the public bundle provides machine-readable reference data.Immediate bounty B | Win-branch value W + B + H | Exact expression | Required q* |
|---|---|---|---|
| 0 | 165 | 120 / 165 | 72.73% |
| 25 | 190 | 120 / 190 | 63.16% |
| 50 | 215 | 120 / 215 | 55.81% |
| 75 | 240 | 120 / 240 | 50.00% |
The curve falls because only the successful branch receives B. That monotonic result is conditional on every other input staying fixed. In a real tournament, a larger bounty can coincide with a different stack distribution, range, payout state, and chance of elimination. Recompute the full branch ledger instead of reading across this chart.
An Off-Table Study Workflow
- Record the operator and event. Save the lobby or structure sheet that defines the buy-in allocation, cash split, progressive transfer, side-pot award, split rounding, and final-winner rule.
- Draw the pots and stacks. Mark who covers whom and the relevant pot for each all-in player. Do not assign a bounty merely because your hand can beat theirs.
- Choose the common unit. Estimate complete continuation values
F,W, andL—including existing and later prize and bounty paths—in one documented value system. - Enter immediate cash only in
B. Apply it only to branches where the event rules award it to you. - Run
H = 0first. If you isolate an incremental effect of the current progressive transfer, publish that assumption separately and check thatWdoes not already include it. - Enumerate branches. Include folds, wins, losses, ties, distinct legal side-pot settlements, survival, and every distinct bounty award. Confirm probabilities sum to one.
- Stress the inputs. Vary
F, branch probabilities, andH; report whether the decision changes rather than presenting extra decimals as certainty.
The calculator supports the two-branch arithmetic. The CSV branch ledger is the starting point when the hand has more outcomes. Neither supplies ICM inputs, ranges, fold equity, or joint multiway probabilities for you.
Method, Downloads, and Independent Check
The public JavaScript generator freezes the five-input example, the four-row bounty sensitivity, the branch ledger, the chart, and the browser calculator. A separate Python standard-library verifier recomputes the equations and invariant checks without importing or invoking the JavaScript implementation. SHA-256 hashes cover the release artifacts.
Audit or reuse the complete bundle:
- Interactive two-branch calculator
- Method, data dictionary, reproduction commands, and limitations
- Machine-readable reference data (JSON) and frozen expected-check specification (JSON)
- Worked branch ledger (CSV) and immediate-bounty sensitivity (CSV)
- Primary JavaScript generator, independent Python verifier, and SHA-256 manifest
- Bundle-local chart copy (SVG) and bundle-local hero copy (WebP)
Save every linked file in one flat directory. From that directory, run node generate.mjs, then python verify.py. Exact rational checks back the displayed 24/43 and 8/11 results; rounded percentages never feed back into the computation. A successful verifier run confirms agreement between the two implementations and catches many arithmetic and serialization errors. The frozen expected-check specification is not an execution receipt, and neither it nor a successful run proves the input values, branch probabilities, or operator interpretation.
Where GTO Gecko Fits
Use GTO Gecko off-table to review a comparable available precomputed scenario, including the available actions, action frequencies, EV estimates, and range composition. The current US App Store listing, accessed September 4, 2026, supports that narrow educational workflow. Keep the bounty overlay in the separate worksheet above.
GTO Solutions AS publishes GTO Gecko and this article. The store listing describes GTO Gecko as educational study software with precomputed outputs and simulated scenarios. It does not claim that every arbitrary PKO node is available or that the app accepts this five-input model. It is not a PKO calculator. A non-bounty library spot can be a baseline only when its positions, stacks, pot, board, and action tree are actually comparable; it cannot silently supply B, H, operator rules, or tournament-equity inputs.
Limits of the Planning Model
- Inputs, not truth: the formula propagates
F,W,L,B,H, and branch probabilities. It does not estimate them. - Complete, common-unit values required: cash and tournament chips cannot be added directly, and
F,W, andLcannot omit existing-bounty or later-knockout paths. The article does not prescribe one ICM or tournament-value implementation. - Two-branch scope: the closed-form threshold assumes one successful bounty branch and one loss branch. Use the general ledger for folds, ties, side pots, several opponents, partial wins, and survival states.
- Progressive uncertainty:
His only the user-modeled incremental effect of the current transfer excluded fromW. Setting it equal to the displayed transfer is unsupported. - Operator dependence: PokerStars and the cited WSOP Circuit event are examples of their own published rules. Always use the current rules for the specific event.
- No strategy output: the model does not create ranges, solve an equilibrium, forecast a field, account for skill, or recommend a poker action.
- No outcome promise: expected value under a model is not a prediction of one hand, cash, tournament finish, or future result.
The useful habit is simple: one row per possible branch, one column per kind of value, and one declared unit. If the decision changes when H moves away from zero, the honest conclusion is that the isolated current-transfer assumption—not the displayed bounty—controls the answer.
Sources
- PokerStars, What are Knockout (KO) tournaments on PokerStars? Used for the operator's described PKO cash/progressive split and winner treatment; accessed September 4, 2026.
- PokerStars, Tournament Types. Used for the stated common PKO buy-in allocation, progressive mechanism, exceptions, and event-lobby warning; accessed September 4, 2026.
- PokerStars, Tournament Rules. Used for the relevant-pot, stack-coverage, side-pot, identical-hand split, and ICM-description claims; accessed September 4, 2026.
- WSOP Circuit, $400 Progressive Knockout structure sheet. Used only as an operator-specific example of allocation, rounding, split-pot, and final-winner rules; accessed September 4, 2026.
- George T. Gilbert, The Independent Chip Model and Risk Aversion, 2009. Used for the ICM expected-tournament-value framing and the warning that fair chip gambles need not preserve modeled prize-pool value; accessed September 4, 2026.
- GTO Gecko, public method, data dictionary, reproduction commands, and limitations, generated September 4, 2026, with an independent verifier readers can run locally.
- Apple App Store, GTO Gecko: Poker Study. Used for the bounded product-study description; accessed September 4, 2026.

