Fairness and Round Verification

1. About this document

1.1 This document explains how the result of every RUST50/50 coinflip round is decided, how that result is fixed before anyone can see it, and how any person can check a finished round, either with the Round checker on the site or with their own code. It is the long companion to the Round checker: the checker does the calculation for you, and this document tells you exactly what the calculation is, so that you do not have to take the checker on trust.

1.2 RUST50/50 ("RUST50", "we", "us", "our") is operated by Rust50 Entertainment Ltd at https://rust50.com. RUST50/50 is not affiliated with, endorsed by or sponsored by Valve Corporation or Facepunch Studios. Steam and Rust are trademarks of their respective owners.

1.3 This document forms part of our Terms and Conditions (Terms clause 1.2) and gives the full detail of the rules summarised in Terms clauses 9 (how results are determined) and 11 (the house fee). The Terms govern your use of the site as a whole. If the two documents conflict, the order of precedence in Terms clause 1.2 applies, under which the Terms prevail over this document. Both are intended to describe the same calculation: the one the site actually performs, set out in full in sections 5 to 9 and 14 of this document. If the Terms and this document ever seem to describe it differently, we will treat the difference as a drafting error, correct it under section 20 and deal with any round affected under Terms clause 13 and section 15.6.

1.4 Current status. Real Steam trading is currently disabled. The site runs a public test mode that uses simulated items with no real-world value. There are no real deposits, payouts or winnings in the test mode. If you sign in with Steam during the test mode, your real Steam inventory can be viewed read-only, but real items cannot be staked or transferred. The fairness calculation described here is the same code in the test mode and is the calculation intended for real-item rounds at launch. Where this document describes trade offers, deposits, payouts and fees on real Steam items, it describes how the service is designed to work when real trading is enabled.

1.5 Provably fair is not a certification. Where the operator holds a licence from the Curaçao Gaming Authority (CGA) (licence HE 452139), the CGA licence conditions require each game to be certified for soundness and integrity by a testing laboratory approved by the CGA (licence conditions, art. 10). The CGA's licence application form lists provably fair games as a recognised category, but it also asks whether the operator's games are certified, so a provably fair method does not take the place of certification. The provably fair method described here is a transparency tool for players. It does not replace laboratory certification, and nothing in this document claims that the game has been certified.

1.6 This document is written for players who want to understand a round before they play, players who want to check a round after it has finished, and anyone who handles a complaint about a result. You do not need to read the technical sections to play, but you are entitled to rely on them.

1.7 The game at a glance. The table summarises the rules, odds, costs and payout arrangements explained in the rest of this document. The section references point to the full rule.

2. Definitions

2.1 In this document the following words have these meanings. Words defined in the Terms have the same meaning here unless this table says otherwise.

3. What provably fair means, and what it does not

The idea

3.1 In most online games you have to trust that the operator's random number generator is honest, because you cannot see how a result was produced. A provably fair game changes this. Before the result exists, the operator publishes a fingerprint (the commitment) of a secret value (the server seed). After the round, the operator reveals the secret. You can then check two things yourself: that the revealed secret matches the fingerprint published earlier, and that the result follows from the secret by a published formula. If both checks pass, the operator could not have swapped the secret after seeing who joined, and could not have changed the result after the event, without you being able to detect it.

What a successful check proves

3.2 When you check a finished round and every check passes, you have established that:

1. the revealed server seed is the seed whose SHA-256 hash is the commitment. If you saw and kept a copy of that commitment before the result, you have established that the seed was fixed before the result;
2. the roll follows from the server seed, the client seed and the nonce by the formula in section 8;
3. the winner follows from the roll and the recorded creator and joiner values by the rule in section 9; and
4. therefore nobody, including us, changed the server seed, the roll or the winner after the commitment was published without that change being detectable.

What it does not prove

3.3 Provably fair is a strong tool but it has limits, and you should know them. A successful check does not, on its own, prove:

1. That the server seed was chosen at random. Our server creates the server seed with a cryptographically secure random number generator at the moment the round is created, in the same step in which it records the creator's client seed. The commitment proves that the seed was not changed after it was published. It cannot prove how the seed was chosen in the first place. The design therefore relies on the server generating the seed randomly rather than selecting a seed that produces a particular roll.
2. That the server seed was kept secret until the reveal. The roll depends only on the server seed, the client seed and the nonce, and the client seed and nonce are public from the start. Anyone who learned the server seed of an open round could therefore work out its roll before joining, and could decide whether to join and with what stake inside the permitted range. Protection against this comes from keeping server seeds secret and from the rule that our staff and key persons may not play (section 15), not from mathematics.
3. That the item values were right. The values used for the chance and the fee come from our pricing source. Valuation is outside the provably fair calculation (section 13).
4. That the trades settled. Deposits and payouts are Steam trade offers. Steam Guard confirmations, trade holds, restrictions or Steam outages can delay or block them. The calculation says who won; it cannot move items on Steam.
5. That the other player was independent. The check cannot show whether two accounts were controlled by the same person or were cooperating. That is dealt with by our account rules and monitoring under the Terms.
6. That every round which should have been settled was settled. A round that ends without a result, because it was cancelled or held, has no roll to check. Section 16 explains when this happens and what records are kept.
7. Anything, if you did not see the commitment before the result. If the only copy of the commitment you have is the one the site shows you now, the check proves that the stored record is internally consistent. It does not prove that this record existed before the result. Keep your own copy of the commitment before a round you care about is settled (section 11.7).
8. That the game is certified. See section 1.5.

Why it is still worth checking

3.4 Within those limits, the method gives you something a closed system cannot: an independent way to confirm, for each finished round, that the published inputs produced the published result by the published formula, and that the secret input was not swapped after the commitment. Each check takes seconds, it needs no account, and it does not depend on our software if you use your own code (section 12).

4. When each value is fixed during a round

