Skip to main content

What is Provably Fair?

Provably fair is a cryptographic verification system that allows players to verify that case opening results are truly random and not manipulated by the platform. Unlike traditional gambling systems where you must trust the operator, provably fair systems use cryptographic hashing to prove that outcomes were determined fairly.

Why It Matters

In traditional case opening platforms, players have no way to verify if the results are genuinely random. The platform could theoretically:
  • Manipulate results to give worse items to certain users
  • Adjust odds dynamically based on user behavior
  • Predetermine outcomes unfavorably
With a provably fair system, every case opening result can be independently verified by any player, ensuring complete transparency and fairness.

How It Works

Cajas implements a provably fair system using three cryptographic components:

1. Server Seed

A random 64-character hexadecimal string generated by the server:
  • Generated using cryptographically secure random bytes
  • Kept secret until the player requests a new seed
  • Used as the primary source of randomness
export function generateServerSeed(): string {
    return crypto.randomBytes(32).toString('hex');
}

2. Client Seed

A random 32-character hexadecimal string that players can customize:
  • Generated by default but can be changed by the player
  • Publicly known and controlled by the player
  • Ensures the server cannot predetermine outcomes
export function generateClientSeed(): string {
    return crypto.randomBytes(16).toString('hex');
}

3. Nonce

An incrementing counter that ensures each game is unique:
  • Starts at 0 and increases with each case opening
  • Prevents the same seed combination from producing identical results
  • Resets to 0 when seeds are rotated

The Verification Process

Before Opening a Case

  1. The server provides you with a hashed server seed (SHA-256 hash)
  2. You can see and modify your client seed
  3. The current nonce value is displayed
This information is shown before the case is opened, proving the server committed to a specific seed without knowing what you’ll receive.
export function hashSeed(seed: string): string {
    return crypto.createHash('sha256').update(seed).digest('hex');
}

During Case Opening

  1. Your client seed, the server seed, and nonce are combined
  2. An HMAC-SHA256 hash is calculated: HMAC-SHA256(server_seed, client_seed + "-" + nonce)
  3. This hash is converted to a number between 0 and 1
  4. The number determines which item you win based on probability weights

After Opening a Case

You receive:
  • The roll value (the random number between 0 and 1)
  • The server seed hash (to verify it matches what was shown before)
  • Your client seed and nonce used for this game
When you rotate seeds, the previous server seed is revealed, allowing you to verify all past games.

Trust Through Transparency

The key principle is commitment: The server commits to a server seed (by showing its hash) before you open cases. Since cryptographic hashes are one-way functions, the server cannot change the seed after seeing your client seed without you noticing the hash mismatch. This means:
  • The server cannot manipulate results after you set your client seed
  • You can influence randomness through your client seed
  • All results are deterministic and verifiable after the fact
  • No trust in the platform is required—only trust in mathematics

Security Guarantees

The server must commit to its seed before knowing your client seed. Since it cannot predict your seed or change its own without detection, it cannot manipulate outcomes.
This is prevented by the client seed. The server cannot know what client seed you’ll use, so it cannot predetermine outcomes. Even a small change to your client seed completely changes all results.
Using a nonce is more efficient and provides a better user experience. It allows for batch verification of multiple games without requiring seed rotation after every single case opening.

Next Steps

Implementation Details

Deep dive into the technical implementation and algorithms

Verification Guide

Learn how to verify your case opening results

Build docs developers (and LLMs) love