<p>Have you checked <code>genSeed</code> function from <a href="https://input-output-hk.github.io/ouroboros-network/cardano-crypto-praos/Cardano-Crypto-VRF-Praos.html#v:genSeed" rel="nofollow noreferrer"><code>Cardano.Crypto.VRF.Praos</code></a> module?</p>
<p>This module is the Haskell implementation of <a href="https://github.com/input-output-hk/libsodium" rel="nofollow noreferrer"><code>libsodium</code></a>, the library used by Algorand and Cardano to generate Verifiable Random Functions (VRF), which are key at the time of randomly choosing validators in both chains.</p>

CC BY-SA 4.0
2022-06-01T09:00:49.930Z
I don't think this can be compiled to Plutus in on-chain code
Mateus
CC BY-SA 4.0
2022-06-01T10:19:25.727Z
Can you please explain the reason? I'm just starting with Plutus and I understand that all Haskell code can be compiled to Plutus.
Falcon Stakepool
CC BY-SA 4.0
2022-06-01T13:49:38.203Z
Not all Haskell code, we have some [builtins](https://playground.plutus.iohkdev.io/doc/haddock/plutus-tx/html/PlutusTx-Builtins.html) and only they can be used inside validators. So you wound't be able to use any haskell function at all since they don't use those builtins, but we can use the plutus prelude which contains a bunch of equivalent functions
Mateus
CC BY-SA 4.0
2022-06-01T21:03:46.570Z
Thanks for clarifying!
Falcon Stakepool
CC BY-SA 4.0
2022-06-01T06:28:51.927Z
2022-06-01T06:28:51.927Z
Falcon Stakepool
<p>For The Open Source Cardano Lottery, I have created a pseudo random number onchain validator that uses parts of a tx id for the source of a random number.  I am open to any feedback on this approach, but from what I have tested, I can't guess what the winner lotto ticket number will be in advance :)</p>
<p><a href="https://github.com/lley154/cardano-lottery" rel="nofollow noreferrer">https://github.com/lley154/cardano-lottery</a></p>

CC BY-SA 4.0
2022-06-01T09:00:09.583Z
But I guess you could "select" the result, since you you can use any of the N UTxOs you have and each UTxO has a different tx id
Mateus
CC BY-SA 4.0
2022-06-01T13:39:15.713Z
To clarify @Mateus, the lottery number is chosen by players before the final close tx is created.  Only after the window to choose a winning number is closed is another transaction created that is used to derive the winning numbers.   So someone would have to predict in advance what a tx id will be - which I believe is not possible.
lley154
CC BY-SA 4.0
2022-06-01T13:41:21.177Z
I see, so the tx id of the script it self is used?
Mateus
CC BY-SA 4.0
2022-06-01T13:50:29.527Z
yes, but only after the window to choose a winning number is closed.   I created a state machine smart contract that ensures that only when the lotto is in the correct state that a winning number can be chosen from a UTXO (that must inclue the lottery thread token).
lley154
CC BY-SA 4.0
2022-06-01T20:52:54.813Z
It is not possible to generate random numbers on-chain. In your lottery, you set the winner with the closing transaction. The party doing this will inevitably have the power to chose the winner freely. There is no way to effectively prevent this. using the tx-id does not help. You can fine-tune your UTxO to get the tx-id you need.
Jey
CC BY-SA 4.0
2022-06-02T13:59:53.253Z
Hi Jey, thanks for your feedback!   The lottery uses a state machine which transitions from a state that players can buy a ticket to a state that players cannot buy a ticket.  It is during this "player can't buy a lottery ticket" that a transaction is created by the lotto admin to draw the winning number.   The winning number is derived by the transaction id locked at the lotto script address which was created by transitioning the to "player can't buy" state.   By using a thread token design pattern, only the lotto admin and only during the proper state can a specific UTXO be used .
lley154
CC BY-SA 4.0
2022-06-02T20:29:19.663Z
Hi lley154, what mechanism do you think prevents the lottery admin to pick the winning number freely (i.e. setting the tx-id of his choice when transitioning to the state "player can't buy") ?
Jey
CC BY-SA 4.0
2022-06-03T00:15:16.237Z
Hi Jey,  in order to submit the close transaction, the UTXO must contain the thread token.  So, this prevents the lotto admin from choosing any arbitrary UTXO.  This thread token can only be spent (and then be part of a UTXO) after the lotto numbers have been chosen.   I really need to write up a diagram on this, but really appreciate the questions to see if there are any holes.  I created a youtube video of going throug the lottery process, but not sure (and don't expect) if you'll have time to look at that.  https://www.youtube.com/watch?v=q55nU9mwZYg&t=105s
lley154
CC BY-SA 4.0
2022-06-03T07:39:59.217Z
I quickly went over the video. You draw your winner from the tx-id. You treat your tx-id as if it was a source of randomness. But it is not. Maybe explain why you think that your lottery has the following 2 properties: i) the party behind the admin cannot steel the pot (through a combination of acting as admin and as a buyer), ii) the winner ticket is not known in advance (i.e. cannot be computed by looking at the blockchain).
Jey
CC BY-SA 4.0
2022-06-06T21:14:09.333Z
Hi @Jey,  I realized that the tx-id is not a true random number, but I thought it might be sufficiently difficult to predict it several transactions out.  But after doing some more testing, you are correct and it is possible to predict each transaction in advance until you get to the close transaction. There is also nothing to stop the lotto admin from being a player, but this is by design, so the crux of the issue is to make the winning number truly random.  Looks like I will look at using an oracle to salt the winning number selection so it can’t be predicted in advance.  Thanks again!
lley154
CC BY-SA 4.0
2022-06-07T20:13:02.623Z
Hi @lley154, you're welcome. In a hobby project, I implemented a lottery that combined (i) a root number committed through a hash at creation by the lottery admin with (ii) a number (either 0 or 1) that every ticket holder could add to he oracle. Thus, the admin would need to buy the whole lottery to pick a ticket at choice. And a normal ticket holder cannot do more than pick at random because he does not know the root number. I'm not sure this approach has no holes, but it looked promising to me.
Jey
CC BY-SA 4.0
2022-06-09T15:48:17.703Z
Hi @Jey,  interesting approach and I like the idea that each ticket purchased provides entropy.  The only downside I see is that the oracle needs to be updated via ticket purchases and that it may be difficult to easily audit this openly.  Ideally it would be great if the oracle used some publicly known random value so at least there can be an open audit/review once the winning numbers are revealed.   This doesn't prevent the admin from rigging the system, but does allow everyone to know if the lottery was fair.   By using multisig there could be some checks and balances as well.
lley154
CC BY-SA 4.0
2022-06-13T02:37:35.450Z
Hi @Jey,  I just realized that if you require the number of tickets purchased be greater than the total amount of Ada locked in the lotto contract, this will disincentive the lotto admin from buying all of the lotto tickets.   If you also require ½ of all purchased tickets to be revealed, this prevents predicting the winning number as well.  So, I prefer your approach.  I have submitted a draft proposal in Fund 9, please message me on catalyst if you would like to be a co-proposer and we can discuss level of involvement if interested.  https://cardano.ideascale.com/c/idea/415197
lley154
CC BY-SA 4.0
2022-05-31T13:55:29.700Z
2022-05-31T13:55:29.700Z
lley154
<p>Getting randomness into smart contracts is a bit difficult on Cardano due to it's deterministic nature. In some cases, committment schemes can be used: <a href="https://www.youtube.com/watch?v=JXKf1JwVAOE" rel="nofollow noreferrer">https://www.youtube.com/watch?v=JXKf1JwVAOE</a> which rely on the one-way property of hash functions. In this example, it's applied to a game between two parties, which are real competitors, so neither of them wants to reveal their secret information to the other and the outcome is indeed random.
This doesn't work when the different parties might have some incentive to cooperate (e.g. against the operator)</p>
<p>One can also &quot;collect entropy&quot; from multiple parties as it was done here:
<a href="https://github.com/input-output-hk/lobster-challenge" rel="nofollow noreferrer">https://github.com/input-output-hk/lobster-challenge</a></p>
<p>One can use a RNG oracle, but still has to deal with the determinism. So even if it's a perfectly fair random number, the gambler might just decide not to play (=submit their tx) in case they would loose. Maybe one can overcome it with validity intervals for tx and penalties for not submitting a tx, but it has some obvious drawbacks.</p>