4.1 The table shows the stages of a round, what happens at each stage, and which values are public or fixed by the end of it. Timings are the current settings of the service.

4.2 The consequence that matters most is this: the result is a fixed function of inputs that are all stored by the time the joiner's trade is confirmed. The server seed, client seed and nonce exist from stage 1, and the creator and joiner values are recorded when each player's items are added. Nothing that happens afterwards, including the countdown, the animation, later price changes, chat, promotions or anything an administrator does, enters the calculation.

4.3 If our service restarts after a join has been confirmed but before the round has been settled, the round is settled when the service is running again, using the roll and winner already stored. Recalculating the round from its inputs gives the same result, because the calculation is deterministic.

4.4 In the current test mode, trade offers are simulated and no real items move. The stages and the calculation are otherwise the same.

5. The commitment: server seed and SHA-256

5.1 Generating the server seed. For each new round the server takes 32 bytes (256 bits) from the cryptographically secure random number generator provided by the Node.js crypto module, and writes them as 64 lowercase hexadecimal characters. Each round gets its own new server seed. Server seeds are never reused and are never derived from the seed of another round.

5.2 Calculating the commitment. The commitment is the SHA-256 hash of the server seed's 64 characters of text, written as 64 lowercase hexadecimal characters. The 64 characters are hashed as text (each character is one byte in UTF-8), not as the 32 bytes they represent. This detail matters if you write your own checker: hashing the decoded bytes gives a completely different value (section 12.7).

5.3 Example. The server seed

82f17e244e1cfaebcb40695ba47b5a23e1534e259db649dedaa6f64bca60b249

has the commitment

3caf107c581b3e7f51acf7a690519f876736f04f0c89121928dc5b675d1389e9

5.4 Publication. The commitment is stored with the round when it is created and is part of the public round record from that moment. It is shown in the Round checker and is available to anyone who opens the round, before any joiner commits items to it.

5.5 Why a hash works as a commitment. SHA-256 has two properties that matter here. First, it is one-way: knowing the commitment does not let anyone work out the server seed, so publishing the commitment does not give away the result. Second, it is binding: nobody knows how to find a second, different seed with the same hash, so once the commitment is published we are tied to one server seed. If we revealed a different seed, its hash would not match. No practical method is publicly known for breaking either property of SHA-256.

5.6 Keeping the seed secret. Until a round is settled, its server seed is not shown on the site, in the Round checker, in public round data or in the owner console, which shows a round's server seed only after the round has finished. Section 3.3(b) and its drafting note explain why secrecy matters and what further controls are planned.

5.7 Revealing the seed. The server seed is revealed when the round is settled (stage 7 in section 4). From then on it is part of the public round record together with the roll and the winner. The server seed of a round that ends without a result is not revealed (section 16.3).

6. Client seeds

6.1 Purpose. The client seed is an input that the creator can choose, so that the calculation includes text supplied by a player as well as the server's secret. In the current design the client seed is submitted at the moment the round is created and the server seed is generated in the same step, so the client seed lets the creator see that their own text was used, but it does not by itself stop a dishonest server from selecting a server seed (section 3.3(a)). The creator cannot see the server seed when choosing the client seed, so the creator cannot use the client seed to steer the result either.

6.2 Choosing a client seed. When creating a round, open "Client seed" in the create dialog and type any text of up to 64 characters. Spaces and other blank characters at the beginning and end are removed. Text longer than 64 characters is cut to the first 64. Some symbols, such as emoji, count as two characters for this limit.

6.3 If you leave it empty. If you leave the field empty, or enter only spaces, the server generates a client seed from 8 random bytes, written as 16 lowercase hexadecimal characters, for example a9bcf477e49b84b0.

6.4 Public and fixed. The client seed is public from the moment the round is created, and it cannot be changed afterwards by the creator, the joiner or us. The joiner does not supply a client seed. A joiner who wants to know the inputs before joining can read the commitment, client seed and nonce in the round record.

6.5 Exactness. The client seed is used exactly as recorded. It is case-sensitive, every character counts, and it is encoded as UTF-8 text. To avoid copying and encoding mistakes when you check a round with your own code, we recommend client seeds made only of letters, digits and hyphens.

6.6 A client seed cannot make you luckier. Because the server seed is secret and random, every client seed gives the same chance. Your chance of winning depends only on your share of the pot value (section 9). There are no lucky or unlucky seeds, and no seed, name or strategy can improve your chance.

6.7 Test mode sample rounds. In the public test mode, some sample rounds are opened by labelled test identities using the fixed client seed Rust50-preview. They use the same calculation as every other round and involve only simulated items.

7. Nonces and round numbers

7.1 Format. The nonce is a whole number written in ordinary decimal digits, with no leading zeros, spaces, commas or "#" sign. In the calculation it is placed after the client seed and a colon (section 8).

7.2 New rounds: the nonce is the round number. Every new round is given a random ten-digit round number between 1,000,000,000 and 9,999,999,999. The server checks that no other round already has that number before using it. For these rounds, the nonce is exactly the round number. For example, round #3527580646 has the nonce 3527580646.

7.3 Older rounds keep their original nonce. Before ten-digit round numbers were introduced, rounds used a different stored nonce, a small sequential number. Those rounds keep the nonce that was stored when they were created. They were later given a ten-digit round number so that they can be looked up in the Round checker, but their nonce was not changed and their result was not recalculated. For an older round, the nonce is therefore not the same as the round number.

7.4 Rule for checking. Always use the nonce shown in the round record. Do not assume that the nonce equals the round number. The Round checker fills in the stored nonce automatically when you look a round up.

7.5 What goes wrong with the wrong nonce. A different nonce gives a completely different HMAC and therefore an unrelated roll, which may point to the other winner. Example 4 in section 10 shows this with real values.

7.6 Why the nonce need not be secret. The nonce is public from the start. Its job is to make the calculation specific to one round. Secrecy and unpredictability come from the server seed, not from the nonce.

