Matka Prediction Algorithms: How They Work

A prediction algorithm is a function, and a function can be run on every input it will ever receive. That is the one thing a chart, a screenshot or a testimonial cannot be made to do, and it is the reason this page exists. Most writing about Matka prediction argues about whether the numbers are predictable. This page does something narrower and harder: it takes the algorithm that this site itself publishes - the three-day jodi recipe on our own free tips guide - executes it across all 1,000,000 inputs it can be handed, reads its output distribution, and then measures that output against the only bar that matters, which is the break-even hit rate implied by the payout list this product actually ships. Then it does the same for the machine-learning version of the claim, because "AI predictions" is a different architecture and deserves its own arithmetic rather than the same conclusion.

What "Prediction Algorithm" Has To Mean

The phrase is doing three different jobs in Matka writing, and mixing them up is how a page about algorithms ends up arguing with itself. Before any arithmetic, separate them.

The third row is the reason this page exists in this form. Almost every piece of writing in this genre, including the copy that sells prediction software, quietly borrows the authority of the third reading - the software does this - while making a claim of the first or second kind. The software here genuinely is an algorithm, in the strict sense: a finite sequence of rules that terminates with an answer. It just happens to be an algorithm that takes the result as an input and produces winners as an output. The direction of that data flow is not a stylistic detail. It is the entire difference between computing and predicting.

The Census: Where The Word Actually Lives Here

So let us start with the boring, decisive fact. Searching this product's Java sources for the stem predict returns 17 identifiers in 4 files, and all 17 sit on one code path.

There is no forecasting model, no feature store, no inference call, no scoring function and no table to write a prediction into. On the client side the vocabulary census is just as flat: the word forecast appears 33 times across 17 files, and every single one of those files is a blog post - prose in this repository, never code. The predict hits above are all admin-facing. So no part of this product, front or back, computes a number that a human then bets on. What it does have is an arithmetic rule published as marketing text on one of its own public guide pages - which is where the rest of this page gets its subject.

The Only Recipe This Site Publishes

Buried in the public routes of this product is a page whose URL is /guide/free-matka-tips-today. Its headline is not casual: it reads Satta Matka Probability Analysis: Understanding Open & Close Figures, and it contains a numbered procedure. Verbatim, the four steps are:

Three things are worth registering before we test any of it. First, the page is static. It is a Thymeleaf template, but the template carries no loop and no value binding anywhere in its article body - there is no th:each, no th:text. The digits 45, 12, 78, the sums 12 and 15 and the predictions 2 and 5 are literal characters in a file. The product does not compute them; nobody refreshes them; they were written once. So the "today" in the URL is doing no work at all, and the recipe is best read as a specification of a function rather than a daily tip.

Second, the recipe is entirely deterministic given its input, and its input is a six-digit string. That means it is a function from 1,000,000 possible worlds onto a pair of digits - a function small enough that we do not need to sample it, simulate it or trust anybody's chart of it. We can just run all of it. Section 3 does exactly that.

Third, the claim attached to it is a probability claim, twice: "high-probability" and "likely to appear". That is what makes this page honest rather than a complaint about marketing copy. A page that said "here is a nice pattern" would be unfalsifiable and uninteresting. A page that says likely has staked a number on the output distribution of a function, and a function's output distribution is a thing you can compute to the last digit. If it turns out to be flat, the word "likely" is simply wrong - our own word or anybody else's.

The Worked Example Reproduces

Before generalising, the arithmetic has to be understood correctly, so we reproduce the page's own example rather than assume it. From 45, 12, 78 the open digits are 4, 1, 7 and the close digits 5, 2, 8. Sum the opens: 12, whose unit digit is 2. Sum the closes: 15, whose unit digit is 5. Both printed values come back identical to the ones in the template, so the function we are about to test is the function the page describes - (d₁ + d₂ + d₃) mod 10 applied to three open digits and, independently, to three close digits. Its predicted jodi for the worked example is 25, and its two cut numbers are 7 and 0.

One detail of notation matters later. "Take the unit digit of the sum" and "reduce modulo 10" are the same operation, and it is the same operation the product uses to settle bets. In the result-declaration service the anna is computed as the digit sum of the declared panna modulo 10, and the bulk settlement statements match a single-digit bet against exactly that value. So this recipe is not some rival arithmetic bolted on beside the real game. It is the game's own annas function, fed with digits from three previous days instead of from the panna being declared. That is the most charitable framing available and it is worth holding: the recipe is native to the product's mathematics, and it still has no information in it.

