mDevCoinExchange: a successful conference gamification based on Firebase and Angular

I helped to organize mDevCamp — a conference about mobile development which took place on June 15, 2018. I was responsible for the conference gamification. This year, we were inspired by a popular topic of cryptocurrencies and created a system simulating a crypto exchange for attendees. The game was a big success: 520 out of 750 attendees participated. In this post, I will explain our system design, open-source code, share some statistics and show how it could be improved.

TV interface of the game


At first, we were looking at various cryptoexchanges like Coinbase and Kraken and figured out the MVP which would fit the conference:

  • We need at least 3 coins to make exchange rates between them interesting and less predictable. We named them Android Dev Coin (ADC), iOS Dev Coin (IDC) and Cross-platform Coin (XPC), based on interests of our attendees.
  • Attendees should get some coins after login to get hooked from the beginning. They will log in via a private key printed on their badges, but it should be possible to protect it with a password later.
  • Attendees should be able to earn more coins at our partners’ stands. Our partners will like it because it will attract motivated attendees to their stands. For that, they will help us with the content (each partner created some task or game for the attendees) and they will donate physical prizes to us.
  • Attendees can ‘cash out’ the coins for physical prizes. This way, our coins will have a real value and it will motivate attendees.
  • Attendees should be able to trade coins on an open market and trading should affect the price of each coin. Attendees can speculate on a future value.
  • Users need to be able to send coins to each other directly. We need this feature for partners and it also allows attendees to send coins from multiple accounts into one in order to have larger market power and get a chance to buy more expensive prizes.
  • Users should be able to see their transaction history.
  • Users should be able to see graphs of coin values. We should also show this on a big TV to attract new players.

Economic model

We needed to design a model which is simple to implement but similar to crypto markets. I talked to a few people with an economic background and we came up with the following economic model:

  • Only the accepted offers should affect the price, not standing offers. Also, sending coins directly (for free) should not affect the price.
  • The value of coins should be expressed in CZK, a fiat currency outside the system. All attendees know it so it’s easy to associate a value with it. It also helped us with pricing the prizes = we just copied real prices from real shops.
  • Each eligible transaction should increase the price of the more valuable coin and decrease the price of the less valuable coin. However, the total value of both coins should stay the same.
  • The prices in graphs should be a weighted average from past 30 minutes of transactions. It will smoothen the graphs and won’t show extremes. The weight should be the transaction amount (larger transactions affect the exchange rate more). The exchange rate for cash-out should also use this averaged value.
  • We will give 10% of coins to attendees in the beginning and 50% will go to partners for distribution.
  • We are not sure how the market will behave. There was a risk that it would be too balanced and not changing much, which would be boring. So we set aside 40% of coins for market manipulation and as a reserve for unexpected things. To justify market manipulation we prepared funny “fake news” on conference Slack.

How was the exchange rate of each transaction calculated?

It’s easiest to understand it from an example:

Someone sold 1 IDC for 2 ADC.

What would be the value of IDC and ADC in CZK?

First, we need to figure out an average price of one coin in CZK. It was easiest to make this simply 1. We had prizes for 300k CZK so we issued 300k coins (100k of each).

The general formula is:


Price of IDC was calculated like this:

1 IDC = 1/(1+2)*2*2 = 1.3333333 CZK

Price of ADC was calculated like this:

1 ADC = 1/(1+2)*1*2 = 0.6666666 CZK

This way we achieved our goal:

  • IDC is twice as valuable as ADC
  • Total value of both coins in CZK are the same as before
List of offers with values in CZK

The code

We dismissed using an actual blockchain technology for this. We need the system to be centralized, not distributed. It needs to be really fast and we don’t want to maintain it after the conference.

We knew that the system needs to be very real-time, especially the offers. Many people will put offers at once and buy them at similar time so we need to handle the conflicts. First, we considered a simple REST API done in Python, but at the end we chose Firebase Realtime Database as a backend solution. The system was very fast and it handled all synchronization logic for us.

It’s always hard to design a good database structure. Here is our sample database and a clean database structure. The database is backed up by security rules which ensure data consistency and authorization. We wrote them with Bolt, which greatly simplified the process.

All the backend logic (login, calculating exchange rates, buying offers, handling cashouts etc.) was done by Cloud Functions for Firebase. We used mostly database triggers which were listening on changes in the database and writing results to other parts of the database. We started to write functions in pure Javascript, but it quickly turned into a hard-to-debug callback hell. So I rewrote it into TypeScript with heavy use of async-await pattern. It comes very handy with Firebase because all the APIs are asynchronous.

We didn’t have resources to develop both Android and iOS app, so we chose a web frontend for the game. I didn’t have much background in JavaScript development, but I wanted to learn what the fuss is about with all those frameworks. I was considering React and Angular. At the end I chose Angular, because it contained all the parts on its own. I didn’t have to make decisions about architecture, router library, build tools etc. Angular has a nice CLI which generates all the boilerplate and made me to separate the code into independent components. Plus there is a nice library AngularFire which simplified the work with Firebase.

For the charts we chose a proven library ChartJS which supported line charts and pie charts we needed.

We wanted to show which prizes are available in real-time to motivate the attendees and also allow them to decide when it’s the best time to cash out. In the end, a simple spreadsheet worked really well.

All the code is open-sourced! We welcome feedback and we are curious what you will learn from it and how you will use it. Feel free to use it for another conference. Or maybe for a simulation of real currencies?


  • 520 out of 750 attendees participated in the game
  • Together, they made 5520 transactions (one every 6.5 seconds)
  • We handed out prizes of total value of 269,950 CZK
  • Server costs were: Realtime DB $2.41, web hosting $0.16, Cloud Functions $0.02 = $2.59
Changes in exchange rates during the day including “fake news”


If you didn’t attend mDevCamp, you can try the game here.

Based on our experience, this is what we would have done differently:

  • Offers should expire, for example after 30 minutes. There were many outdated offers which clogged the UI.
  • Exchange rate was converging to 1:1:1, even after we changed the prices with fake news. We think it was mostly caused by outdated offers.
  • Charts became very slow with a lot of data. We should optimize the code — not reload data chart after every change and introduce sampling to reduce amount of data displayed.

Otherwise, the game was a big success as confirmed by our attendees (thanks Luu Ly for an awesome report!) and partners. Check out the open-source code, learn from it about Firebase, Angular and economics. Let us know if you use our system somewhere else, we are curious!

Big thanks to Jiří Čadek for his work on backend and testing and David Ryšánek for his work on charts, TV interface and design.