8. The roll

8.1 The roll is calculated in four steps.

1. Build the message. Join the client seed, a colon and the nonce into one piece of text: <client seed>:<nonce>. For example: survivor-2026:3527580646.
2. Calculate the HMAC. Calculate HMAC-SHA256 with the server seed as the key and the message as the data. The key is the server seed's 64 characters of text, exactly as for the commitment. The message is encoded as UTF-8. The result is 64 hexadecimal characters.
3. Take the first 8 hexadecimal characters. These are the first 4 bytes (32 bits) of the HMAC. Read them as a hexadecimal number. This gives a whole number from 0 to 4,294,967,295.
4. Divide. Divide that number by 4,294,967,295 (hexadecimal ffffffff). The result is the roll.

8.2 In one line:

roll = integer(first 8 hex characters of HMAC-SHA256(key = server seed, message = client seed + ":" + nonce)) / 0xffffffff

8.3 Range. The roll is at least 0 and at most 1. There are 4,294,967,296 possible values. A roll of exactly 0 happens only when the first 8 characters are 00000000, and a roll of exactly 1 only when they are ffffffff.

8.4 Uniformity. HMAC-SHA256 is designed so that, to anyone who does not know the key, its output cannot be told apart from random data, and no practical method of doing so is publicly known. With a randomly generated server seed, each of the 4,294,967,296 possible values of the first 8 characters is therefore, for all practical purposes, equally likely, and the roll is spread evenly between 0 and 1. The remaining 56 characters of the HMAC are not used.

8.5 Precision. The division is done in standard double-precision floating-point arithmetic (IEEE 754). Every mainstream language that uses this arithmetic, including JavaScript, Python and awk, produces exactly the same roll. The Round checker displays the roll to 10 decimal places, but the comparison in section 9 uses the full value. If you want an exact comparison, compare the 8 hexadecimal characters or the whole number from step 3, which involve no rounding at all.

9. The stake-weighted winner rule

9.1 Chance equals share of the pot. Each player's chance of winning is that player's share of the pot value:

creator chance = creator value / (creator value + joiner value)
joiner chance  = 1 - creator chance

9.2 Deciding the winner. The creator wins if the roll is less than the creator chance. Otherwise the joiner wins. If the roll were exactly equal to the creator chance, the joiner would win. The winner's side is the side that player chose or took: the creator's side if the creator wins, and the other side if the joiner wins.

9.3 Sides are labels. Black and White are labels only. The roll is compared with the creator chance in the same way whichever colour the creator picked. Low rolls favour the creator and high rolls favour the joiner.

9.4 Equal stakes are exactly 50/50. With equal stakes the creator chance is 0.5. Of the 4,294,967,296 possible values from step 3 of section 8.1, exactly 2,147,483,648 give a roll below 0.5. The creator and the joiner each win on exactly half of the possible values.

9.5 Unequal stakes. Because the roll has a finite number of possible values, the probability actually delivered can differ from the stated chance by at most 1 in 4,294,967,296 (about 0.0000000233 percentage points). For example, at a creator value of USD 100.00 and a joiner value of USD 94.00, the creator wins on 2,213,900,668 of the 4,294,967,296 possible values, which differs from the stated 51.5464% by less than 0.00000001 percentage points.

9.6 The join range. A joiner may stake between 94% and 106% of the creator value, each limit rounded to the nearest cent. Before rounding, this puts the creator chance between 48.5437% (joiner at the top of the range) and 51.5464% (joiner at the bottom of the range). Because the limits are rounded to the cent, very small stakes can fall slightly outside these figures: a creator value of USD 1.09 can be joined with USD 1.02 to USD 1.16, giving a creator chance between 48.4444% and 51.6588%. From a creator value of USD 10 upwards the effect is less than 0.02 percentage points. Whatever the values, the chance used is always the exact share of the pot, and it is shown before the joiner confirms. The table shows the range for some creator values.

9.7 Values used. The creator value and joiner value used in the calculation are the values recorded for the round, rounded to cents, when each player's items were added. The exact chance is shown to the joiner before the joiner confirms. A later change in the price of an item does not change the chance of a round that has already been created or joined.

9.8 Nothing else counts. No other factor affects the chance or the result: not account age, history, win or loss record, referral status, promotions, a Steam display-name tag, chat activity, the side chosen, the time of day or the client seed.

10. Worked examples

10.1 The examples below use illustrative values generated for this document. They are not real rounds and the round numbers do not belong to real rounds. Every number was produced by a script using the Node.js node:crypto module and cross-checked against the site's own fairness and fee code. You can reproduce each example with the code in section 12.

Example 1: equal stakes, creator's own client seed

10.2 The creator stakes USD 50.00 on Black and types the client seed survivor-2026. The round number and nonce is 3527580646. The joiner stakes USD 50.00 and takes White.

Example 2: the creator's larger stake decides the round

10.3 The creator stakes USD 100.00 on White and leaves the client seed empty, so the server generates a9bcf477e49b84b0. The nonce is 7311601923. The joiner stakes USD 94.00, the lowest value the join range allows, and takes Black.

10.4 This roll is above 0.5. With equal stakes the same roll would have gone to the joiner. The creator won because the creator's larger share of the pot gave a creator chance slightly above 0.5142. This is the stake weighting at work: a player who puts in more value gets a proportionally larger chance, and a player who puts in less gets a proportionally smaller one.

Example 3: the joiner at the top of the range

10.5 The creator stakes USD 250.00 on Black with the generated client seed 3119c2890a21d46e and nonce 5635166970. The joiner stakes USD 265.00, the highest value the join range allows, and takes White.

10.6 The creator had the smaller chance in this round but still won. A larger stake improves a chance, it does not guarantee a win.

Example 4: an older round whose nonce is not its round number