Running It On Every Input It Will Ever Get

Here is the whole test in one sentence. There are 10⁶ possible six-digit inputs - every combination of three open digits and three close digits. Feed all of them to the recipe. Count how often it says 0, how often it says 1, and so on, for the open prediction, the close prediction and the pair.

Not approximately. The deviation is zero, and the enumeration is small enough that this is arithmetic rather than measurement: every one of the ten predicted-open cells contains precisely 100,000 of the million inputs, and all hundred predicted-jodi cells contain precisely 10,000. There is no digit the recipe favours, no digit it avoids, no clustering, no hot cell and no cold cell. If you ran this recipe for as long as the input space allowed and nothing else changed, its predictions would be distributed with the flatness of a perfect random number generator - and the flatness is exact, not statistical, because the underlying sum modulo 10 is a group homomorphism and every residue class has the same number of preimages.

Which is the moment to be very careful about what this does and does not prove, because the temptation to overclaim here is exactly the temptation that produces bad prediction software.

What This Does Not Say

It does not say the recipe is wrong. It says the recipe is uniform. Those are different statements with different consequences. A uniform predictor over a uniform source is as good as any other predictor and as bad as any other predictor: it hits the true anna one draw in ten, which is exactly what a coin would do. A uniform predictor over a biased source would be mediocre where a smarter rule would be good - it would spread its predictions evenly across ten targets while all the money sat in two of them. So the exhaustive enumeration establishes the recipe's shape. Whether the shape is enough is a question about the source, and whether the shape can be improved is the interesting engineering question. Section 5 answers it, and the answer is that this particular shape is actively destructive.

It also does not say the recipe can be narrowed. A commoner's objection to a critique like this is "well, the trick is it rules numbers out". It does not. All 100 jodis are reachable; all ten annas are reachable; the reachable set is the whole outcome space and the weights on it are equal. Nothing about applying it reduces the field you have to cover, which means the only way it can help you is by reweighting - and the enumeration above shows it does not reweight either.

The Cut Number Is A Rearrangement, Not A Reduction

The recipe's last move is the ±5 cut, and it is worth its own paragraph because it is the part that sounds like an insight. Adding 5 modulo 10 maps 0→5, 1→6, 2→7, 3→8, 4→9, 5→0, 6→1, 7→2, 8→3, 9→4. That is a permutation: ten distinct inputs, ten distinct outputs, and it is its own inverse - cutting twice returns you to where you started. So "add or subtract 5" cannot create a concentration of probability any more than re-labelling a die can make one of its faces heavier. It takes a uniform distribution and hands you the same uniform distribution wearing different shoes.

What it does change is coverage per rupee, which is a different question and the one you actually care about: buying both the prediction and its cut doubles your chance to 2 in 10 and doubles your stake, so the expected value per rupee is untouched. The full economics of a cut pair are worked through in the cut-ank analysis; here the point is only that the cut is a symmetry operation and the recipe's claim of "high-probability" cannot be smuggled in through it.

Why Sums Modulo Ten Cannot Concentrate Probability

The result above looks like an accident of the specific recipe - three digits, unit digit, mod 10. It is not an accident, and the general form is worth knowing, because it covers most of the digit-sum family: add the last two results, add four and take the last digit, add the day's panel and reduce. All of them are the same shape.

Take any distribution over digits that is exactly flat, and add two independent draws from it. For each target residue, the number of ordered pairs that land on it is ten - pick the first digit freely and the second is then determined. So the sum is flat again, over 100 inputs and 10 cells at 10 each. Now add a third: pick two digits freely, the third is forced, giving 100 preimages per cell, flat again. The pattern is total: for k summands there are 10^k inputs and 10^k−1 preimages per output cell, uniformly. Here is the convolution chain run explicitly.

There is no "sweet spot" number of summands at which the arithmetic starts to help. Adding more past results to a digit-sum formula does not add information; it adds terms to an operation that is exactly flat in every direction. This is why the digit-sum genre has survived a century of being right often enough to be remembered: it is correct about the mechanics of annas and silent about the fact that a correct mechanic with a uniform output has no edge in it. The companion piece to this series on guessing tricks classified the whole genre from the outside; this is what it looks like from the inside, computed.

The Recipe Cubes Whatever Bias It Inherits

