What we can learn about the NEM voting system from Travelbybit
First of all, congratulations to the Travelbybit team, I hope that the project goes well and we have more good news soon.
The NEM voting module has suffered a little bit in the last months, mainly due to it being disabled for the update of NanoWallet, now it has been reenabled and is regaining popularity amongst nem users, reflected by the number of votes and interest on the last proposal votes. Also, an npm module for voting is being developed and will be released soon so that everyone that wants to include voting in their applications can do so freely and easily, without having to learn about all the technical details.
So now that the system is back up and doing well, let’s see what we can learn from the most recent proposal, Travelbybit. I have extracted the data from all the votes for the proposal and analysed the data to see what information we can extract from there.
First of all the total number of votes for the proposal was 464. From those 456 were in favor of the proposal and 8 were against, showing an unanimous support for the project. The total importance of all the voters with valid votes at the time of the end of the poll is 3.1947%, the total importance for the yes vote is 3.1634%, and the importance for no is 0.0312%.
Of the 464, 123 voters have an importance score of 0, and 299 voters have the minimum of 10000 xem needed to have an importance score. The remaining 42 votes are invalid votes. This are the reasons votes are counted as invalid:
Votes that send xem to the option account are counted as invalid, to prevent people trying to vote from an exchange to manipulate the results. It is important that when you vote on the NEM system you send a 0xem and 0 mosaics transaction, otherwise your vote will not count. There is also 22 accounts that sent a transaction to both options, and their vote was nullified.
From the accounts that voted on the proposal 29 are multisig accounts.
Let’s now draw some charts. First we will plot the total amount of accumulated votes over time.
We can see the initial spike at the time that the proposal vote was announced, but after that people kept voting on the proposal mostly at a constant rate. We can also see how people at some point lost some interest. As we can see in the next graph that point was when the total importance for the yes option surpassed the 3% importance needed for the proposal to pass. If you support the project it is adviced that you vote even if the importance at the time is higher that 3%, since importances can change, and things can happen over time, so you never know when your vote will be useful.
Next we will plot the same concept, but instead of total number of voted we will see the total accumulated importance.
We can see in this plot the sudden spikes from when big importance accounts vote. We can see better here how the number of votes diminishes drastically once the goal is reached. Let’s see now how importances are distributed between voters:
This graph contains all the accounts that voted on the poll, we can see that there are a lot of low importance accounts, but also there is one account that can’t be easily seen but is at the right of the poll, and has around 0.14% of the total NEM importance. That is huge. Let’s visualize the same plot but without the 0 importance accounts and the huge account (we will analyse the high importance accounts later).
This one looks much clearer after removing the outliers. The distribution is still very left skewed, but there is also an interesting spike at around 0.03–0.35%. I suspect these are supernodes since that is around the importance that you would get by purchasing one.
Another interesting thing we can do is to visualize the 5 highest importance votes.
We can see here that the huge account has almost triple the importance than the second vote with more importance, and also that the third highest importance vote is invalid by sending xem or mosaics in the vote transaction. Maybe that is somebody that tried to vote from an exchange?
In conclusion I think that the results look good for the NEM voting system, and also for Travelbybit who got very good results. The amount of people that participated on the poll says a lot, and I personally think it will continue to grow.
It is also important when anouncing a poll to give clear instructions on how to vote, to avoid people from sending invalid votes. Votes from 0 importance accounts are ok and there is nothing wrong with them, since it doesn’t add to the importance score for the option they vote, but it shows support for the project, but it should be made clear that only votes with 0xem and no mosaics are counted as valid.
If you want to know more about the voting system I have recently redacted a Technical specification, and stay tuned for the upcoming npm module that will change how voting is used in the NEM ecosystem, increasing the possible use cases. It will also allow extracting data so that anybody can analyse data like in this post.
I have released the .csv file with the data used and the Jupyter notebook used to perform the analysis on github if you want to play with the code, the data or the interactive charts.
Thanks to all the people who participated to help grow the voting system, and all those who voted in the TravelbyBit proposal.
TravelbyBit is growing a network of merchants around Australia that accepts payment in cryptocurrencies like Bitcoin and soon NEM.
TravelbyBit payment system is fundamentally different. Our merchants facilitate genuine peer-to-peer transactions. Through the use of digital wallets travellers pay with their choice of digital currency, creating an awareness of Bitcoin amongst the merchants, their staff, and their customers.
Although customers pay in digital currencies like Bitcoin, the merchants can choose to receive payment in Bitcoin, fiat currency, or a combination. It’s our vision that our merchants around Australia will begin to receive payment exclusively in Bitcoin, use it to pay for business suppliers and even pay their staff in Bitcoin.