There is a lot of advantages of blockchain technology but its transparency, combined with the deterministic nature of computers is a stumbling block in creating true on-chain randomness. Yet, random number generators (RNGs) are essential tools for solving various algorithmic problems. Here we will discuss the approach Oasis has adopted to ensure smart contract developers can integrate randomness into their applications in a hassle-free manner. What is RNG As deterministic machines, computers function by following predictable instructions. So, randomness is never truly possible. However, almost random numbers can be generated with external inputs or complex algorithms. But how feasible is this? Not very. For example, a deterministic RNG can only mimic randomness and produce pseudo-random outputs using algorithms transforming a starting “seed” value into sequences. If the “seed” is known, it all becomes predictable. On the other hand, non-deterministic RNG can generate completely random numbers by using erratic physical phenomena, like dice rolls or photon scattering, as a workaround for the computer reading predictable patterns. Why blockchains need RNG? When you try to replicate RNG in the smart contract framework, it gets interesting. Whether you are developing dApps for the web3 at large or the cryptoAI space, you will need provable fairness or unbiased and tamperproof outcomes based on unpredictable inputs. Even from a core blockchain point of view, RNG plays a crucial role in cryptographic operations. It produces the unique keys or values needed for securing transactions, encrypting data, or authenticating users, ensuring that outputs cannot be guessed or replicated. Without secure on-chain RNG, reverse engineering of keys, outcome manipulation and all kinds of exploits become possible. Now, blockchain technology also use deterministic rules, and all nodes reaching a consensus is a non-negotiable criteria. This makes on-chain randomness tricky but it is still doable. For example, verifiable random functions, commit-reveal schemes, or the method Oasis has adopted — using Verifiable Random Function (VRF) and some other cryptographic primitives. Let’s now take a closer look into Oasis. How Oasis RNG works? With its default focus on smart privacy and scalability, Oasis uses its confidential EVM runtime, Sapphire to streamline RNG through its randomBytes precompile. By abstracting a simple Solidity function, any smart contract developer can integrate randomness into their applications without dealing with the complexities of blockchain RNG. It basically works like this. Generating the Per-Block Root RNG Sapphire communicates with a key manager runtime to generate secret keys. The key manager supports multiple kinds of keys, some of which are long-term and some of which are ephemeral. The ephemeral keys are used for encrypting transactions and also the RNG. To improve security, these keys are never persisted anywhere and are rotated each epoch. This means fresh keys are generated, and after a while, old keys get securely erased and cannot be recovered even if any component is later compromised. The RNG exposed to Sapphire contracts is initialized on every block. Each block uses private ephemeral entropy obtained from the key manager runtime. Only remotely attested Sapphire instances can obtain this private entropy inside the TEE, which ensures that no external observers can learn anything about the RNG state. Next, this entropy is processed and used as a root VRF key. To turn this entropy into a usable key, Sapphire employs SHA-3-derived algorithms like TupleHash, KMAC256, and cSHAKE. These functions process the epoch-specific entropy from the key manager runtime, producing a unique per-block root RNG that anchors all subsequent randomness in the block with consistency and security. Domain Separation for Per-Transaction RNGs The per-block root RNG alone isn’t enough. Each transaction needs its own private RNG, which is where domain separation comes in. Sapphire builds on the key manager’s output by using Merlin transcripts to initialize per-transaction RNGs from the root RNG, customizing randomness for individual interactions using transaction-specific data. This customization is implemented in the Rust Runtime SDK used to build Sapphire, which handles the VRF and domain separation schemes. Together with the key manager’s private entropy, it ensures private, unbiased, and unpredictable outputs are exposed to developers via the randomBytes precompile. Code examples Basic Random Number Generation This snippet shows how to generate a 32-byte random value, ideal for straightforward RNG needs in a dApp like a poker game. bytes memory randomPad = Sapphire.randomBytes(32, ""); Random Number for Signing Key Pair This snippet uses randomBytes to seed a signing key pair generation, which you can use as a part of a more complex RNG-driven mechanism while ensuring cryptographic security. Sapphire.SigningAlg alg = Sapphire.SigningAlg.Ed25519Pure;bytes memory pk;bytes memory sk;(pk, sk) = Sapphire.generateSigningKeyPair(alg, Sapphire.randomBytes(32, "")); Key Resources: Sapphire docsSapphire repositoryrandomBytesOasis ROFLOasis playground for demo dApps Have a question or need help? Join our Discord and head over to the #dev-central channel. Originally published at https://dev.to on September 22, 2025. Secure On-chain Randomness By Oasis Is A Great Way To Answer The Blockchain Need For RNG was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this storyThere is a lot of advantages of blockchain technology but its transparency, combined with the deterministic nature of computers is a stumbling block in creating true on-chain randomness. Yet, random number generators (RNGs) are essential tools for solving various algorithmic problems. Here we will discuss the approach Oasis has adopted to ensure smart contract developers can integrate randomness into their applications in a hassle-free manner. What is RNG As deterministic machines, computers function by following predictable instructions. So, randomness is never truly possible. However, almost random numbers can be generated with external inputs or complex algorithms. But how feasible is this? Not very. For example, a deterministic RNG can only mimic randomness and produce pseudo-random outputs using algorithms transforming a starting “seed” value into sequences. If the “seed” is known, it all becomes predictable. On the other hand, non-deterministic RNG can generate completely random numbers by using erratic physical phenomena, like dice rolls or photon scattering, as a workaround for the computer reading predictable patterns. Why blockchains need RNG? When you try to replicate RNG in the smart contract framework, it gets interesting. Whether you are developing dApps for the web3 at large or the cryptoAI space, you will need provable fairness or unbiased and tamperproof outcomes based on unpredictable inputs. Even from a core blockchain point of view, RNG plays a crucial role in cryptographic operations. It produces the unique keys or values needed for securing transactions, encrypting data, or authenticating users, ensuring that outputs cannot be guessed or replicated. Without secure on-chain RNG, reverse engineering of keys, outcome manipulation and all kinds of exploits become possible. Now, blockchain technology also use deterministic rules, and all nodes reaching a consensus is a non-negotiable criteria. This makes on-chain randomness tricky but it is still doable. For example, verifiable random functions, commit-reveal schemes, or the method Oasis has adopted — using Verifiable Random Function (VRF) and some other cryptographic primitives. Let’s now take a closer look into Oasis. How Oasis RNG works? With its default focus on smart privacy and scalability, Oasis uses its confidential EVM runtime, Sapphire to streamline RNG through its randomBytes precompile. By abstracting a simple Solidity function, any smart contract developer can integrate randomness into their applications without dealing with the complexities of blockchain RNG. It basically works like this. Generating the Per-Block Root RNG Sapphire communicates with a key manager runtime to generate secret keys. The key manager supports multiple kinds of keys, some of which are long-term and some of which are ephemeral. The ephemeral keys are used for encrypting transactions and also the RNG. To improve security, these keys are never persisted anywhere and are rotated each epoch. This means fresh keys are generated, and after a while, old keys get securely erased and cannot be recovered even if any component is later compromised. The RNG exposed to Sapphire contracts is initialized on every block. Each block uses private ephemeral entropy obtained from the key manager runtime. Only remotely attested Sapphire instances can obtain this private entropy inside the TEE, which ensures that no external observers can learn anything about the RNG state. Next, this entropy is processed and used as a root VRF key. To turn this entropy into a usable key, Sapphire employs SHA-3-derived algorithms like TupleHash, KMAC256, and cSHAKE. These functions process the epoch-specific entropy from the key manager runtime, producing a unique per-block root RNG that anchors all subsequent randomness in the block with consistency and security. Domain Separation for Per-Transaction RNGs The per-block root RNG alone isn’t enough. Each transaction needs its own private RNG, which is where domain separation comes in. Sapphire builds on the key manager’s output by using Merlin transcripts to initialize per-transaction RNGs from the root RNG, customizing randomness for individual interactions using transaction-specific data. This customization is implemented in the Rust Runtime SDK used to build Sapphire, which handles the VRF and domain separation schemes. Together with the key manager’s private entropy, it ensures private, unbiased, and unpredictable outputs are exposed to developers via the randomBytes precompile. Code examples Basic Random Number Generation This snippet shows how to generate a 32-byte random value, ideal for straightforward RNG needs in a dApp like a poker game. bytes memory randomPad = Sapphire.randomBytes(32, ""); Random Number for Signing Key Pair This snippet uses randomBytes to seed a signing key pair generation, which you can use as a part of a more complex RNG-driven mechanism while ensuring cryptographic security. Sapphire.SigningAlg alg = Sapphire.SigningAlg.Ed25519Pure;bytes memory pk;bytes memory sk;(pk, sk) = Sapphire.generateSigningKeyPair(alg, Sapphire.randomBytes(32, "")); Key Resources: Sapphire docsSapphire repositoryrandomBytesOasis ROFLOasis playground for demo dApps Have a question or need help? Join our Discord and head over to the #dev-central channel. Originally published at https://dev.to on September 22, 2025. Secure On-chain Randomness By Oasis Is A Great Way To Answer The Blockchain Need For RNG was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story

bytes memory randomPad = Sapphire.randomBytes(32, "");

Sapphire.SigningAlg alg = Sapphire.SigningAlg.Ed25519Pure;
bytes memory pk;
bytes memory sk;
(pk, sk) = Sapphire.generateSigningKeyPair(alg, Sapphire.randomBytes(32, ""));

Copy linkX (Twitter)LinkedInFacebookEmail