Now the genuinely technical part, and the reason a page titled "how they work" should not stop at "it is uniform". Suppose the source is not uniform. Suppose a real, structural bias exists in the annas being generated - a hot digit that comes up 12% of the time instead of 10%. That is already a large bias: it is the kind of thing a serious investigation would consider a defect. Feed a source like that into the published recipe and watch what the recipe does to it.

The bias did not disappear - it was cubed. A 2-percentage-point structural advantage leaves the recipe holding 0.000988 of a percentage point, attenuated by a factor of 2,025. And this is not a quirk of the particular hot-digit distribution: the exact statement is that the m-th harmonic of a threefold sum is the cube of the m-th harmonic of the summand. Verifying that directly: the first harmonic of the source distribution has amplitude 2.2222 × 10⁻², and after three summands it is 1.0974 × 10⁻⁵, which is the original cubed to four decimal places - a ratio of 1.0000. Since every harmonic of a probability distribution has amplitude at most 1, raising it to the third power shrinks it. Summing two digits squares the signal; summing three cubes it; a formula that sums k past digits keeps the k-th power, which tends to nothing.

The consequence is a hard constraint on the entire genre, and it runs opposite to how these recipes are advertised. Digit-sum formulas are marketed as ways of finding structure. In information terms they are signal destroyers: whatever structure exists in the digits, an k-fold sum reduces its measurable amplitude to its k-th power. If you wanted to detect the residual 0.000988 pp the recipe is holding, and you had a 2-sigma test, you would need 3,690,562,500 draws. A single market produces 626 digits a year and 6,262 in a decade. So the recipe does not merely fail to create bias; it takes the bias that would have been detectable in 626 observations and buries it under a number no one can collect in a century.

Which is also the honest answer to a question the software vendor never asks you: if there were a predictable pattern in the results, how would you get at it? Not by summing. Summing is the least informative function of the digits that still looks like arithmetic. You would need to estimate the joint distribution directly, which is the machine-learning problem - and that is a genuinely different algorithm, so it gets its own section rather than the verdict above.

The Bar Every Prediction Has To Clear

Everything above is about the shape of an algorithm's output. None of it is about money. The money question is the one that decides whether a prediction is worth buying, and it has a single number for answer: the break-even hit rate, which is one divided by the payout multiplier. Bet at rate r and you need to win one time in r to hand back exactly what you staked. Anything below that is a loss with a nice story attached.

This product's shipped rate list is not a rumour or a screenshot: it is a static immutable map in the payout configuration, backed by per-client keys seeded into the first client-config migration, and both sources agree on all seven bet types. Those values - 9.5, 95, 140, 280, 700, 1,000 and 10,000 - turn into the bar below. Win probabilities use the game's own outcome spaces: ten annas, one hundred jodis, and panna classes taken from the 220-class census (120 single classes covering 6 orderings each, 90 double covering 3, 10 triple covering 1, out of 1,000 ordered triples).

Read the last two columns together and the whole genre of prediction software changes appearance. The edge ladder runs 5% → 5% → 16% → 16% → 30% → 40% → 64%, and it climbs almost monotonically with the size of the payout. The rates people chase are the rates the arithmetic punishes hardest. An algorithm advertised for the ₹10,000 full-sangam number is not being asked to be clever; it is being asked to be 2.78 times better than chance before it is merely worth buying. Meanwhile the humble single digit, the one every "tip" page is actually about, needs only a 5.26% relative improvement - the smallest ask on the list, and still more than the published recipe delivers, which delivers zero.

The same relationship, stated as a pricing shortfall rather than an edge, is the clearest way to see it.

Two caveats so this table is used rather than worshipped. The rates are configuration, not constants: a client's keys can differ from the seeded defaults, and the multipliers are hidden from the player-facing config endpoint in one of the product's modes, so the numbers you are offered may not be these. Recompute the break-even column for the list you are actually shown - it is one division per row. The win chances are one convention rather than the only one: the five panna and sangam rows price each leg as a class of orderings, so a booked 123 wins on a draw of 132. That denominator question is argued in the panna payout-rates guide and the sangam strategy guide, and the alternative moves more than a decimal. Read the legs positionally, which is how this platform's own settlement compares them, and the return per ₹1 falls to ₹0.14 on a single panna, ₹0.28 on a double, ₹0.70 on a triple, ₹0.10 on a half sangam and ₹0.01 on a full - house edges of 86.00%, 72.00%, 30.00%, 90.00% and 99.00%. Only the first two rows of the ladder are convention-free; the bottom five get worse under the other reading and never better, and both readings leave the two sangams the worst-priced bets on the card.