10.7 An older round was created with the stored nonce 42 and later given the round number #4586346365. The creator staked USD 20.00 on White with client seed ec1f7b659aa3a7e8, and the joiner staked USD 20.00 on Black.

10.8 The commitment check passes in both columns, because it involves only the server seed. The roll and winner match the record only with the stored nonce. If you used the round number by mistake, the Round checker would report that the proof does not match the recorded result. That would not be a discrepancy in the round; it would be the wrong input (section 7.4).

Example 5: a swapped server seed is detected

10.9 Suppose that, after round #3527580646 from Example 1 was joined, someone tried to reveal a different server seed that differs from the real one only in its last character:

82f17e244e1cfaebcb40695ba47b5a23e1534e259db649dedaa6f64bca60b240

With this seed the roll would be 0.4187745830, below 0.5, and the creator (Black) would win instead of the joiner. But the SHA-256 hash of this seed is

0c6526c7ddc4bd5b4203039c8a365bf0acfa7aab73e69ebd21dffb2a99db86a8

which is nothing like the published commitment 3caf107c...5d1389e9. The Round checker would show "Hash mismatch. This seed does not match the commitment." A one-character change to the seed changes the hash completely, which is why a published commitment ties us to one seed.

11. Checking a round with the Round checker

11.1 Opening the checker. Open the Round checker from the link at the bottom of the lobby, or select "Check this round" in the details of any round.

11.2 Before the result: record the commitment. Enter the ten-digit round number, with or without the "#" sign, and select "Find round". The checker shows the round record: round number, status, commitment (server seed hash), client seed, nonce, and each player's side and stake value (or "Open seat" if nobody has joined). While the round is not finished, the checker notes that the seed will be revealed after the flip and the "Verify result" button is disabled. If a round matters to you, copy the commitment, client seed and nonce into a note or take a screenshot now, before the result.

11.3 After the result: look the round up again. Once the round is finished, the record also shows the revealed server seed, the recorded roll (to 10 decimal places) and the recorded winner. The verification fields are filled in from the record. If the checker was already open on that round, it updates when the round finishes.

11.4 Verify. Select "Verify result". The checker calculates, in your browser, using the browser's built-in Web Crypto functions:

1. the SHA-256 hash of the revealed server seed, and compares it with the commitment;
2. the HMAC-SHA256 of client seed:nonce with the revealed server seed as key, and the roll from its first 8 characters;
3. the creator chance from the creator value and joiner value; and
4. the winner, which it compares with the recorded roll and recorded winner.

The result panel shows the commitment check, the computed roll, the recorded roll, the creator chance, the computed winner and the recorded winner, and states "Calculated locally in this browser." The calculation itself does not send the seeds anywhere.

11.5 Messages.

11.6 Manual mode. If you change any field, the checker stops comparing with the stored round and shows "Manual fields. This check is not linked to a stored round." You can use manual mode to check values from your own notes, to try the worked examples in section 10, or to see what happens with a wrong input.

11.7 The strongest check uses your own copy. When the checker looks a round up, it shows what our database stores now. "Verified" therefore confirms that the stored record is internally consistent. To confirm that the seed was fixed before the result, compare the revealed seed with the commitment you copied before the round was settled. You can do this in manual mode: paste your saved commitment into the "Server seed hash" field and the revealed seed into the "Revealed server seed" field. If they match, you will see "Commitment matches".

11.8 A record held by Steam. When real trading is enabled, the message of the creator's deposit trade offer is designed to include the first 12 characters of the round's commitment. Because that message is created before the round can be joined and is shown to you in Steam, it gives the creator a record of the commitment that is not held only on our site.

11.9 Round links. The copy button in a round's details copies a link of the form https://rust50.com/game/<round number>, which you can keep with your notes.

11.10 Round records are public. Anyone with a round number can see its record, including the players' Steam display names and avatars, their sides, the items and their recorded values, and the fairness values. Public round data also includes each player's Steam account identifier (SteamID64). See What other users can see in the Privacy Policy.

12. Checking a round independently with code

12.1 You do not have to use the Round checker. Each snippet below implements sections 5 to 9 with standard tools and no third-party packages, so you can check a round without relying on any code we wrote. Replace the example values with the values of your round. Each snippet was run before publication and its output is shown below it.

JavaScript (Node.js)

12.2 Save as verify.mjs and run node verify.mjs (Node.js 18 or later). The values are from Example 1.

// verify.mjs - run with: node verify.mjs   (Node.js 18 or later, no packages needed)
import { createHash, createHmac } from 'node:crypto';

// Copy these values from the Round checker or the round record.
const round = {
  serverSeedHash: '3caf107c581b3e7f51acf7a690519f876736f04f0c89121928dc5b675d1389e9',
  serverSeed: '82f17e244e1cfaebcb40695ba47b5a23e1534e259db649dedaa6f64bca60b249',
  clientSeed: 'survivor-2026',
  nonce: 3527580646,
  creatorSide: 'black',
  creatorValue: 50.00,
  joinerValue: 50.00,
};

// The seed is used as text (its 64 hexadecimal characters), not as decoded bytes.
const commitment = createHash('sha256').update(round.serverSeed, 'utf8').digest('hex');
const hmac = createHmac('sha256', round.serverSeed).update(`${round.clientSeed}:${round.nonce}`, 'utf8').digest('hex');
const roll = parseInt(hmac.slice(0, 8), 16) / 0xffffffff;
const creatorChance = round.creatorValue / (round.creatorValue + round.joinerValue);
const otherSide = round.creatorSide === 'black' ? 'white' : 'black';
const winner = roll < creatorChance ? round.creatorSide : otherSide;

console.log('commitment ok :', commitment === round.serverSeedHash.trim().toLowerCase());
console.log('hmac          :', hmac);
console.log('roll          :', roll.toFixed(10));
console.log('creator chance:', (creatorChance * 100).toFixed(4) + '%');
console.log('winner        :', winner.toUpperCase());

Output:

