RNG V1 (Legacy)

Legacy Warning

BOG RNG V1 has been superceded by BOG RNG V2. Lifetime support will be available for this version however we urge all new projects to use the the more economical and powerful V2 RNG. Read the new docs here:BOG RNG V2


BogRNG allows applications to get Randomness On-Chain in a verifiably secure fashion. A hash is stored in the Oracle contract of the next random number to be provided so that it can be checked by the contract receiving the random number to ensure the random number provided has not been changed 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.


Currently the Oracle charges a flat fee of 0.25 BOG per request, this will be modified in the future to be pegged to a constant dollar amount using our Oracles once the price of BOG increases.

Please also see the note at the bottom - we are offering free credit to early adopters of our Oracle.

Random Oracle


To get a random number your contract should call requestRandomness on the oracle.

Your contract should implement the IReceivesBogRand interface - the receiveRandomness function will be called back by the Oracle in a separate transaction once your contract has made a request and will provide you with the random number. This function must not consume more than 200K of gas.

BogRNG Address: 0x3886F3f047ec3914E12b5732222603f7E962f5Eb

Example Implementation


Security Considerations for Verifiable Randomness

  • You MUST check that the random number is ONLY being provided from the oracle contract. See the above example for an implementation of this.
  • Once the randomness has been requested by your contract you should not allow any other interactions that may be able to change the outcome as this could allow miners to exploit your contract. 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 - one possible solution to this is to only allow one random number to be requested at a time.
  • 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 if you are concerned about the rng source. An example of this would be hashing together the address of the last ticket buyer for a lottery with the provided random number.