On-Chain Randomness Generation

On-chain randomness generation is a critical primitive for DeFi protocols, gaming applications, and NFT minting platforms on Tezos. The protocol provides a native RANDOM opcode in Michelson, but its security properties are fundamentally limited by the baker's ability to censor or selectively include operations that produce unfavorable outcomes. Builders must understand that RANDOM alone is not a secure source of randomness for high-value applications; it is a commitment to a future random seed that a block proposer can observe before deciding whether to include a transaction.

The standard mitigation pattern on Tezos is a commit-reveal scheme, where a user commits to a future action by submitting a hash, waits for the RANDOM seed to be fixed in a subsequent block, and then reveals their action. This two-phase approach prevents last-second manipulation by ensuring the random outcome is bound to a seed that was unknown at the time of commitment. However, the security of this pattern degrades if the economic value of manipulation exceeds the baker's block reward and bond, or if the reveal phase is not enforced with timeouts and penalties. Developers must also account for the RANDOM opcode's behavior across protocol upgrades, as changes to the seed generation mechanism could alter the distribution or predictability of values.

For teams building lotteries, randomized airdrops, or on-chain games, a security review of the randomness implementation is essential. Chainscore Labs can assess the commit-reveal lifecycle for front-running vulnerabilities, verify timeout and penalty logic, and model the economic incentives for baker manipulation at various value thresholds. This analysis extends to integration risks for wallets and indexers that must correctly parse and display the two-phase state machine to users.

Tezos provides a dedicated RANDOM opcode in Michelson that generates a pseudo-random byte sequence within a smart contract's execution context. The opcode consumes a seed, a number of bytes, and the current level from the stack, and produces a deterministic sequence of bytes. The critical security property is that the generated value is deterministic given the same inputs and context, meaning its entropy is entirely dependent on the seed provided by the caller. A naive implementation where a user submits a seed in the same operation that consumes the randomness is trivially exploitable, as a baker can reorder transactions, censor unfavorable seeds, or simulate the outcome before deciding to include the operation.

The standard mitigation for this manipulation vector is a commit-reveal scheme, which decouples the seed submission from the randomness consumption across two distinct phases. In the commit phase, a participant submits a hash of a secret seed, locking in their future randomness contribution without revealing it. The contract records this commitment alongside the block level. In the reveal phase, typically enforced after a minimum number of blocks have elapsed, the participant submits the original secret. The contract verifies it against the stored hash and then uses it as the seed for the RANDOM opcode. This temporal separation prevents bakers from simulating the outcome during the commit phase because the secret is unknown, and it prevents them from censoring the reveal phase without forfeiting the opportunity, as the commitment is already on-chain.

Despite the commit-reveal pattern, residual risks remain. A baker can still censor the reveal operation if the economic value of doing so exceeds the cost of the forfeited commitment. For high-value applications, developers must carefully calibrate the timeout window and the economic stake required during the commit phase. Additionally, the RANDOM opcode itself is not a source of cryptographic entropy; it is a deterministic pseudo-random generator. The security of the entire scheme collapses if the secret is guessable or if the same seed is reused. Teams implementing on-chain randomness for lotteries, gaming, or DeFi protocols should subject their specific commit-reveal implementation and parameter choices to a dedicated security review to ensure the manipulation cost is appropriately calibrated for the value at stake.