The FunFair dev team including founders Oli Hopton and Jeremy Longley took part in the second ever live team chat with community members over on Reddit this week.


To save you the bother of scrolling through the whole AMA, we’ve collated the main topics covered for you below (if you do want to catch up on the whole thing, you can do here).

Thanks to everyone who asked questions and got involved with the latest team chat.



ZergShotgunAndYou asked:

Hi Funfair Team,

The only technical limitations that i see as creating friction for the end user playing the games are the following:

1)Fate channels inability to transition between games therefore requiring closing the current channel and opening a new one to switch from one game to another,worsening the UX with added delays and more network fees.I understand your are planning with third party games in mind and oit’s critical to devise a secure way to allow users to transition between games without the risk for nefarious actors to put users funds at risk. Are there any plans to develop this?

2)The dispute resolution system must be efficient and automated.what’s the current status on this and your thinking about this very important mechanism?

3) i think it’s very important to get the time parameters related to the fate channels right to prevent attacks trying to tie up casinos funds by spamming multiple open game sessions, players funds being committed for too long in case of failure of the casinos nodes etc. Anything you can share with us on this?

4) some FUN detractors will certainly use the fact that the UI portion of the games – unlike the smart contracts – is fairly opaque to the user and still needs to be vetted by a central entity as a major flaw in the trustless/decentralized security architecture pioneered by Funfair. This could partially invalidate the claims of having provably fair and verifiable games. Any response to this?

5)how will the games detect and handle the eventuality of a casino not having enough FUN liquidity to cover a bet about to be placed by the player?will an alert explaining the situation be displayed?

Jeremy asnwered: 

All very good questions!

1) This is somewhat related to 5), and the locking up of casino funds, but the initial implementation is based around relatively short-lived sessions. We certainly could keep our channels open for longer, and allow game-switching to take place, but this will come in due course. There aren’t any situations where user’s funds would be at risk, though.

2) It is automated. In fact the UI-side of it has been the last piece of the puzzle to go into place. I have (finally) written the sequel to my blog post on state channels from December, and it’s about how we handle dispute resolution – should hopefully be posted next week

3) This is a key part of the Beta test. Bearing in mind that, initially, we’ll be restricting users to one account, we need to see what the practical implications are. We’re trying to keep these timeouts relatively short, whilst respecting the reality that someone might be playing on a train and go into a tunnel/run out of battery etc.

4) This is an issue with DAPPs in general, to be totally honest. Ultimately, tech like IPFS/Swarm will be able to lock in verified client-side code, and Metamask (and equivalent) will show more of what’s going on inside Eth transactions.

5) We’re pretty up front about this – the user can see how much FUN the casino has committed to the session. Each game smart contract knows the maximum win for each bet, and the UI simply won’t let the user place a bet that the casino can’t cover.



peleroberts asked: 

1. Do you have any long term plans over 5/10/15 yrs that you are working towards or on ? (very broad question)

2. Are there any incentives for the casinos besides “Fair” “transparent” to use the FF Platform ?

3. Though i have not tested this myself, Have any games been tested on Chromebooks ?

4. Will or are there any plans for a dedicated FF Android/iOS app with tablet support etc ?

5. For small first time (non established) casinos, is there a certain requirement/criteria that must be met ?

Oli asnwered:

1. We have a vision for where we want the platform to go. That will obviously change and evolve as we learn lessons from our upcoming beta and going live with our first operators, but hopefully not too much. Blockchain is such a fast moving space that trying to plan 5 or 10 years into the future is probably impossible!

2. This has been covered elsewhere in this thread, but in addition to providing fair and transparent gaming to players a FunFair powered casino will be cheaper for operators to run, far less servers and customer support than traditional solutions.

3. We haven’t done any explicit testing on Chromebooks, but as FunFair is just HTML + Javascript it should run on any relatively recent hardware.

4. iOS and Android apps are possible, but they will likely be wrappers of an operators site rather than native apps. It will be up to operators to decide if they want to do this or not, and they will have to navigate the iOS and Android app store approval processes themselves (I believe that Google only allow gambling apps on their UK store right now?)

5. We will perform due diligence on casino operators, at least in the short-medium term.



califreshed asked:

Have you started implementing gas estimation for opening and closing of the fate channels? How easy/hard is this, and are you going to have a “simple/advanced” interface, so a player thats a noob can come and it will auto choose his tx cost for fast play, or the advanced player can define it himself if he knows the ins and outs of the cost and wants to try a low fee.

Oli answered:

Gas estimation and pricing is a very interesting one, we have a simple solution at the moment, but this is one area in particular where we’re looking to learn during our Beta.

We will almost certainly end up with something along the lines of a simple/advanced UI so players who are more familiar with making Ethereum transactions can have more control.



gianluca-ragnoni asked:

Hi FunFair team, could you explain in a little details how RNG are generated in the Fate Channel context? thanks

Oli answered:

I should be good at answering this one by now.

We use a commit/reveal scheme for our RNG. The player and the house both build a chain of hashes, they use a CPRNG to generate a 32 byte seed value which they hash 10,000 times. The last hash in each chain is submitted to the blockchain during the opening of the Fate Channel. Nothing else is shared about these chains, each party keeps theirs private.

The player and house work backwards through these chains as RNG is required for gameplay. They exchange their hashes and each can validate the other’s sequence by checking that the hash they’ve just been given hashes to the last hash they were given.

Finally the player and house seeds are combined (by concatenating them and hashing again to get 32 random bytes) before being used as the input for the game contract.

That’s a whole lotta hashing.



Crypto-Pittsburgh asked:

My concern is that going to a casino’s website and doing whatever has to be done in order to play will be too intimidating/complicated to the average person. Will it be as easy as buying something online with a credit card?

Oli answered:

Player on-boarding is something we’re spending a lot of time on, and will iterate on quickly as we learn what works and what doesn’t. When we launch with our first operator we will have at least one mechanism to allow players to exchange at least ETH for FUN directly on the site (which one isn’t decided yet).

This is somewhere where the wider Ethereum ecosystem is going to help us a lot as tools (e.g. MetaMask) mature and products and services are released which allow things like purchasing crypto with credit cards direct from a dapp.