Blockchain Randomness Websites

random numbers on web 3 : randomizer vs chainlink vs api3 what rng or vrf service for randomness in smart contracts should you use ? current rng solutions if you want random numbers in your solidity smart contract , you may have considered one of the following solutions : blockhash using block data like a combination of the last block ’s hash with the current block difficulty is an easy way to get a number that ’s random but   predictable . a miner can simply not include a specific transaction until the “ random ” number benefits them . to make this method less predictable , you can have the user “ lock in ” their request by having them call the function first , and then utilize a future block ’s data ( or the next round ’s “ prevrandao ” value ) after the transaction is made ( e . g .   n + 10   where   n   is the block height of the user transaction ’s block ) . this is more secure but requires a specific future block ’s data ( e . g . the 10th block after the request ) . so you need wait until the future block is mined , then call a callback function that ’s called within 255 blocks from when the request is made , otherwise the future block ’s data is no longer available from within the smart contract . randao on ethereum pos since ethereum pos you can get relatively unpredictable pseudo - random numbers by requesting the next   randao   value . this is a reliable source of randomness : it ’s very difficult for nodes to influence a future randao value , but it also takes a minimum of 6 minutes to generate ( the higher the delay the more secure the number ) . pros unpredictable for users . native on ethereum pos . cons usage limited to the ethereum network . other evm - based l1 and l2 networks may not support randao , creating “ blockchain lock - in ” for your smart contract . need to integrate callbacks yourself . like when using a future blockhash , a smart contract function needs to be called to store or use the future randao value once it ’s available . manipulatable : an attacker could simply wait for a “ randao ” value that benefits them and only trigger it then . chainlink vrf a third - party solution is chainlink verifiable random numbers . the process is as follows : a developer creates a subscription account in the chainlink vrf contract for their contract ’s address and funds it with link tokens . when a user calls the contract , the contract requests randomness from the chainlink vrf contract . chainlink oracles generate random values with the method of generation verified on - chain , ensuring the random values could not have been tampered with by any party . chainlink ’s coordinator contract calls your contract ’s callback function with the random values . pros your contract ’s callback function is called automatically when the random value is available . used by many projects   e.g. for nft trait generation . cons most expensive   out of all available solutions on ethereum : at times during 2021/2022 a single request could cost up to $ 85 usd   ( $ 35 request , $ 4 . 45 premium , $ 40 fulfillment ) . developers need to fund a subscription account with link tokens which adds extra complexity and gas fees if you want to fund it with eth ( i . e . route in - contract dex calls ) . gas fees converted to link ( plus a static fee of currently 0.25 link ) makes the cost of a single request fluctuate with the price of link . if your subscription account runs out of link then your contract stops working until it ’s funded again . currently only a few networks are supported ( ethereum , polygon , bnb chain ) . chainlink is not keeping things simple . it ’s generally unclear how the chainlink protocol works , shown by   this recent thread   about how code reviewers had to dive into the contracts to show that chainlink ’s price oracles are simply a 3/20 multisig :   “ if 3 of these 20 keys are compromised in any way ( hack , regulatory attack , etc ) , defi could experience an unprecedented black swan and suffer irreversible destruction . ” currently unavailable on layer 2 as the protocol is partly secured by the gas limit of ethereum blocks , which arbitrum for example does not have . api3 qrng a centralized “ quantum - powered ” random number generator service offered by api3 in partnership with the australian national university . pros no premium fees : this service is built to   “ give back ”   to the web3 industry , so developers are expected to only pay for gas fees . cons centralized : the service is a smart contract that accepts any input sent to it from the owner wallet . “ just trust us , bro ” : you   have to trust   that the numbers are random . there is   no on - chain proof that the values are random   or unpredictable . the only source of reliability is that the node ( sourcing the random values ) is operated by the australian national university . if a bad actor gains access to the private key of the node , it ’s over . one party has   full control   over your deposit : to pay for the randomness fees you have to send eth to a “ sponsor wallet ” . the “ qrng node ” owns the private keys to these addresses , so they have   full control without restrictions over your deposit . in short : the api3 qrng is a fully centralized service where you have to trust a single party with not only the “ random ” values being sent to your contract , but also with your deposited funds . none of these solutions met our needs , so we built … randomizer : a simple and effective solution randomizer . ai   is a new rng solution built on solidity , out now on arbitrum one . randomizer sends verifiably unpredictable bytes to requesting contracts on any l1 or l2 chain , using eth for settlement . you don’t need to mess with other tokens to pay for randomness . simply deposit eth to randomizer ’s contract ( you can also have the end user pay for it within a function ) , and receive a callback with random bytes in seconds ! the method is as follows : a developer calls the   client deposit ( )   function in the randomizer contract along with some eth and their contract address . their smart contract requests a random number to randomizer , to be signed by   3   beacons . 2 beacons are pseudo - randomly selected , sign the request ’s unique data , and then send their vrf response to the randomizer contract . vrf responses are verified using on - chain elliptic curve cryptography to guarantee there has been no possible tampering . the   contract uses both submitted vrf hashes and the blockhash of the request ( unknown at request time ) as a new random seed to select the final beacon . this ensures that the final submitter beacon is not known at request time . the final beacon submits its vrf hash which is also verified on - chain . randomizer ’s smart contract then combines all signatures in the order that the beacons were selected and generates the final random bytes . the requesting contract ’s   randomizer callback ( id , value )   function is called by randomizer ’s contract , with the request id and random bytes . the contract can now do anything it wants with the random value . with on - chain validation , the values cannot be tampered with . the result value is unpredictable to the user and smart contract . features values are verified on - chain ( i . e . vrf ) , making the result tamper - proof . fast and cheap on ethereum layer 2 ( now on arbitrum one mainnet ) . native eth payments . developers can even have users pay for the random number generation . real - time results in your front - end , even before the result is included in a block with randomizer ’s real - time module . decentralized : you don’t need to trust any centralized party to not tamper with your values , and fee transfers are handled within randomizer ’s smart contract , so you ’re never overpaying . randomizer will become a dao in the future with its own unique governance nft .