What does affect everything is that the break-even numbers are tiny margins expressed against rates nobody quotes. The single digit needs 10.5263%, not "about 11%". The gap between chance and break-even is half a percentage point. That gap is the entire target an algorithm must hit, and half a point on a ten-way target is not a design problem - it is a measurement problem, which is why the next section is about sample sizes rather than cleverness.

How Many Bets A Real Edge Actually Needs

Suppose an algorithm is genuinely better than chance. Suppose, in fact, that it is exactly good enough to clear break-even - the most profitable case a vendor could honestly promise. To know it has cleared break-even you must distinguish its true hit rate from the flat one, and that distance is fixed by the noise of the count. Using the standard two-sigma detection size, n = 4p(1−p)/δ², with δ being the gap between the uniform chance and the break-even rate from the table above:

Two numbers to keep. 12,997 single-digit bets - about nine months of every session across the full 25-market MAIN catalogue - is the least evidence that will let you say, at conventional confidence, "this algorithm is above break-even on the cheapest bet". And 142,957 settled jodis, which at 25 a day is 15.67 years, or 30.13 years if you only count the 13 hourly Starline slots. The jodi is the bet every tip page talks about and the one the arithmetic makes impossible to validate inside a human betting lifetime.

Now put that beside what the history in this database can supply. A companion audit in this series found the chart table's retention row set to 180 days, leaving 181 dates, and the settlement predicate restricting deletable rows to fully-declared days - so the whole catalogue holds 25 × 181 = 4,525 settled jodis. That is 3.17% of the 142,957 a just-beats-break-even jodi algorithm would need to be proven at all. The missing evidence is not a modest gap that a longer archive would close; it is 138,432 bets, 15.17 years of draws, and the product deletes its way toward the answer at a fixed rate every morning. The relationship between these two pages is not rhetorical. The prediction question is unanswerable in exactly the same machinery that makes the decade question unanswerable.

The Budget You Actually Have

Flip the calculation, because that is the form that helps a reader. Nobody places 13,000 bets; people place a few hundred and decide. Here is the smallest real advantage a given budget can even see, on the single digit where the space is widest:

Every budget short of thirteen thousand is blind to the only margin that matters. That does not mean nothing at those budgets is provable - a genuinely extraordinary algorithm, one that hits 18% rather than 10.5%, shouts at 50 bets. It means that a merely-profitable algorithm is indistinguishable from a coin for as long as a punter is likely to keep count. This is why "I have been using it for three months and I am up" is not a weak argument but a structurally unusable one, and it is the same arithmetic, in the other direction, that the missing-dates analysis applies to frequency tables.

What A Learned Model - Or An AI - Would Face

Machine learning is a different architecture from a digit-sum recipe and it deserves the distinction rather than the same dismissal. A recipe hard-codes an operation; a learner estimates one from data. It can in principle discover that digit 0 comes up 12% of the time and simply always answer 0 - something no summing formula can do, since summing was shown above to destroy exactly that signal. So the honest question is not "can a model be smarter than the recipe" (yes, structurally) but "what is the ceiling on what a model can learn here", which turns out to be three separate walls.

The middle wall is the one that produces vendor screenshots, and it is worth dwelling on because it is not a lie told by a dishonest person so much as a property of fitting. Any model with enough freedom, given a few hundred past results, will find a digit that appeared more often than others and will happily report that it predicted it. The in-sample accuracy of a fitted model is a measurement of the model's flexibility, not of the source's predictability - which is the whole content of the phrase "overfitting", and is why the only number in this section that means anything is 10.5263% measured forward on bets you have not yet made. The first wall is the deepest: it says that if the digits are fair, there is no model to find, and no amount of compute changes that, because the optimal strategy on a flat source is already known and already loses. The third is a practical dead end that saves you the trouble of hoping - a learner asked to map six input digits to two output digits has a million inputs and will be shown a few thousand.

What "AI Predictions" Would Have To Add

Precisely one thing: a hit rate above the break-even row of the rate table, sustained, on data the model did not train on, at a sample size where the margin is visible. Not a confidence score, not a percentage of "accuracy" quoted from a backtest, not a chat interface, not a model architecture. The word "AI" changes nothing about the bar and nothing about the required sample; it only changes who is blamed when the number fails to appear. The closely related question - what a claim of 90% accuracy would have to show before it could be taken at all - is answered on its own page in this series and is not repeated here.