CC BY-SA 4.0
2022-06-01T22:34:53.457Z
2022-06-01T22:34:53.457Z
DaveStrider
<p>It depends on the use case, but <a href="https://nut.link/" rel="nofollow noreferrer">nut.link</a> has been submitting the League of Entropy randomness beacon.</p>

CC BY-SA 4.0
2021-12-31T23:13:47.327Z
2021-12-31T23:13:47.327Z
Marek Mahut - StakeNuts
<p>I would like to create a gambling Dapp and for this I need a provably fair RNG. What are the best solutions for provably fair randomness in Cardano</p>
<p>Will Cardano add Chainlink VRF in the future?</p>

CC BY-SA 4.0
2021-10-08T04:24:58.773Z
Thanks for asking a question @hanno! It is, though, on the edge of guidelines... 'wen' is almost never helpful question here. 

If you rephrase to ask about the best solutions for randomness in Cardano, I think it will add more value. (And people will be more likely to respond, as that is more in scope).

PS-- I'll answer about how to stay informed in discord :)
Matthew Capps
CC BY-SA 4.0
2021-10-08T04:26:42.350Z
Also, look into the ergo raffle dapp. I would assume they need verifiably fair randomness for that, and it's in EUTxO like Cardano.
Matthew Capps
CC BY-SA 4.0
2021-10-08T06:31:59.937Z
Ergo does not use a provably fair RNG
Hanno
CC BY-SA 4.0
2021-10-08T06:36:43.077Z
Thanks for updating @hanno, and checking out my (ultimately disappointing) reference. Upvoted your question!
Matthew Capps
CC BY-SA 4.0
2021-10-08T07:16:11.020Z
@MatthewCapps you are really great helper as you are trying hard to help. Great attitude
Ergo as I understood is taking randomness from the previous block header
Hanno
CC BY-SA 4.0
2021-10-22T06:42:58.513Z
as I did not get any answer to my question do I need to assume that there is no randomness solution for Cardano?
Hanno
<smart-contract><decentralized-applications>
What are the best solutions for randomness in Cardano?
# What are the best solutions for randomness in Cardano?

