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.
Why were we interested in this project?
Out of all the many project proposals, we decided to take a bold move and look into the blockchain related projects. Aside from cryptocurrency related proposals, AR/VR, sport technology, neural networks, live subtitling projects were of our interests, but in the hopes of learning a new topic and being able to brag that we know something about blockchain, we put a lot of our options as blockchain projects. We were originally glad that we were chosen for the Musicmap project, but it has been two weeks and now that we have discovered that our project has not a whole lot to do with music, we are starting to doubt our decision.
Understanding TCR
As all of us were new to blockchain, especially TCR built on Ethereum smart contracts, the first cycle consisted mostly of research. Through our brief research throughout slightly less than two weeks, we believe that we now have a basic understanding of a TCR, Token Curated Registry.
Token Curated Registry is a registry built on the smart contract on the Ethereum platform and it holds list elements in a decentralised manner. There are three big agents: Curators, Contributors, and Users. The ultimate goal is to have a high-quality list so that it benefits the curators, contributors, and the users of the list. Right now, we have a centralised system that releases ranked registries on specific topics. For example, we have multiple magazines and websites that release the Top 10 Universities in the world, and it is easy to notice some bias in a sense that if the company releasing the list was a UK company, Cambridge, Oxford, and Imperial are more likely to appear in the upper spots while if the company releasing the list was a US company, we would see UChicago, Carnegie Mellon appear more frequently while UK universities are slightly pushed to the back. In order to reduce the bias as much as possible, the theory of TCR was introduced and right now, it doesn’t seem to have an actual implementation that is working successfully.
The curators of the list will have set a minimum deposit the contributors would need to pay in order to challenge to be on the list, and if a contributor was successful after the voting of the curators who are token-holders, it would be on the registry and would be free to withdraw whenever they would want to exit. In the case the application was rejected, the money would be split amongst the curators and the listees of the list. The higher-quality the list would become, the more users would be looking at the list, ultimately achieving the theoretical goal of the TCR. In simple words, every agent involved in the TCR formation would like to benefit from it but it isn’t the case now.
Designing our first prototype
Therefore, we decided to come to the rescue!
Actually, we hope that would be the case but at the moment, we are quite lost. We intend to build a simulator that tests out multiple TCR mechanisms so that we will be able to arrive at a TCR that will actually work. We have built our first prototype of our simulator with possible behaviour modifications for the three agents such as the number of curators, contributors, and users, and we have thought of basic TCR mechanisms that could be modified such as couple parameters like minimum deposit, and also a rather interesting change, whether the users of the TCR should pay.
As shown in the above figure, we finalised our decisions on the structure of our project and the languages we will use to program the corresponding sections. Other than designing a front end, we attended a workshop on building smart contracts in Solidity and also tried the Truffle tutorial to familiarise ourselves with the framework and Ganache. We have a long way to go, but in the next two weeks we hope to have a more specific structure for the backend and start implementing it, implement a TCR mechanism that varies with different parameters, and also implement the connection between the frontend, backend, and the TCR. It seems like a long way to go, and every time we have to take a step we seem to be lost, but what fun would it be if all the answers lied in front of us!
Problems faced
That was just positive us talking, but in reality, we have been facing quite a number of problems. It was also difficult because we couldn’t spend all our times and give all our attentions to the project as we had other university work. First, for the TCR implementation, we had no idea where to even begin. We forked the implemented TCR and with all the classes and seem-to-be-well-implemented functions, we were lost. However, right now, we are heading in the direction so that we can first implement a TCR that gets various inputs from the frontend for the parameters and correctly make a TCR according to those parameters.
Second, for the backend simulation, we struggled a lot on how to carry out the simulation at the backend at the beginning. Our initial thought was to create classes for each type of agents: Contributor, Curator and User, then generate object for each individual in the simulation. However, we did not think it was a good idea because it would cost too much computational power when we scale up the simulation. Also, we figured it would be difficult to implement concurrency when too many objects were interacting with each other. As a result, we came up with a solution which hopefully makes our lives much easier. Instead of having a class for each type of agent, we decided on creating an agentGroup class for each different kind of agent. Third, fourth, fifth, we could go on, and we are sure more problems and questions will come up each minute we spend working on this project. However, fortunately, we have our supervisor Dominik, and Ocean Protocol employees to help us whenever we are too stuck and can’t seem to move on. We have been timid in sending our questions in the concern that we may be asking dumb questions and they would judge us for not knowing such basic things, and also in the concern that we may be bothering them with our work. However, we are going to try our best not to be intimidated and ask more starting now. After all, we could be the ones who present a solution to the not working TCR!
It’s nice to dream big, but to get there, we should probably get back to work. We have a long way to go.
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).
