Standard highest-total battles
In the common format, every participant opens the same sequence of cases. The credited value of their items is added across the round, and the participant or team with the highest total receives the settlement described by the rules. Equal case access does not mean equal expected profit because the case prices and platform fee still apply.
A clear battle page should show the selected cases, number of rounds, player slots, entry cost, mode and winner rule before a person joins.
Teams and multi-player formats
Team battles normally add the item totals of team members. The rules should explain how uneven teams, disconnected participants and ties are handled. Multi-player free-for-all battles may give everything to one player or divide value under a different settlement model.
Do not infer the payout simply from a visual layout. Read the written rule for the exact mode.
Crazy, terminal and alternative modes
“Crazy” commonly means the lowest total wins rather than the highest. Other operator-specific names may change how final rounds, shared pots or item distribution work. These modes alter volatility and the winning condition; they do not turn a negative-cost game into a positive one.
Bots and empty seats
Some sites allow automated participants to fill seats. Useful documentation explains whether a bot funds an entry, receives outcomes through the same random process, can win the settlement and affects the human participant’s payout. If those details are not public, mark them unknown.
Where the cost appears
The platform cost may be embedded in the underlying cases, added as a battle fee or reflected in item valuation. A “no additional fee” statement does not establish that the cases themselves have no edge. Use the case odds guide to inspect the underlying distribution.
Verifying a completed battle
A useful record identifies the battle, player positions, cases, mode, seeds or commitments, each generated roll and final settlement. Verification needs to reproduce each case outcome and show that the winner rule was applied to the resulting totals.
Saving only a screenshot of the final animation is not enough to recalculate the round. Record the battle or round ID and the relevant verifier route.
One sequence, three different winners
Assume Alice and Ben open the same two hypothetical cases. Alice's credited items total 18 units and Ben's total 11. In standard highest-total mode, Alice wins under a winner-takes-all rule. In crazy mode, Ben wins because the lower total is the objective. In a terminal-style mode, the rules might make only the final case decisive, so the earlier totals could become irrelevant.
Nothing about the underlying case rolls changed. The settlement changed because the selected mode changed. That is why a battle screenshot without the pre-entry mode cannot establish who should have been credited.
For teams, add one more layer. If four players produce totals of 18, 11, 7 and 15, teams 18 + 7 and 11 + 15 finish 25–26. A site could settle the team total, the best individual, or another published rule. The interface should not leave that choice implicit.
Tie rules are part of the price
A tie may trigger a reroll, split, coinflip, house-favouring priority or another mechanic. Each changes the outcome distribution. Record the exact tiebreak and whether it creates another fee-bearing event. “Ties are rare” is not a substitute for a rule.
The same applies to bots. If a bot can win, identify who funds its seat and where the settlement goes. If a bot merely fills animation space, it should not be treated as an economic participant. Unknown documentation stays unknown in the case-battle comparison.
Reconcile cost before calling a mode cheaper
Add the prices of every underlying case, any displayed battle surcharge and the operator's item-value basis. Then compare that entry cost with the complete distribution and settlement. A battle advertised with “no battle fee” can still inherit the edge embedded in each case; a visible fee is not necessarily the only cost.
Keep the fairness audit separate. First reproduce the case outcomes. Next total them using the recorded valuations. Finally apply the mode and tiebreak. If the first step passes but the final credit does not follow the rule, the remaining issue is settlement rather than random generation.
Battle settlement record
Capture the mode before entry because the same case sequence can settle differently under another mode.
| Field | What to record | Why it matters |
|---|---|---|
| Mode and teams | Highest, lowest, team or alternative | Defines the winning objective |
| Underlying cases | Price, item odds and displayed values | Supplies each generated item |
| Round record | Rolls, positions and item totals | Reconstructs the completed battle |
| Settlement | Tie rule, fee and item distribution | Connects totals to the credited winner |
Interpretation: A verified roll is only one layer; the winner and credited amount still depend on the published battle settlement rule.
Compare currently listed operators on the Rust case battle sites page, then open the individual review and dated evidence table before following an outbound link.