commitment ok : true
hmac          : 902992106913f8e626ba378e067e03a76b4f641f1c77b41114882cea00572ace
roll          : 0.5631343165
creator chance: 50.0000%
winner        : WHITE

JavaScript (browser console)

12.3 This version uses the Web Crypto API built into modern browsers, the same API the Round checker uses. Paste it into the developer console of a page loaded over HTTPS. The values are from Example 4, the older round with nonce 42. We ran it in Node.js 24, which provides the same Web Crypto API. Only paste code into a browser console if you have read it and understand what it does. This snippet only calculates and prints values. Never paste code that someone sends you in chat or by message, especially while you are signed in to any site.

// Paste into the developer console of any modern browser (it uses the built-in Web Crypto API).
(async () => {
  const round = {
    serverSeedHash: 'e0a319e259ddc2010b64e0386ec61587e920c78fa1a629874c20f790d894acf5',
    serverSeed: 'babffa238df6ca2c12149b65c738ebfb5a98d78c79d70ad10f3f4f62a45bea37',
    clientSeed: 'ec1f7b659aa3a7e8',
    nonce: 42,
    creatorSide: 'white',
    creatorValue: 20.00,
    joinerValue: 20.00,
  };
  const bytes = (text) => new TextEncoder().encode(text);
  const hex = (buffer) => [...new Uint8Array(buffer)].map((b) => b.toString(16).padStart(2, '0')).join('');
  const commitment = hex(await crypto.subtle.digest('SHA-256', bytes(round.serverSeed)));
  const key = await crypto.subtle.importKey('raw', bytes(round.serverSeed), { name: 'HMAC', hash: 'SHA-256' }, false, ['sign']);
  const hmac = hex(await crypto.subtle.sign('HMAC', key, bytes(`${round.clientSeed}:${round.nonce}`)));
  const roll = parseInt(hmac.slice(0, 8), 16) / 0xffffffff;
  const creatorChance = round.creatorValue / (round.creatorValue + round.joinerValue);
  const winner = roll < creatorChance ? round.creatorSide : (round.creatorSide === 'black' ? 'white' : 'black');
  console.log({ commitmentOk: commitment === round.serverSeedHash, hmac, roll: roll.toFixed(10), creatorChance, winner: winner.toUpperCase() });
})();

Output:

{
  commitmentOk: true,
  hmac: '757c08e7126f21ab9931c1f109b290b8bd0ce693d33148324dfd5418ae6a7607',
  roll: '0.4589238706',
  creatorChance: 0.5,
  winner: 'WHITE'
}

Python

12.4 Save as verify.py and run python3 verify.py (Python 3.6 or later, standard library only; on Windows the command is usually python verify.py or py verify.py). The values are from Example 2.

# verify.py - run with: python3 verify.py   (Python 3.6 or later, standard library only)
import hashlib
import hmac

# Copy these values from the Round checker or the round record.
server_seed_hash = "ea38f69ce4f772c60223ce202f3740a2ff4d61ae6d12586681d2802a57008429"
server_seed = "ab6e0f60ed74828724681104b5cc54be541ded1d94d132941ce77b11d3c2478e"
client_seed = "a9bcf477e49b84b0"
nonce = 7311601923
creator_side = "white"
creator_value = 100.00
joiner_value = 94.00

# The seed is used as text (its 64 hexadecimal characters), not bytes.fromhex(server_seed).
seed_text = server_seed.encode("utf-8")
commitment = hashlib.sha256(seed_text).hexdigest()
digest = hmac.new(seed_text, f"{client_seed}:{nonce}".encode("utf-8"), hashlib.sha256).hexdigest()
roll = int(digest[:8], 16) / 0xFFFFFFFF
creator_chance = creator_value / (creator_value + joiner_value)
other_side = "white" if creator_side == "black" else "black"
winner = creator_side if roll < creator_chance else other_side

print("commitment ok :", commitment == server_seed_hash.strip().lower())
print("hmac          :", digest)
print("roll          : %.10f" % roll)
print("creator chance: %.4f%%" % (creator_chance * 100))
print("winner        :", winner.upper())

Output:

commitment ok : True
hmac          : 83a2b2371fa248b01ec9d765c363fd9643ead1da7874a590e81f58031edcbcc2
roll          : 0.5142012964
creator chance: 51.5464%
winner        : WHITE

Shell with OpenSSL

12.5 Save as verify.sh and run sh verify.sh. It needs openssl, awk and cut, which are available on Linux and macOS and in Git Bash on Windows. The values are from Example 3.

#!/bin/sh
# verify.sh - run with: sh verify.sh   (needs openssl, awk and cut; works in Linux, macOS and Git Bash)
SEED='8e635add652d283a364f442abb4e44d2e9453f75f88b371ea9682add16145290'
HASH='743e1ed2188bc953ca7be098bcf7f0dafd8f6dd3f221f19939a5e50da7874314'
CLIENT='3119c2890a21d46e'
NONCE='5635166970'
CREATOR_SIDE='black'
CREATOR_VALUE='250.00'
JOINER_VALUE='265.00'

# printf '%s' adds no newline: the hash and HMAC must cover exactly the characters shown.
COMPUTED=$(printf '%s' "$SEED" | openssl dgst -sha256 | awk '{print $NF}')
if [ "$COMPUTED" = "$HASH" ]; then echo "commitment ok : true"; else echo "commitment ok : false"; fi
HMAC=$(printf '%s' "$CLIENT:$NONCE" | openssl dgst -sha256 -hmac "$SEED" | awk '{print $NF}')
echo "hmac          : $HMAC"
FIRST8=$(printf '%s' "$HMAC" | cut -c1-8)
awk -v n="$((0x$FIRST8))" -v cv="$CREATOR_VALUE" -v jv="$JOINER_VALUE" -v side="$CREATOR_SIDE" 'BEGIN {
  roll = n / 4294967295; chance = cv / (cv + jv)
  other = (side == "black") ? "white" : "black"
  printf "roll          : %.10f\n", roll
  printf "creator chance: %.4f%%\n", chance * 100
  printf "winner        : %s\n", toupper(roll < chance ? side : other)
}'