(Asked by: username_0 on 2021-10-05)

I would like to create a gambling Dapp and for this I need a provably fair RNG. What are the best solutions for provably fair randomness in Cardano

Will Cardano add Chainlink VRF in the future?

**Tags:** smart-contract, decentralized-applications
> **Comments:**
> **username_1**: Thanks for asking a question @hanno! It is, though, on the edge of guidelines... 'wen' is almost never helpful question here.   If you rephrase to ask about the best solutions for randomness in Cardano, I think it will add more value. (And people will be more likely to respond, as that is more in scope).  PS-- I'll answer about how to stay informed in discord :)  
> **username_1**: Also, look into the ergo raffle dapp. I would assume they need verifiably fair randomness for that, and it's in EUTxO like Cardano.  
> **username_0**: Ergo does not use a provably fair RNG  
> **username_1**: Thanks for updating @hanno, and checking out my (ultimately disappointing) reference. Upvoted your question!  
> **username_0**: @MatthewCapps you are really great helper as you are trying hard to help. Great attitude Ergo as I understood is taking randomness from the previous block header  
> **username_0**: as I did not get any answer to my question do I need to assume that there is no randomness solution for Cardano?  

---

## 4 answers

### Answer by username_2 on 2022-06-01. Score: 2

Have you checked `genSeed` function from [`Cardano.Crypto.VRF.Praos`](https://input-output-hk.github.io/ouroboros-network/cardano-crypto-praos/Cardano-Crypto-VRF-Praos.html#v:genSeed) module?

This module is the Haskell implementation of [`libsodium`](https://github.com/input-output-hk/libsodium), the library used by Algorand and Cardano to generate Verifiable Random Functions (VRF), which are key at the time of randomly choosing validators in both chains.

> **Comments:**
> **username_3**: I don't think this can be compiled to Plutus in on-chain code  
> **username_2**: Can you please explain the reason? I'm just starting with Plutus and I understand that all Haskell code can be compiled to Plutus.  
> **username_3**: Not all Haskell code, we have some [builtins](https://playground.plutus.iohkdev.io/doc/haddock/plutus-tx/html/PlutusTx-Builtins.html) and only they can be used inside validators. So you wound't be able to use any haskell function at all since they don't use those builtins, but we can use the plutus prelude which contains a bunch of equivalent functions  
> **username_2**: Thanks for clarifying!  

---

### Answer by username_4 on 2022-05-31. Score: 1

For The Open Source Cardano Lottery, I have created a pseudo random number onchain validator that uses parts of a tx id for the source of a random number. I am open to any feedback on this approach, but from what I have tested, I can't guess what the winner lotto ticket number will be in advance :)

<https://github.com/lley154/cardano-lottery>

> **Comments:**
> **username_3**: But I guess you could "select" the result, since you you can use any of the N UTxOs you have and each UTxO has a different tx id  
> **username_4**: To clarify @Mateus, the lottery number is chosen by players before the final close tx is created.  Only after the window to choose a winning number is closed is another transaction created that is used to derive the winning numbers.   So someone would have to predict in advance what a tx id will be - which I believe is not possible.  
> **username_3**: I see, so the tx id of the script it self is used?  
> **username_4**: yes, but only after the window to choose a winning number is closed.   I created a state machine smart contract that ensures that only when the lotto is in the correct state that a winning number can be chosen from a UTXO (that must inclue the lottery thread token).  
> **username_5**: It is not possible to generate random numbers on-chain. In your lottery, you set the winner with the closing transaction. The party doing this will inevitably have the power to chose the winner freely. There is no way to effectively prevent this. using the tx-id does not help. You can fine-tune your UTxO to get the tx-id you need.  
> **username_4**: Hi Jey, thanks for your feedback!   The lottery uses a state machine which transitions from a state that players can buy a ticket to a state that players cannot buy a ticket.  It is during this "player can't buy a lottery ticket" that a transaction is created by the lotto admin to draw the winning number.   The winning number is derived by the transaction id locked at the lotto script address which was created by transitioning the to "player can't buy" state.   By using a thread token design pattern, only the lotto admin and only during the proper state can a specific UTXO be used .  
> **username_5**: Hi lley154, what mechanism do you think prevents the lottery admin to pick the winning number freely (i.e. setting the tx-id of his choice when transitioning to the state "player can't buy") ?  
> **username_4**: Hi Jey,  in order to submit the close transaction, the UTXO must contain the thread token.  So, this prevents the lotto admin from choosing any arbitrary UTXO.  This thread token can only be spent (and then be part of a UTXO) after the lotto numbers have been chosen.   I really need to write up a diagram on this, but really appreciate the questions to see if there are any holes.  I created a youtube video of going throug the lottery process, but not sure (and don't expect) if you'll have time to look at that.  https://www.youtube.com/watch?v=q55nU9mwZYg&t=105s  
> **username_5**: I quickly went over the video. You draw your winner from the tx-id. You treat your tx-id as if it was a source of randomness. But it is not. Maybe explain why you think that your lottery has the following 2 properties: i) the party behind the admin cannot steel the pot (through a combination of acting as admin and as a buyer), ii) the winner ticket is not known in advance (i.e. cannot be computed by looking at the blockchain).  
> **username_4**: Hi @Jey,  I realized that the tx-id is not a true random number, but I thought it might be sufficiently difficult to predict it several transactions out.  But after doing some more testing, you are correct and it is possible to predict each transaction in advance until you get to the close transaction. There is also nothing to stop the lotto admin from being a player, but this is by design, so the crux of the issue is to make the winning number truly random.  Looks like I will look at using an oracle to salt the winning number selection so it can’t be predicted in advance.  Thanks again!  
> **username_5**: Hi @lley154, you're welcome. In a hobby project, I implemented a lottery that combined (i) a root number committed through a hash at creation by the lottery admin with (ii) a number (either 0 or 1) that every ticket holder could add to he oracle. Thus, the admin would need to buy the whole lottery to pick a ticket at choice. And a normal ticket holder cannot do more than pick at random because he does not know the root number. I'm not sure this approach has no holes, but it looked promising to me.  
> **username_4**: Hi @Jey,  interesting approach and I like the idea that each ticket purchased provides entropy.  The only downside I see is that the oracle needs to be updated via ticket purchases and that it may be difficult to easily audit this openly.  Ideally it would be great if the oracle used some publicly known random value so at least there can be an open audit/review once the winning numbers are revealed.   This doesn't prevent the admin from rigging the system, but does allow everyone to know if the lottery was fair.   By using multisig there could be some checks and balances as well.  
> **username_4**: Hi @Jey,  I just realized that if you require the number of tickets purchased be greater than the total amount of Ada locked in the lotto contract, this will disincentive the lotto admin from buying all of the lotto tickets.   If you also require ½ of all purchased tickets to be revealed, this prevents predicting the winning number as well.  So, I prefer your approach.  I have submitted a draft proposal in Fund 9, please message me on catalyst if you would like to be a co-proposer and we can discuss level of involvement if interested.  https://cardano.ideascale.com/c/idea/415197  

---

### Answer by username_6 on 2022-06-01. Score: 0

Getting randomness into smart contracts is a bit difficult on Cardano due to it's deterministic nature. In some cases, committment schemes can be used: <https://www.youtube.com/watch?v=JXKf1JwVAOE> which rely on the one-way property of hash functions. In this example, it's applied to a game between two parties, which are real competitors, so neither of them wants to reveal their secret information to the other and the outcome is indeed random.
This doesn't work when the different parties might have some incentive to cooperate (e.g. against the operator)

One can also "collect entropy" from multiple parties as it was done here:
<https://github.com/input-output-hk/lobster-challenge>

One can use a RNG oracle, but still has to deal with the determinism. So even if it's a perfectly fair random number, the gambler might just decide not to play (=submit their tx) in case they would loose. Maybe one can overcome it with validity intervals for tx and penalties for not submitting a tx, but it has some obvious drawbacks.


---

### Answer by username_7 on 2021-12-31. Score: 0

It depends on the use case, but [nut.link](https://nut.link/) has been submitting the League of Entropy randomness beacon.


---