And if a reader wants the charitable engineering position, it is this: the only place a learned model can beat chance in a game like this is if the source is not uniform, and the only way to know whether a source is uniform is a frequency test at a sample size that can see the bias it is claiming - which is the test the chart-software audit hands you, and which lands, for any real Matka archive, on the retention problem rather than the modelling problem.

What Noise Hands You For Free

A prediction that is exactly as good as chance still looks like a system, and this section quantifies how good it can look for nothing. Run the published recipe across the product's own daily draw count: 25 MAIN markets, open and close each, is 50 sessions a day. At a uniform 10% hit rate the expected daily count of correct predictions is 5, and the standard deviation is 2.1213.

A day in which the recipe appears to predict 20% of the country's Matka results correctly happens roughly nine times a year for free, and its two-sigma band - 0.76 to 9.24 hits, so anywhere between 1 and 10 in practice - is wide enough that a competent-looking day and a genuinely ordinary day are the same event viewed from a screenshot. The exact number that makes this persuasive to a reader is the streak table, because streaks, not averages, are what get posted.

Somewhere in this catalogue, a three-day perfect run by an algorithm with no ability whatsoever is expected roughly nine times a year, and the chance that at least one market produces one in a given year is 30.45% per market and 99.99% across all 25. The four-in-a-row that gets shared in a WhatsApp group happens about once a year by pure noise. Nobody is lying when they post it; they are just holding the surviving tail of a distribution that produced nine identical-looking failures beside it. This is the same phenomenon the series has called the multiple-comparisons problem elsewhere, at the level of a person rather than a database.

A Profitable Year And A Losing Mean, At Once

The last piece of the noise picture is the one that converts a reader into a customer, so it is worth computing rather than asserting. Take a punter betting ₹100 on the recipe's open prediction once a day for 365 days at a genuine 10% hit rate and the shipped 9.5 rate. The year's hit count is a binomial on 365 trials, so the year-end result is not a matter of sampling: the mean is exactly −₹1,825 - five percent of the ₹36,500 staked - the spread around it is ₹5,445, and any year reaching 39 hits finishes ahead. Summing that distribution says 35.60% of such years end in profit. Run the identical arithmetic on a daily ₹100 jodi bet at 95, where four hits in the year clear the stake, and the mean is the same −₹1,825 with a spread of ₹18,059, while 49.61% of years finish positive. A seeded Monte Carlo of 200,000 simulated punter-years reproduces both shares to within its own error bars (35.72% and 49.90%, against ±0.22 points), which is the check that the closed form is being applied correctly - not the source of the number.

Half of all jodi punters following a worthless recipe end the year ahead, and the average one loses. Both statements are true simultaneously because a 95-times payout makes the outcome lumpy: the distribution's median is a loss and its profitable half is real. So a testimonial is not evidence of anything unless it names the mean, the count and the period - and it is precisely this asymmetry that the bankroll and risk-management guides in this series exist to defend against, because a punter in the profitable half of that distribution has no way from the inside to know they are in it by luck.

The Three Algorithms That Actually Run

Having spent this page on what does not exist, it is only fair to describe what does. This product contains three pieces of genuine, executable, deterministic logic that touch result numbers. All three are worth understanding because they are the source of the borrowed authority mentioned at the top: they are real algorithms, they are in the software, and none of them predicts.

1. Settlement: A Predicate, Not A Forecast

When a result is declared, bets are settled by bulk update statements whose entire content is a comparison. The three that matter are on the digits the user booked:

Every one of these statements is gated on b.status = 'ACCEPTED' - seven such predicates in the repository - so nothing unsettled is touched and nothing already settled is revised. The annas computation itself, digit sum modulo ten, appears six times in the result service - three of those sites reading their digits off the open result and three off the close or the declared panna. This is where the recipe in our own guide got its arithmetic, and notice what the code needs in order to run: the declared digits. Not the previous three days' digits. The current ones. A settlement engine is a lookup table with a WHERE clause; it is fast, correct and utterly non-anticipating.

2. The Admin What-If, Which Is The Only Thing Named "Prediction"

