The BOG RNG V2 allows smart contracts to get randomness on-chain in a verifiably secure fashion.

Hashes of the pending numbers are stored in the RNG contract and assigned to randomness requests in the initial call. The oracle will then callback the requesting contract with the random number which is verified against the stored hash to ensure the random number provided has not been tampered with based on the nature of the request.

This is a simple but secure method of providing random numbers on-chain which allows developers to easily integrate it into their project instead of trying to roll their own solution

The RNG oracle can take fees in either BOG or BNB, the base amount of callback gas available is 200K however this is fully customizable by the developers by sending additional BNB with the request which can allow for complex operations to be executed in the RNG callbacks.


Our RNG fees are pegged to fiat amounts to ensure you do not pay more if the token you are paying with increases in price.

We take payment for the fees in either BOG or BNB.

BOG is the preferred payment method and is cheaper so this will be better for developers who expect to have high volume usage.

We also accept payment in BNB which is useful for if each user interaction requires a call to our oracle so that their interaction can be processed without requiring them to purchase or hold BOG. The example lower down the page shows an example of a direct end-user interaction with the oracle where they directly pay the RNG fee in BNB.


Token Amount

Fiat Amount







BOG fees will be transferred out of the calling contract by the RNG oracle so please ensure the contract is funded & has given an approval for the RNG contract to spend the fees. There are methods available on the RNG contract for determining the amount of BNB needed to be sent with a request pair for in BNB.


RNG callbacks allow for up to 200K of gas to be consumed by your contract. If you require more than this you can send BNB with your randomness request equal to the amount of extra gas you require.

For example: requestRandomness{value: EXTRA_GAS}();

The callback gas price is set at 5 Gwei so for an extra 100K of callback gas you will need to send 500K Gwei with your request.

RNG Oracle


The Mainnet RNG uses a polling rate of < 1 second so you can expect almost instant callbacks, whereas the Testnet RNG uses a polling rate of ~60 seconds as we do not run our own testnet node so callback times are increased.





BSC Testnet



The BSC Testnet Oracle can take fees in either BNB or Testnet BOG

Testnet fees are fixed at either 0.01 Testnet BOG or 0.01 BNB.

You may mint Testnet BOG to yourself using the BscScan link below.

Please note gas costs for transferring Testnet BOG may differ to Mainnet BOG as mainnet transactions also power other contracts such as the price oracle used for determining RNG fees.



Example Implementation

CoinFlip: Contract

This is an example implementation of a coin flip game where the user submits a transaction to the contract with a 50% chance of losing their wager and a 50% chance of winning double their wager.

The coin flips are stored in a mapping to the hash they were assigned when requesting randomness from the oracle.

The receiveRandomness(...) callback function processes the result of the coinflip with the corresponding hash.

Storing each coinflip separately using the RNG hash as a unique identifier means it is possible to make the contract non blocking, eg. no need to lock up the contract when waiting for the randomness callback as many users can use it at once and all be guaranteed a uniquely fair result.


CoinFlip: Frontend web3

This example shows how to submit a flipCoin() transaction with enough BNB to cover the RNG fees. The BNB fee allows for a small amount of price slippage to prevent transactions failing due to a change in the price of BNB.


Security Considerations for Verifiable Randomness

  • You MUST check that the random number is ONLY being provided from the RNG oracle contract.
  • Once the randomness has been requested by your contract you should not allow any other interactions that may be able to change the outcome. For example if a random number is requested to determine the winner of a lottery, no more tickets should be able to be bought until after the random number has been provided back to the contract.
  • If multiple random numbers may be requested by your contract you must ensure your contract can not be exploited by miners who alter the order of the random number callback transactions. Please use the hash returned by the requestRandomness() functions to allow each request to be processed in a standalone / unique manner.
  • You may consider using the random number provided along with other data to produce a hash used for randomness as this will add another layer of security. You can use the getRequestBlock() to get the blockhash of a block after the initial request to use as another seed for example.