Welcome once again to another Blocktix Development Update. In this fourth iteration we’ll be talking about our work over the past two weeks in which we’ve been concentrating on a lot of different aspects of the system.
We’ve been working on subjects like ticketing, payment logic, contract creation, event overview, event promotion, interacting with different ethereum browsers and plugins, ticket redemption, and event verification.
At the moment our developers are averaging about 3600 lines of codes per week, with the total currently standing over 14.000 lines of code, which shows we are working hard to complete the initial MVP in time for the Q4 release we are envisioning. Before we move on to the actual Development part of the update we have some other news to share with you.
The Howey Test
Over the past few weeks there has been a lot of news in the cryptoscene regarding the U.S. Securities and Exchange Commission (SEC) and their views on tokens, Initial Coin Offerings (ICO) and crowdsales in the cryptocurrency community as a whole.
The important outtake in this all is that tokens that are build as securities will have big issues in the future with complying to the laws in the United States and probably abroad too. In an effort to make sure our TIX tokens are not securities we have asked our lawyers to write a so-called Legal Memorandum and perform an investigation if TIX tokens are seen as securities or not.
We are happy to announce that our legal team has found that TIX tokens DO NOT satisfy the Howey test and as such are not securities. In short this opens up the path to getting TIX listed on US-based exchanges in the near future.
The New Website
We’ve also been busy with the new website design. Although the design itself is coming along nicely, we feel that it’s not yet ready to be presented, so we’re holding it back for now. We are still working on it, and hope to have a satisfactory design over the next week.
Development of Blocktix
We’ve completed some designs around the events overview and event dashboard. Promoters will have a full view of what’s going on with their events, as well as a detailed view per event, such as revenue, ticket sales, ticket categories, ticket types, transactions and promotion.
On the development side, we’ve been facing some challenges with regards to process logic. It is expensive to deploy, and becomes redundant, as many contracts are going to be using the same logic. We are looking at ways to reduce the contract creation costs without introducing unnecessary complexities and potential security holes, but we aren’t letting the contract creation costs slow us down right now.
There’s also a big delay in creating events at times, when we create the contract, we need to wait for the transaction to be mined before we can make changes and for example add additional ticket types. We are working on a solution for transactions and sequence, to make sure the event host isn’t plagued by these delays, to make sure there is a decent user experience.
The event logs for events are now being indexed properly with elasticsearch, and all configured to run. We’ve introduced an API endpoint just to be able to configure certain parameters, have rate limiting, and so on.
Interacting with different plugins or ethereum browsers has also been interesting, as all changes to events or tickets are transactions. This means that the user needs to confirm the transactions as well as unlock their wallet a few times during the process. We’re constantly having to reconsider our user experience and the flow based on these confirmations, to make sure that these don’t constantly get in the way and ruin the user experience along the way.
The event verification process is moving along, and we’ve opted for a soft verification, that doesn’t block ticket sales unless the event is deemed to be fraudulent. The interface will show unverified events, and once it hits the verification threshold, they will either be verified or blocked. Token holders taking part in the event verification process will have their tokens in lockup until the event takes place, which will make them conscious about which events they want to verify, as without having skin in the game, people could vote for as many events without any downside. This will create a balance with the event verifiers, as they would find the most suitable types of events to verify for the best reward for them. It does mean that smaller events might not reach the verification quota, but they won’t necessarily be blocked.
In Conclusion
Again we’ve had another busy two weeks coding and developing Blocktix. In the next update we’ll have more about the ticket redemption, as well as the different roles in the event contract.