Output:

commitment ok : true
hmac          : 78d3214789dc6782ce0445ea7a235d0cc6042d3782357776176e5db47f065ef0
roll          : 0.4719715881
creator chance: 48.5437%
winner        : BLACK

OpenSSL commands on their own

12.6 For a quick manual check you can run the two OpenSSL commands on their own. With the values from Example 1:

printf '%s' '82f17e244e1cfaebcb40695ba47b5a23e1534e259db649dedaa6f64bca60b249' | openssl dgst -sha256
printf '%s' 'survivor-2026:3527580646' | openssl dgst -sha256 -hmac '82f17e244e1cfaebcb40695ba47b5a23e1534e259db649dedaa6f64bca60b249'

OpenSSL 3.2.1 printed:

SHA2-256(stdin)= 3caf107c581b3e7f51acf7a690519f876736f04f0c89121928dc5b675d1389e9
SHA2-256(stdin)= 902992106913f8e626ba378e067e03a76b4f641f1c77b41114882cea00572ace

The label before the "=" sign differs between OpenSSL versions (for example "HMAC-SHA256(stdin)=" in older versions). Only the 64 characters after it matter, which is why the script takes the last field with awk '{print $NF}'. The first 8 characters 90299210 are 2,418,643,472 in decimal, and 2,418,643,472 / 4,294,967,295 = 0.5631343165, as in Example 1.

Common mistakes

12.7 If your result differs from the record, check these points before reporting a discrepancy:

1. Hashing the decoded bytes. The seed is hashed and used as an HMAC key as 64 characters of text. Decoding it first (for example bytes.fromhex() in Python or Buffer.from(seed, 'hex') in Node.js) gives wrong values. For Example 1, hashing the decoded bytes gives 3d450e25e61f33ea7d046bdb9f642689bf5663b687499358129c3470d573769c instead of the commitment, and an HMAC with the decoded key gives 6fe89c5173f87596a7eec447282f8cd50225f600663f678d973eaefc732e0b30.
2. A trailing newline. echo adds a newline, which changes the hash. For Example 1, echo piped into openssl dgst -sha256 gives c832df083f29a0d1395f0329b8b0f4b2c55aad368f56736da8b924833fa26869. Use printf '%s'.
3. The wrong nonce. Use the stored nonce from the round record, not the round number, for older rounds (Example 4).
4. A changed client seed. The client seed is case-sensitive. Copy it exactly, without extra spaces or quotation marks. If it contains a single quote, the shell script needs different quoting.
5. Letter case in the hash. Hashes are shown in lowercase. If you paste an uppercase hash, convert it to lowercase before comparing.
6. The wrong stake values. Use the creator value and joiner value recorded for the round, not today's item prices or the pot after the fee.
7. A rounded roll. Compare the full roll, or the 8 hexadecimal characters, not a value rounded to fewer decimal places, especially when the roll is very close to the creator chance.
8. Swapped sides. The rule compares the roll with the creator's chance. A roll below the creator chance means the creator's side wins, whichever colour that is.

12.8 The snippets in this section were run with Node.js 24.18.0, Python 3.12.2 and OpenSSL 3.2.1 on Windows with Git Bash. Other recent versions should give the same output.

13. What the roll covers and what it does not

13.1 The roll decides one thing: which of the two players in a round wins the pot after the fee. It decides nothing else.

13.2 Item valuation is not part of the roll. Item values are in US dollars and come from our pricing source the Steam Community Market. They are shown to you before you confirm a stake, they can change between rounds, and the values recorded when items are added to a round are the values used for that round. The current test mode uses reference prices set by the owner, not live market quotes. Item values are used to calculate chances and the fee. They are not a promise by us that an item can be sold for that amount or has any particular cash value, and we do not buy items from players or pay out cash.

13.3 The fee is not part of the roll. The fee is worked out at settlement from the items in the pot, after the result is already fixed, and it does not depend on who won (section 14).

