They promise to leverage the wisdom of the crowd in curating lists of things, any type of things, through economic incentives. They are, however, still mostly theoretical. Little experimentation and formal research has been carried out into different forms and configurations of TCRs.
In this project, as part of Outlier Ventures’ Research Programme with the Imperial Centre for Cryptocurrency Research and Engineering and in collaboration with Ocean Protocol and MusicMap, a group of six students from Imperial College took on the task of building a TCR Simulator that allows for experimentation in an isolated framework to learn what works and what doesn’t. We have been impressed with their results, which included a working product with smart contracts deployed on Ethereum-compatible blockchains, field testing with a small group of users and a proposal for a new TCR mechanism. If you want to have a look at their work, you can use a live version of the TCR simulator and run the code yourself.
This project is a great example of our aim at Outlier Ventures to advance best practices in cutting edge technology through applied research.
In a series of four blogs, Matthew, Emma, Hailey, Ece, Yoon and Noel give a candid look into how they executed the project and the results they produced.
Plot twist
After hours of discussion amongst ourselves, we came to a conclusion – let’s start over! Of course, we would need our supervisor’s input on this, so we wrote him a 2-page Slack message (which really was 5 messages because of Slack’s 2000 character limit).
Hi Dominik,
After the meeting today with you and the Ocean protocol guys, we had a thorough discussion about our current simulator implementation. With the expectations of the Ocean Protocol guys in mind, we came to a new thought and we wanted to ask for your opinion about our next choice of action.
As you may have too, we noticed that the Ocean Protocol guys had a different idea of our simulator and it was quite clear to us today that the Ocean Protocol guys were more interested in the different TCR mechanisms rather than the behaviours of the three agents. Therefore, we are considering switching to what they had mentioned in the meeting, i.e. no longer simulating human behaviours. We have noted your concerns in the case that we make this change, then our simulator will not have a lot of elements to demonstrate, but as there are pros and cons for both ideas, we wanted to discuss it with you.
Option 1: Continuing our current work- Simulating the agents with different behaviours, generating different actions and test the behaviours against different TCR parameters/ a whole new TCR mechanism.
Pros:
- wouldn’t have to scrap the whole thing;
- able to compare different TCRs fairly;
- active demonstrations possible with different results for our presentation.
Cons:
- the backend has to be very actively maintained;
- any fundamental changes to the actions of the agents would lead to changes to the backend e.g. if the maintainer is allowed to propose one of the listees to become a maintainer;
- group/time management would be difficult;
- Simulating human behaviours is really challenging and not feasible within this time frame. Therefore we will implement basic human behaviours but we can’t guarantee that the end product will accurately reflect real-life scenario and therefore may not give concise results.
- Time-consuming, we do not believe that we will implement a good enough software engineer project in time
Option 2: A new approach with the suggestion of what Ocean guys said in mind – Making a platform where (admins) can deploy TCRs with different parameters. We will then let different users interact with the deployed TCRs and let them ‘play’ with it and observe and analyse the different outcomes. The focus would be on the Frontend for different user interactions.
Pros:
- We can focus on the TCR mechanism design (which in the long run might be better for future TCR implementations), which would lead to less work at the backend as it only acts as an interface between the frontend and the TCR.
- As there seems to be always confusion whenever we have a call with the Ocean Protocol guys, this would allow us to be more on the same page with them.
Cons:
- Need to redesign the whole front end
- Have to wait a long time for observations/results because no one would actually use it and there would be no fair comparison between the different TCRs hence leading to less demonstrative materials.
We noticed that even though we try to devote a lot of time to this project, due to upcoming courseworks in other modules and the exams that are coming up, we realised that we have very limited time. It would be very ideal if all of our goals for each checkpoints could be met, but as the project progressed, we noticed that we were stuck on a lot of small decisions, and that took longer than expected, which made us think about the new option more especially after the meeting today.
As mentioned under the cons of Option 1, if we were to continue our simulator implementations, e.g. introducing new actions for the different type of agents etc, it would cost us so much time updating the frontend and maintaining the backend at the same time as we would continuously need to update both ends if we decide to modify one of them. However, this “new idea” is completely different from what have agreed on so far with you, so we would like to know what you think of this idea and see if it is worth changing the plan now.
If in the case we decide to take up on the new approach, we will think of a way to accentuate our demonstration more so that the simulator users can actually see and compare different mechanisms.
Thank you for reading, we hope you will help us and share your thoughts! It was a really long message, but it was worth it because we got the approval in the end!
Re-designing
So after getting approval from Dominik, we set about re-designing our whole front end. There are two main users of the system:
- Players – the maintainers, contributors and users
- Admin – the users who will define the rules of the TCR and observe the results of the players’ interactions
From this, we decided we needed to have 2 main screens for our different users, so we split and programmed a brand new front end.
Our progress
Therefore, for this Friday, we designed our new frontend. The basic mockup looks like the figure above. We have separate pages for the Admin and the Players, and each Player will get their own profile with their account informations.
Redesigning our frontend and changing our project allowed us to incorporate music into our project. We have designed the frontend so that the players will be able to submit the music of their choice to the TCR and also challenge and withdraw their music if they wish to. Based on the amount of tokens the players hold, they could become maintainers of the registry as well. We thought of this as a type of a game; the players would be trying to maintain a good list of music and also trying to getting their choice of music onto the list while the admins who are interested in seeing the results of the different TCR mechanisms will be able to do so as the players are actively adding their music onto the TCR!
We think that our decision to change our project direction has made the simulator more interactive. We also believe that it is better because the general public may not be interested in seeing all the statistics for the different TCR mechanisms but may be interested in being part of the different agents of the TCR and also see good lists of music.
We still have a very long way to go as we actually need to implement different TCR mechanisms and connect the TCR to our frontend. It was a really bold move for us to scrap out everything we’ve done so far and to start over, but we hope that this will be better in the long-run.
This article is for information purposes only and does not constitute investment advice. This article does not amount to an invitation or inducement to buy or sell an investment nor does it solicit any such offer or invitation in any jurisdiction.
In all cases, readers should conduct their own investigation and analysis of the data in the article. All statements of opinion and/or belief contained in this article and all views expressed and all projections, forecasts or statements relating to expectations regarding future events represent Outlier Ventures Operation Limited own assessment and interpretation of information available as at the date of this article.
No responsibility or liability is accepted by Outlier Ventures Operations Limited or Sapia Partners LLP for reliance on the contents of this article.
Outlier Ventures is an Appointed Representative of Sapia Partners LLP, a firm authorised and regulated by the Financial Conduct Authority (FCA).