The one endpoint in this codebase whose name promises a prediction is GET /api/admin/bets/predict-winners, behind a hard admin-role check, backed by an admin-only screen. It accepts a date, a market, a session and a hypothetical open and close panna. Read what it does with them: it recomputes each digit sum modulo 10 with the same function settlement uses, then walks the accepted bets and multiplies the ones that match by the rates from the same configuration.

So the "prediction" is a what-if replay. If tonight's panna is 413, these are the accounts that will be paid and this is the exposure. It is an excellent tool and it is used for risk management by the person running the book - which is to say it predicts the payout, conditional on a stated result, and never the result. It runs the settlement arithmetic forward from an assumption instead of backward from a fact. That is the most sophisticated thing in the product with the word "prediction" on it, and it is exactly the tool a genuine forecaster would need to be given the answer first. The endpoint takes the future as a parameter.

3. The Poller That Refuses To Invent A Digit

The third piece of logic is the only place outside numbers enter the system at all. A scheduled job calls an external results API every 60,000 milliseconds, with a 15-second initial delay, and it is wrapped in guards that matter for the argument: it first checks a master switch, and that switch is a configuration row whose value this product's own migration seeds as 'false' - so on a fresh install, the automatic path is off and results are entered by a human. Per-market the column defaults to enabled, but it can only act on markets flagged as API markets, and the job skips any market without that flag. It then rejects empty responses, and its validator accepts a panna only if the response actually carried three digits - there is no code path in that job that contains a random number generator, a fallback digit, a "guess from history" branch or a default value standing in for a missing result. Where the external API returns nothing, the job logs it and leaves the day undeclared.

That last property is the closest this product comes to a philosophy about numbers, and it is worth stating plainly because it is the opposite of what prediction software does: a result that has not happened is recorded as not having happened. The system would rather display a gap than manufacture an answer. Any tool that offers you a digit before the draw has, by this product's own design standard, done something the software is written not to do.

Where A Forecast Would Have To Live, And Doesn't

There is a structural way to see whether a system contains prediction: ask what it would have to store. A real prediction service keeps, at minimum, the forecast itself, the moment it was issued, and the outcome it is scored against, so that its accuracy can be computed later. Ninety migrations define this product's schema, and zero of them contain a column, table or index for a forecast. The bet entity has no field for what the player expected; it has digits, an amount, a status, a settlement outcome and a win amount - all written after money moved.

That absence has a practical consequence for anyone being sold prediction software through a betting platform. If a product genuinely produced daily predictions, it would be trivial to log them, and the log would make every claim in this genre checkable: publish the issued forecasts, timestamp them, leave the results untouched, and let the accuracy be computed by the customers rather than by the vendor. Nobody has to trust a screenshot. The technical reason tip archives never do this is not secrecy - it is that a logged forecast is a falsifiable record, and the arithmetic above says that once it exists, the mean lands near 10.5263% or below. The absence of a predictions table in a product that keeps audit logs, deletion logs and idempotency snapshots for money is not an oversight; it is the tell.

What The Database Does Keep

For completeness, the columns of result-bearing storage: market days with open and close results, a seven-state result status where only one state is eligible for deletion, a payout configuration keyed per client, a cleanup table with retention rows, and the bet rows themselves with outcome and win amount. There is a genuinely useful thing to do with all that, which is not prediction at all but the measurement of the source - the frequency census, the missing-date audit and the completeness checks the other guides in this series cover. Reading your own history honestly is a smaller promise than forecasting it, and it is the only one this schema can actually service.

What The Stake Ceilings Already Admit

One more piece of evidence, and it comes from the product's own risk configuration rather than from probability. The Starline payout table is not only a list of multipliers; every bet type carries a min_bet_amount and a max_bet_amount, seeded by migration, and the ceilings are ordered in a very specific way.

The ceilings run ₹50,000 → ₹10,000 → ₹5,000 → ₹2,000 while the edge climbs 5% → 16% → 16% → 30%. They are inversely ordered with the house edge. The operator lets you put five times more money on the 5%-edge bet than on the 16% one and twenty-five times more than on the 30% one, and the minimum stake is ₹10 on every row. That is what a risk-reasoned rate card looks like: the expected loss at the cap is held in a narrow band - ₹2,500, ₹1,600, ₹800, ₹600 - rather than being allowed to grow with the payout. Read plainly, the configuration agrees with the arithmetic of this page, and agrees with it harder than most prediction marketing does: the high-multiplier bets are the ones worth limiting.

