Start with the full item table
A Rust case normally has a price, a list of possible items and a probability for each outcome. The first check is whether every item and probability is available before opening. Promotional tiles often emphasize rare expensive skins, but the common low-value outcomes determine most of the expected return.
The probabilities should total 100%, subject only to a clearly explained rounding difference. If an item list is visible but probabilities are absent, the page does not contain enough information to calculate expected value.
Expected value in plain language
Multiply each item’s credited value by its probability and add the products. The result is the average credited value predicted over a very large number of identical openings. It is not the amount a person should expect from a single case.
Suppose a five-unit example case has a 70% chance of a one-unit item, a 25% chance of a four-unit item and a 5% chance of a twenty-unit item. Its expected credited value is 0.70×1 + 0.25×4 + 0.05×20 = 2.70 units. Dividing 2.70 by the five-unit price gives an implied return of 54%. These numbers are examples, not live operator data.
Credited value is another assumption
The calculation uses the values displayed by the site. Those values may differ from Steam Community Market observations, third-party cash markets or the price attached to current withdrawal stock. A transparent case table can therefore describe its internal mathematics without guaranteeing an external resale value.
Read how Rust skins are valued before treating site balance and market value as interchangeable.
Roll mapping and provably fair checks
Some systems convert a cryptographic output into a number across a fixed range, then map ranges to items. A completed-round check should let a reader verify the committed server seed, client seed, nonce and calculation used for the roll. The item table must still show which roll range corresponds to which item.
The verifier answers “did this recorded input produce this recorded roll?” It does not answer “was the case priced attractively?” The provably fair guide separates those questions.
Case opening versus case battles
A battle may use the same underlying case outcomes but adds a winner rule across multiple players or teams. Check whether the highest total, lowest total or another mode wins, and whether a separate fee applies. Our case battle modes guide covers those structures.
Audit the table before calculating it
Start by counting rows and summing the displayed probabilities with full precision. A total of 99.99% or 100.01% can be explained by rounding; a materially larger gap needs an explanation. Also check for duplicated cosmetics with different conditions, wear states or site values. Combining them too early can hide a mapping error.
Copy the case price and item values in their original balance unit. If the interface mixes cents, coins and dollar-like labels, normalize only after documenting the conversion. Do not add a Steam cash reference to some rows while leaving other rows at the operator's internal value.
Sensitivity: the value source can change the answer
Return to the hypothetical five-unit case with probabilities 70%, 25% and 5%. Its internal values of 1, 4 and 20 produce an expected credited value of 2.70. If a consistent external reference instead values those items at 0.70, 2.80 and 13, the expected external reference becomes 0.70×0.70 + 0.25×2.80 + 0.05×13 = 1.84 units.
Neither result is universally “the real RTP.” The first measures expected site credit under the displayed table; the second models a separate external reference. Label the numerator and denominator so a reader knows what the percentage describes.
What a useful case page answers immediately
- What does one opening cost in the displayed balance unit?
- Are all possible items and exact probabilities visible before opening?
- What timestamp and price source determine each credited value?
- Do probabilities map to explicit roll intervals without gaps or overlaps?
- Can a completed round expose the inputs needed to reproduce its roll?
- Is the table version preserved when odds or values change?
If the page cannot answer the second question, expected value remains unknown. A sample of recent drops cannot repair the missing distribution: rare outcomes require far more observations than a promotional history normally provides.
Why “one in 100” is not a session forecast
A 1% item probability means each eligible opening follows a one-in-100 model under the published assumptions. It does not mean the item must appear once in any block of 100, nor that a long miss makes the next opening more likely. The relevant check is whether rounds are independent under the published method and whether the probability table stayed unchanged.
Case expected-value worksheet
Copy the entire case table rather than selecting only the rare outcomes shown in promotional artwork.
| Field | What to record | Why it matters |
|---|---|---|
| Case price | Cost in the displayed balance unit | Denominator for implied return |
| Probability table | Every item chance totals approximately 100% | Defines the outcome distribution |
| Credited values | Site value for every possible item | Supplies the expected-value weights |
| Roll mapping | Random range assigned to each item | Connects fairness output to the item |
Interpretation: Expected credited value describes a repeated mathematical model; it does not predict one opening or guarantee external resale value.
The case-opening site comparison lists operators whose public catalogues name case opening. Inclusion does not mean every case publishes enough data for a complete calculation.