13.4 The animation is cosmetic. The countdown, the spinning coin and its slowing landing, which together last several seconds, are a presentation of a result that was calculated and stored when the join was confirmed, before the animation started. The animation does not generate, influence or delay the result, and with reduced motion turned on (in the site's preferences or your device settings) the result is simply shown. A frozen or skipped animation, a lost connection or reloading the page during the flip does not change the result. If anything shown on screen, such as the coin, a countdown, a notification, a lobby card or a sound, ever differs from the recorded result, the recorded result, which you can verify, prevails.

13.5 Trade settlement is not part of the roll. Whether and when a deposit or payout trade completes depends on Steam, including Steam Guard confirmation, trade holds, trade restrictions and Steam outages. These can delay or block a trade. They do not change a result.

13.6 The lobby and chat are not part of the roll. The order of rounds in the lobby, the history list, statistics and chat have no connection to any result.

14. The fee and the expected return

The fee rule

14.1 When a round is settled, after the result is fixed, we keep whole items from the pot as our fee. We choose the set of pot items whose total value is as close as possible to, but not more than, the fee cap. The fee cap is 8% of the pot value, rounded to the nearest cent. The fee can be lower than the cap, including zero when no item in the pot fits under the cap. The fee is not a percentage of the winner's profit. The winner receives all other items in the pot. The fee percentage is a setting of the service; it is currently 8%, and the software refuses to start with a setting above 8%.

14.2 How the items are chosen. Only items valued at or below the fee cap are considered. They can come from either player's stake. The server searches every combination of those items, counting in whole cents, and takes the combination with the highest total that does not exceed the cap. If more than one combination reaches that same highest total, the server takes one of them by a fixed, deterministic procedure; the fee value is the same either way.

14.3 The fee is independent of the result. The fee calculation uses only the items in the pot and their recorded values. It has no input about who won. The same items would be kept whichever player won, so the fee cannot influence the roll and the roll cannot influence the fee.

14.4 Where you see it. The result of a finished round shows the item value paid to the winner and the item fee. The round record identifies which items were kept as the fee.

Fee examples

14.5 These examples were calculated with the site's own fee code at 8%.

Expected return

14.6 Because each player's chance equals their share of the pot and the fee does not depend on who wins, every player in a round has the same expected return as a fraction of their stake:

expected item value received = stake value x (pot value - fee) / pot value
expected return              = 1 - fee / pot value

In F1, each player stakes USD 50.00 with a 50% chance of receiving USD 92.50, an expected USD 46.25, or 92.5% of the stake. In F2, the creator has a 51.5464% chance of USD 190.00 (expected USD 97.9381 on a USD 100.00 stake) and the joiner a 48.4536% chance (expected USD 92.0619 on a USD 94.00 stake): both 97.9381%. In F3 the expected return is 100% because no fee is taken. Across all rounds the expected return is between about 92% and 100% of the stake, depending on how closely the pot's items can fill the cap (in pots of only a few dollars it can be marginally below 92% because of the rounding described in section 14.8). It is lower than 100% whenever a fee is taken.

14.7 The expected return is a long-run average, not a prediction for any round. In any single round you either receive the pot after the fee or lose your whole stake. Returns are measured in item value from our pricing source, not in cash. Gambling should never be seen as a way to make money. See the Responsible Gambling Policy.

14.8 Rounding of the cap. Because the cap is rounded to the nearest cent, it can be slightly above the exact 8% figure, by less than half a cent. For example, in a USD 1.94 pot, 8% is USD 0.1552 and the cap is USD 0.16, so if the pot contains an item worth exactly USD 0.16, the fee is 8.25% of that pot. For pots of a few dollars or more the effect is negligible.

15. Why a committed result cannot be changed

15.1 The inputs are locked in. When a round is created, its server seed, client seed and nonce are stored with it and its commitment is published. When the join is confirmed, the recorded values complete the inputs, and the roll and winner are calculated and stored at once. From that point the result is a fixed function of stored inputs.

15.2 There is no control to change a result. The site has no function, for anyone, to edit a round's server seed, commitment, client seed, nonce, recorded values, roll, winner, odds or payout recipient. In particular:

1. The operator and administrators. The owner console is reached by the owner signing in with a one-time code sent by email. It can mute players for 1 hour, 24 hours or 7 days, ban players (each with a recorded reason in an audit log), view rounds read-only and view the audit log. It cannot change results, odds, seeds, balances or payouts, and it shows a round's server seed only after the round has finished.
2. Payout resends. A failed or unaccepted payout can be sent again, by the winner or by an administrator, but only to the recorded winner (or, for a refund, to the creator). A resend does not change the result.
3. Promotions. Referral codes, the inactive "2.5%" promotional eligibility field, the Steam display-name tag check and any giveaway never change odds, seeds or results. No rewards are currently credited through referrals (see the Promotions and Referral Terms).
4. Test tools. The owner's test tools in the test mode (a test inventory of simulated items, a labelled test-bot opponent, labelled sample rounds, a switch that hides test labels in the owner's own view only, a private set of simulated profile fixtures that is visible only in the owner console and is never shown to players, and a manual test window and simulated qualifying deposit for the planned giveaway) cannot change seeds, odds or results. Rounds against a test bot use the same calculation as any other round. Test bots are labelled, are not real players, and must never take part in real rounds or real draws.
5. Moderation. Muting or banning a player does not change the recorded result of any round.

15.3 The mathematics makes changes detectable. To reveal a different server seed after the commitment, someone would have to find a second seed with the same SHA-256 hash, which no one knows how to do (section 5.5). To change the roll or the winner without changing the seed, someone would have to publish a roll or winner that does not follow from the published inputs, which anyone can detect by recalculating (sections 11 and 12).

15.4 Detectable, not impossible. We run the servers and the database. Provably fair does not make it physically impossible for a person with access to the database to alter a stored record. What it does is make any change after the commitment detectable by anyone who kept a copy of the commitment and the inputs, and by anyone who recalculates a record. We undertake never to alter a result, and we keep the records described in section 17 for that reason.

15.5 Staff and key persons do not play. Our staff, key persons and their accounts, and any account controlled by us, may not create or join real rounds. Under the National Ordinance on Games of Chance (LOK), a person may not take part in a game if they already know its outcome, and key persons of the licence holder may not take part in its games (LOK art. 1.3). Section 3.3(b) explains why this rule matters for a provably fair game.

15.6 If a recorded result were ever wrong. The result given by the published formula, from the round's published inputs, is the correct result. If a technical fault ever caused a recorded result to differ from it, we would not silently correct the record. We would treat it as an incident, investigate it, inform the affected players, and put them, as far as possible, in the position they would have been in had the correct result been recorded, as set out in Terms clause 13. The original record would be kept, with a correction note added to it (section 17.4).

16. Cancelled, void and held rounds

16.1 A round can end without a result. The table sets out each case. Timings are the current settings.

16.2 A failed join does not change the roll. The roll depends only on the server seed, the client seed and the nonce, which do not change when a join fails. Whoever finally joins the round faces the same roll; only the creator chance, which depends on that joiner's stake value, can differ. Nobody who does not know the server seed can know the roll in advance, so a failed join gives no information about the result.

16.3 Seeds of rounds without a result. The server seed of a cancelled or held round is not revealed. Such a round has no roll and no result to verify. The Round checker shows it with its status and commitment. Its server seed is never used for any other round.

16.4 Held rounds. A held round never produces a result. After review, the items each player deposited into it are returned to that player, and the round is treated as void. Its record, including the reason it was held, is kept.

