Prove your draw is fair without trusting a third party

For fifteen years, the engineer behind UVS built casino systems and slot machines. But one day, they noticed a critical flaw in how gambling software is certified: the certification process often feels like a box-ticking exercise. Labs review static documents, issue paper certificates, and the real-time systems keep running—with no one checking whether the certified algorithm still matches the live code. This disconnect exists beyond casinos: lotteries, gacha banners, school admissions, and event ticket raffles all suffer from the same vulnerability. They display a badge labeled "Provably Fair," point to a public seed and hash, and assume fairness is proven—even though almost no one verifies it.

Enter UVS (Uncloned Verification Standard), a framework designed to shift fairness proofs from opaque certificates to public recomputation. Instead of asking users to trust a badge or a lab, UVS lets anyone run the same verification process and confirm the outcome independently. The system is built around a core function called deriveTier, which assigns a draw a trust tier based on evidence, not promises.

Trust isn’t claimed—it’s derived from evidence

The deriveTier function evaluates the evidence attached to a draw and assigns one of three trust tiers:

• 🔴 — No anchor. The operator provides only a bare server seed without any commitment mechanism.
• 🟡 — Weak or unverified anchor. Notaries, self-anchors, or beacon bindings exist, but they lack proof that the commitment was created before the randomness was revealed.
• 🟢 — Strong anchor. A neutral registry signs the commitment, or the system uses trail immutability (e.g., Bitcoin timestamps) with a proven commitment.

The tier is determined by code, not by a badge or a promise. If there’s no verifiable evidence, the system flags the draw as untrusted—no green checkmark, no false sense of security.

What UVS actually proves—and what it doesn’t

UVS guarantees that the published rules were followed using the published inputs and randomness. It does not, however, verify the honesty of those inputs. An operator could still fabricate phantom entries, alter prize pools, or misrepresent the terms of a draw. UVS secures one specific link: the outcome. Everything upstream—input integrity, KYC checks, licensing—remains the operator’s responsibility. The standard makes that limitation clear to avoid overselling its capabilities.

Two verification paths for different randomness mechanisms

UVS splits verification into two branches, each tailored to how randomness is generated and consumed.

uvLottery: Ensuring fairness in draws and gacha

In lotteries and gacha systems, a single seeded permutation determines the outcome. The process combines a server seed with public, time-based randomness from a drand network (which releases randomness every 3 seconds). The combined seed is hashed with each participant’s ID to generate a unique score. The system sorts participants by score (descending, with tiebreakers) and assigns prizes top-down.

combinedSeed = SHA256(serverSeed + drandRandomness)
score(id) = SHA256(combinedSeed + id)

This ensures the same inputs always produce the same sorted list, regardless of the machine or programming language used. To prevent operators from manipulating the randomness by choosing favorable seeds, UVS ties the outcome to a drand round that doesn’t exist yet at the time of commitment. The round is derived from the timestamp of the commitment using a deterministic function:

round = floor((current_time − genesis_time) / 3) + 1  # quicknet genesis = 1692803367

Achieving the highest trust tier (🟢) requires an additional safeguard: a commitment anchor. The operator timestamps the commitment hash at two independent RFC-3161 Time-Stamp Authority (TSA) services (e.g., FreeTSA and DigiCert in different jurisdictions). The drand round used for the draw is then derived strictly after the timestamp, ensuring the operator cannot influence the round selection. Verification involves re-deriving the round, recomputing the permutation, and confirming the outcome matches the public record.

openssl ts -verify -digest <commitmentHash> -in token.tsr -CAfile <ca>

While TSAs are technically third parties, their neutrality and dual-jurisdiction setup make collusion implausible. The entire chain is publicly re-derivable: fetch the randomness, recompute the permutation, and verify the timestamp. The system asks for no trust—only the willingness to recompute.

uvGame: Handling interactive and physics-based outcomes

Interactive games, such as physics-based simulations, rely on real-time player input alongside a committed server seed. Because external beacons like drand cannot anchor the outcome in real time, achieving 🟢 is impossible by design. Instead, UVS caps the trust tier at 🟡 for these systems. The verification process focuses on deterministic replay: using the input log, the system replays the game logic to confirm the outcome matches the public record. This ensures the game followed the published rules but does not guarantee input integrity.

The "Uncloned" layer: Code that can’t be pre-baked

The name "Uncloned" refers to a key innovation in UVS: each verification session generates a unique WASM (WebAssembly) module in the user’s browser. The registrar provides a regSeed, which seeds a deterministic algorithm to generate a one-of-a-kind arithmetic circuit. This circuit cannot be pre-baked or stubbed because it is generated dynamically from the seed.

function buildWasm(regSeed):
    lcg = new LCG(regSeed)
    n = lcg.range(4, 7)  # 4 to 7 arithmetic steps
    steps = []
    for _ in range(n):
        steps.append({
            shiftOp: SHIFT_OPS[lcg.range(0, len(SHIFT_OPS))],
            shiftAmt: 8 + lcg.range(0, 8),
            binOp: BINARY_OPS[lcg.range(0, len(BINARY_OPS))],
            constVal: (lcg.next() | 1) | 0,
        })
    # Emit WASM sections in LEB128 format
    return { bytes: new Uint8Array([0x00, 0x61, 0x73, 0x6d, ...]) }

The client instantiates this module, runs a function like compute, and receives a wasmResult. The registrar performs the same computation using its own regSeed and compares the result. Because the circuit is unique per session and derived from the seed, tampering is impossible without running the exact arithmetic sequence the registrar emitted. This eliminates the risk of pre-baked verification engines or stubbed logic.

After a session, the player’s final game record is notarized at the same dual RFC-3161 TSAs, creating an immutable ledger. The system labels this as 🟡. A path to 🟢 using OpenTimestamps and Bitcoin trail immutability is available but not enabled by default.

Architecture: A streamlined verification system

UVS’s backend runs in a Docker container on Render, hosting both the game registrar and anchored draws. The system exposes endpoints like /commit, /draw, and /anchor, but its core value lies in the transparency of its verification logic. The reference implementations—available in JavaScript, Python, Java, and C++—are designed for draw verification. For interactive games, deterministic replay logs validate outcomes.

The framework’s strength lies in its refusal to rely on blind trust. Whether it’s a lottery draw, gacha banner, or physics-based game, UVS ensures fairness isn’t just claimed—it’s publicly verifiable.