The MAIN catalogue, by contrast, applies one flat limit of ₹10,000 to every game type - it is a single global betting maximum, not a per-type ceiling, and it is the same ₹10,000 that the bet service falls back to when no configuration is present. Under that flat cap the expected loss at the ceiling runs ₹500 on a single digit, ₹1,600 on a panna, ₹3,000 on a triple panna, ₹4,000 on a half sangam and ₹6,400 on the full sangam. Two different risk philosophies in one product, and the per-type one is the honest statement of which bets a rational operator thinks are worse. For a punter, the practical reading is that the stake ceilings are the only place this genre's math appears as a policy you can inspect - so inspect them, and be suspicious of any "algorithm" whose recommended bet sits under the tightest ceiling in the table.

A Test Any Prediction Algorithm Must Pass

Everything above compresses into six checks. They are ordered so that the cheap ones kill the claim first; most claims die at the second, and none of them needs access to anybody's source code except the last.

Two notes on using this. Check 2 is the one that costs nothing and refutes almost everything, and this page has now run it against our own published recipe: the histogram is flat to the last input, so no version of that rule clears step 3. Check 4 is the one that protects you from a truthful vendor - someone who really did hit 13% over 400 bets, reported it honestly, and is nevertheless selling you noise, because 400 bets cannot see a 2-point margin. And check 5 has a variant that is worth asking any app: if it shows you today's numbers before the draw, does it keep them? If the answer is "no" or "they update", the accuracy you can see is unmeasurable by construction, and there is no version of the arithmetic above that can be applied to it.

The purpose of these six is not to make prediction look silly. It is to give the word a definition that software can be held against - because a prediction is a number issued before an outcome, stored, and scored; and the entire industry either cannot produce the stored number, or produces one whose accuracy is the same 10% that an empty hand would have given you.

Frequently Asked Questions

Is a prediction algorithm impossible, or just this one?

This one, provably: its output distribution is uniform across all 1,000,000 inputs and any bias it inherits is raised to the third power. In general the question is empirical and has a crisp answer - any predictor must beat 1 ÷ payout on out-of-sample bets. On a fair source no predictor can; on an unfair one, a model that estimates the marginal distribution directly can, and the recipe in this article is the worst possible way to do it.

The tips page says "high-probability". Is that a lie?

Measured against this page's enumeration, every output of that recipe has the same probability as every other, so no predicted number is high-probability relative to any other. What the sentence does capture is a real property of the game: the recipe's answer is a legitimate anna and will sometimes win. That is exactly the sense in which a coin "sometimes" lands heads, which is why the sentence needs the break-even column next to it.

Why is the single-digit bet the easiest to beat break-even on?

Because its relative ask is the smallest on the list: 5.26% better than chance, versus 19.05% for a panna, 42.86% for a triple panna and 177.78% for a full sangam. The rate card prices the exotic bets far below their fair odds. Easiest, though not easy - it still requires a margin that roughly 13,000 bets are needed to see.

Does an AI model change the required sample size?

No. The sample size comes from the distance between chance and break-even, not from the algorithm's sophistication. A better model can in principle close that distance; it cannot make the distance easier to measure, and it makes overfitting easier, since a flexible model on a few hundred results will report accuracy improvements that were only ever in the training data.

Can I use the winner-prediction screen in the admin panel to forecast?

No, and it is worth understanding why, because the screen's name invites the error. It takes the result as an input - you type in a hypothetical panna - and returns the bets that would win against it. It predicts payouts conditional on a result, never the result. Every honest prediction tool works in the other direction.

What about software that claims 90% accuracy?

90% against a 10.5263% bar is not a marginal case that needs 13,000 bets to verify; it would be visible in about ten. Claims of that size are refuted almost immediately by the vendor's own records if they exist - which is why they never do. The page in this series on what such a claim would have to show works through the specific evidence it would need.

Why does the operator cap high-payout bets more tightly?

Because it is the only rational response to the same arithmetic. Starline allows ₹50,000 on a 9.5 rate and ₹2,000 on a 700 rate, which keeps the expected loss at the cap inside a narrow band instead of letting it grow with the multiplier. It is a policy statement about which bets the operator believes are worse for the player, taken from configuration rather than marketing.

So what is the chart actually good for?

Accounting, not forecasting. A chart is the only place most players can check that the result they were paid on is the result that was declared, and that the history under it is complete. Those are real, useful, checkable things - and they are the subjects of the completeness and frequency audits elsewhere in this series.