16.5 Void for other reasons. Terms clause 13 sets out the limited cases in which a round may be voided for an error, for example an obvious pricing error, and how staked items are then returned. Voiding a round does not alter its fairness record. The original values stay as they were, and the void status and its reason are added.

16.6 Steam reversals and restrictions. If Steam restricts, delays or reverses a trade after a round has been settled, the recorded result is not changed. What happens to the items concerned is governed by the Terms.

17. Records are never rewritten

17.1 Once a value has been written into a round record as part of its fairness proof, it is never edited or recalculated, including when our software changes. These values are the commitment, server seed, client seed, nonce, players' sides, recorded item values, roll, winner, fee items, fee value and payout value. The only entry that is ever removed is the entry of a joiner whose join trade failed or timed out (section 16.1): it is removed before any roll or winner has been fixed, and the round then waits for a new joiner with its original commitment, client seed and nonce.

17.2 Example. When ten-digit round numbers were introduced, older rounds were given a ten-digit number so they could be found, but their stored nonce, roll and winner were left exactly as they were (section 7.3).

17.3 Formula versions. There is currently one version of the calculation, described in sections 5 to 9 and 14. If we ever change the calculation, the change will apply only to rounds created after it takes effect. Each round will be verifiable under the rules in force when it was created, and this document will keep a description of every earlier version.

17.4 Additions, not overwrites. Information that legitimately changes after settlement, such as the state of a payout trade offer, a review note, a void status or a correction note, is recorded alongside the fairness values and does not replace them.

17.5 Retention. Round records are kept for the periods set out in How long we keep personal data in the Privacy Policy. Round, trade and fee records of real-value rounds are transaction records: they are kept for at least five years after each transaction, or for up to ten years if the Financial Intelligence Unit or another competent authority orders it. When a retention period ends, personal data in a record may be deleted or pseudonymised. That is not a rewrite of the fairness values, which stay as they were for as long as the record is kept.

17.6 Keeping your own evidence. We recommend that you keep a copy of the commitment, client seed and nonce of any round that matters to you before it is settled (section 11.7). Your own copy is the strongest evidence in any dispute.

18. Other random features

18.1 The provably fair method in this document applies to coinflip rounds only.

18.2 Planned giveaway ("Mazalito"). A planned hourly giveaway called "Mazalito" currently exists only as a test feature in the test mode. In that test, a 3-minute entry window opens every hour, the prize is one catalogue item worth USD 1 to USD 3 chosen at random, entry requires a qualifying deposit of USD 5, and the winner is drawn uniformly at random from the entrants using a cryptographic random number generator. This draw is not provably fair and cannot be checked with the Round checker. In the test mode, labelled test bots also enter; that must never happen in a real draw. No real prizes are given.

18.3 Referrals. The referral programme involves no randomness and no rewards are currently credited. It has no effect on any result or chance.

19. Reporting a suspected discrepancy

19.1 What to report. Please report it if, for example:

1. the Round checker or your own code shows a hash mismatch, or a roll or winner different from the record, when you have used the correct inputs;
2. the commitment you saved before the result differs from the commitment in the round record;
3. the client seed, nonce, sides or recorded values in the record differ from what you saw before the result;
4. the fee does not follow the rule in section 14;
5. a finished round's server seed was never revealed; or
6. you believe a round was cancelled or held when it should have been settled.

A difference between the animation and the recorded result is not a discrepancy in the result, because the animation is cosmetic (section 13.4), but you are welcome to report it as a display problem.

19.2 Check first. Most mismatches come from one of the mistakes in section 12.7, especially the wrong nonce for an older round, a trailing newline, or hashing decoded bytes.

19.3 What to include. To help us investigate quickly, include:

1. the round number;
2. your Steam display name and SteamID64, so that we can identify your account;
3. the commitment, client seed and nonce you saved, with any screenshot or note showing when you saved them;
4. the values you used and the output you obtained, with the tool or code you used; and
5. a short description of the problem and when it happened.

Never send us your Steam password or Steam Guard codes. We never need them and will never ask for them.

19.4 How to report. Follow the Complaints procedure, which has a section on round result disputes (Complaints section 8), or email complaints@rust50.com. For general questions about a round, contact support@rust50.com. Complaining is free of charge.

19.5 Time limits. The Complaints procedure sets out the time limits and steps, which follow the National Ordinance on Games of Chance (LOK art. 5.3). In summary, you may complain up to 6 months after the round was settled (Complaints section 4). We acknowledge a complaint in writing within one week and give a reasoned written decision within four weeks, which we may extend once by up to four further weeks with prior written notice (Complaints section 6). If you are not satisfied with our decision, you can refer the dispute to our independent alternative dispute resolution provider, the Cyprus Consumer Protection Service (Ministry of Energy, Commerce and Industry), free of charge (Complaints section 15). The Complaints procedure also explains the role of the Curaçao Gaming Authority (Complaints section 16). If this summary and the Complaints procedure differ, the Complaints procedure applies, because under Terms clause 1.2 it prevails on complaint handling.

19.6 What we do. When we receive a fairness complaint, we:

1. preserve the round record unchanged, together with the related trade offer records and logs;
2. recalculate the round independently of the site's own code, using the method in section 12;
3. compare the record with any evidence you sent, such as a saved commitment;
4. tell you the outcome in writing, with the values we used and our reasons; and
5. if we find an error, apply section 15.6 and, where the rules of our regulator require it, report the incident to the regulator.

20. Changes to this document

20.1 This document has a version number and an effective date, shown at the top. We review it whenever the game changes and at least once a year.

20.2 A change to the calculation itself (sections 5 to 9 or 14) applies only to rounds created after it takes effect, as described in section 17.3. We will give notice of such a change before it takes effect, as Terms clause 3 describes for material changes.

20.3 Corrections of drafting errors that do not change how the site works may be made at any time and will be listed in the version history. Earlier versions of this document are archived and available on request from support@rust50.com.