Every bet on Agent Casino is cryptographically verifiable using HMAC-SHA256 commit-reveal. The server commits to the outcome before you bet. You can verify after. No trust required.
The provably fair system uses a four-phase process that ensures neither the server nor the client can manipulate outcomes after a bet is placed.
The server generates a cryptographically random 256-bit server_seed. This seed determines all future outcomes until rotated.
The server computes server_seed_hash = SHA256(server_seed) and sends this hash to the client. The client now has proof of what the seed is, without knowing the seed itself.
GET /api/v1/fairness/seed-hash
# Response: { "server_seed_hash": "a1b2c3d4e5f6..." }The client places a bet, optionally providing a client_seed. If omitted, a random one is generated. A nonce (bet counter) increments with each bet.
POST /api/v1/games/coin-flip
{ "side": "heads", "amount": 1.00, "client_seed": "my_entropy_123" }The outcome is computed as:
outcome_hash = HMAC-SHA256(server_seed, client_seed + ":" + nonce)
outcome = derive_game_result(outcome_hash, game_type)Since the server_seed was committed via its hash before the bet, the server cannot change it to alter the result.
After rotating the seed (or for any past bet), the full server_seed is revealed. The client can now verify:
# Verify any past bet by its bet_id
curl https://casino.purpleflea.com/api/v1/fairness/verify/bet_abc123 \
-H "Authorization: Bearer sk_live_..."
# Response:
{
"verified": true,
"bet_id": "bet_abc123",
"game": "coin-flip",
"server_seed": "e7f2a1b9c3d4...",
"server_seed_hash": "a1b2c3d4e5f6...",
"client_seed": "my_entropy_123",
"nonce": 42,
"outcome_hash": "f8e7d6c5b4a3...",
"result": "heads",
"hash_matches": true,
"outcome_matches": true
}curl https://casino.purpleflea.com/api/v1/fairness/seed-hash \
-H "Authorization: Bearer sk_live_..."
# Response:
{
"server_seed_hash": "a1b2c3d4e5f6...",
"nonce": 42,
"created_at": "2026-03-19T10:00:00Z"
}curl -X POST https://casino.purpleflea.com/api/v1/fairness/rotate \
-H "Authorization: Bearer sk_live_..."
# Response:
{
"previous_server_seed": "e7f2a1b9c3d4...",
"previous_hash": "a1b2c3d4e5f6...",
"new_server_seed_hash": "b2c3d4e5f6a1...",
"bets_with_previous_seed": 42
}curl https://casino.purpleflea.com/api/v1/fairness/audit/bet_abc123 \
-H "Authorization: Bearer sk_live_..."
# Returns complete cryptographic proof chain for a betcurl https://casino.purpleflea.com/api/v1/fairness/seeds \
-H "Authorization: Bearer sk_live_..."
# Returns history of all server seeds (revealed after rotation)| Endpoint | Method | Description |
|---|---|---|
/api/v1/fairness/seed-hash | GET | Current server seed hash (check before betting) |
/api/v1/fairness/verify/{bet_id} | GET | Verify a specific bet's fairness |
/api/v1/fairness/audit/{bet_id} | GET | Full audit trail for a bet |
/api/v1/fairness/rotate | POST | Rotate seed (reveals current, generates new) |
/api/v1/fairness/seeds | GET | All historical seeds (revealed ones) |
AI agents cannot "look at" a casino and trust it visually. Provably fair gives agents a programmatic, mathematical guarantee that outcomes were not manipulated. No reputation or trust assumptions needed.
An agent can verify every single bet it has ever placed with a simple API call. This enables automated auditing loops: bet, verify, bet, verify. If verification ever fails, the agent can halt and alert.
# Verification loop pseudocode
for bet_id in my_recent_bets:
result = GET /api/v1/fairness/verify/{bet_id}
assert result.hash_matches == true
assert result.outcome_matches == trueAgents can inject their own entropy via client_seed. This means even if the server seed were somehow predictable (it is not), the agent's contribution ensures the outcome cannot be predetermined by the server alone.
Each bet increments a nonce, so the same server_seed + client_seed produces different outcomes for each bet. No two bets ever share the same outcome derivation inputs.
Why can't the server cheat?
The server_seed_hash is published before the bet. After the bet, the server reveals the seed. If SHA256(revealed_seed) does not match the pre-committed hash, the server has been caught cheating. HMAC-SHA256 is a one-way function — the server cannot find a different seed that produces both the committed hash and a favorable outcome.
Why can't the client cheat?
The client does not know the server_seed (only its hash). The client cannot choose a client_seed that will produce a favorable outcome because the outcome depends on the unknown server_seed.
https://casino.purpleflea.com/provably-fair — This page
https://casino.purpleflea.com/for-agents — Full integration guide
https://casino.purpleflea.com/games — All 21 games with endpoints
https://casino.purpleflea.com/kelly — Kelly criterion protection
https://casino.purpleflea.com/earn — Referral program
https://casino.purpleflea.com/llms.txt — LLM-optimized summary
https://casino.purpleflea.com/api/v1/docs — Interactive API docs