Plinko, priced: why the middle bucket pays ×0.2 and the edge pays ×1,000

A coin per row

Strip the pegs and the bouncing ball off a Plinko board and what remains is a coin. At each row the ball goes right or left; after n rows it has gone right some number of times between 0 and n, and that count is the bucket it lands in. Nothing about the physics changes the arithmetic — the animation exists to show you a path, and any path with the same number of right-bounces ends in the same bucket.

A count of fair coin flips has a name: it is binomially distributed. The probability of landing in bucket k on an n-row board is C(n, k) ÷ 2ⁿ — the number of paths with k rights divided by the number of paths altogether. That is the whole probability model of the game, and every number below follows from it.

Paths are binomial coefficients C(16, k). The multipliers are the engine’s 16-row tables, which are symmetric, so each row of this table covers a mirrored pair of buckets.

Every board returns about 99%

Multiply each bucket’s multiplier by its probability and add the products, and you have the expected return of a drop. Done for all 27 boards in the source file, the answer barely moves.

Odd row counts sit in the same band (98.9–99.2%). The exception is discussed below.

So the risk switch is not a price switch. Low, medium and high all give back about the same 99 cents on the dollar over many drops; what they change is where the missing cent is taken from. Low risk takes it as a ×0.5 centre bucket on an otherwise near-fair board. High risk takes it by paying ×0.2 on the five or six central buckets — which together catch four drops in five on a 16-row board — and spending what that saves on the edges.

Rows change the shape, not the price

Adding rows sharpens the binomial: the centre becomes relatively narrower and the edges become far rarer. On 8 rows the edge bucket is 1 in 256; on 16 it is 1 in 65,536, two hundred and fifty-six times rarer. The multiplier tables track that curve almost exactly — the high-risk edge goes from ×29 to ×1,000, a factor of 34, while its probability falls by 256, so the edge bucket is worth less per drop on a tall board than a short one, and the central buckets make up the difference.

• Short boards concentrate value in the edges. On 8 rows high risk, the two ×29 buckets alone contribute 22.7 points of the 99.06% return.
• Tall boards concentrate value in the shoulders. On 16 rows high risk, buckets 1 through 5 on each side — ×130 down to ×2 — carry most of the return; the two ×1,000 buckets contribute about 3 points between them.
• The centre is a tax on every board. At every row count and every risk setting, the most likely bucket pays below ×1. That is where the edge lives, and it is why a long session of Plinko feels like a slow leak punctuated by rare spikes.

This is the same lesson as the minefield’s one fraction and the keno risk dial: the operator publishes a table, the table implies a return, and every knob the player is given redistributes that return across outcomes without changing its total. A game that let the knob change the total would be one where a setting was simply better than the others; a well-built one makes every setting cost the same and lets the player choose the shape of the ride.

One cell that did not fit

Pricing every table by hand turned up one anomaly, and it was worth reporting rather than hiding. Twenty-six of the twenty-seven tables are left-right symmetric, as a fair coin demands. The 9-row high-risk table was not: it listed ×0.6 in the fourth bucket from the left and ×1.6 in the mirrored bucket on the right. Priced as printed, that board returned about 115% — a board that pays the player — which is not something any operator ships on purpose.

The same ×1.6 sat in the older pixi configuration the React table was copied from, so it was never a slip between the two client files; it was a cell both of them inherited. The file itself says which side wins a disagreement: the server pays what the server’s table says, and the client’s tables exist to draw the buckets. Whether the server’s cell read 0.6 or 1.6 was not visible from here, so this article asked the game team to check.

It read 1.6. The row had carried it since the payout table was first written, and the board really was returning 115.469% — the arithmetic above, not a client-side display quirk. The cell has since been corrected in both client tables, in the seeded schema, and in the databases the game reads on every drop, and a test now holds all twenty-seven boards to their own mirror symmetry and to the 99% band, so the same slip cannot come back unnoticed. Nothing had to be unwound: no drop had ever landed on 9-row high risk, which takes moving both the risk and the rows selector to reach. That is the argument for publishing tables at all — an error in a printed table can be found by a reader with a calculator, and an error in a hidden one cannot.

What the fairness ticket shows, and what it does not

Plinko here is one of the house games whose landing bucket is chosen on the server and returned with the bet, together with the seed-pair nonce the drop drew on; the client animates a path into that bucket. The seed panel shows the same committed server-seed hash and client seed as every other original, and the ticket for a round carries the nonce, so a drop can be tied to a specific committed pair and round number.

What this article can and cannot claim should be said exactly. The multiplier tables are read from the source and the bucket probabilities are arithmetic on a fair per-row coin, which is what the demo implements and what a Plinko board means. The server-side function that turns a seed pair and nonce into a bucket is not in the client repository, so the live draw is verified through the ticket and the committed seed rather than by reading its code here — the same boundary the verification walkthrough draws for the other house games. Everything priced above is a property of the published table; the ticket is where you check that a given drop honoured it.