Tutellus Roadmap — updated
Understanding how a digital product work is complex, and if we add a blockchain layer with a double token model the usual will be that no one understand what we are working on. To bring some light to the Ecosystem and our community, we share an updated version of the project status and the product development we plan for the mid term (6 months from now).
1. The past: Tutellus, an APIcentric platform a little bit rusty
As my partner and CTO Javier Ortiz says, “I would burn most of the code”. As any other big project, Tutellus is the result of many people, many years and many lines code. In spite of the product works perfectly it’s a little bit old: this Tutellus version was designed and built during 2014–2015. In that time we started with the 0.1.8 Docker version. There weren’t dockerization services and GraphQL was just a dream.
You have in this image some of the main projects that run around the API. The mail issue has always been the Front-end maintenance, since not to lose SEO in 2015 (remember we are in-the-air since 2013) we had to build a SEO-friendly project breaking up the website from the application, with all the complexity to maintain and duplicate code in both sides. Despite of this fact the product works, scales very well and at a very reasonable cost.
2. The present: API migration from Rest to GraphQL and services redefinition
During 2018, as we progressed in Tutellus’ tokenization, Tutellus.io development and the business around the token, we noticed we would have to increase the tech requirements and to change a lot of things. Our infrastructure model fixed very well with the NEM infrastructure, the blockchain we bet, but we had to renovate the technology in order to scale better and to improve the maintenance of future services around the token.
In the actual infrastructure model we work with (without the blockchain layer) we unify the Front with React and redesign the API connections with all the services.
3. Introducing the Blockchain layer over the actual infrastructure
Next natural step is to introduce the Blockchain layer, where due to our Tokenomics design (a lot of transactions per second and a double token model deeply described in the Whitepaper) we need 2 networks, one public (NEM mainnet) and other private, with a different token in each one and atomic cross chain transactions each a concrete number of blocks.
Why do we need atomic cross chain transactions between blockchains?
We have 2 tokens, the STUT and the TUT.
The STUT tokens measures the Relevance (knowledge) you are acquiring en each course. Any course is tagged proportionally per skill depending on its educational content. For example, a Blockchain course can have a Relevance distributed in:
- 45% knowledge in Asset Tokenization
- 30% knowledge in NEM — token creation
- 20% knowledge in NEM — apostille serve
- 5% knowledge in NEM — Catapult development
The Relevance (number of STUT tokens you get in the course) keeps the previous proportionality. The sum of the skills in each course will let your global skills grow faster. By last, the STUT tokens are distributed continually during the course, in real time, so they are consolidated in the private chain where we don’t have consolidation cost (in the Catapult NEM version, still in development).
The TUT token is the liquid token, that fluctuates and is in the mainnet, in the public NEM Blockchain. As the STUT is in the private chain no one as outsider would have access to it; and if we are the owners of the private chain we’ be able to do whatever-we-would-want on it, being able to change transactions, for example. The way to assure we don’t manipulate the private chain info is making anchorages each several blocks between both blockchains, sharing info from private to public. We assure in this way the data (STUT tokens) immutability in the NEM public chain. And this awesome functionality is still on development by Catapult team (we hope to have in production in Q4).
4. Why a double token model, or why just a token?
After the crazy ICO year of 2017 and the 2018 crypto winter people discuss a lot about the need -or not- to launch a token, and only a few projects (like Tutellus) risk to launch a doble token model. We remind you the value added to the community with our token model;
4.1. Decentralized Governance close to a DAO
The double token model and the STUT management let us to decentralize Operational decisions and to delegate them in the Community. We inspire in how contributors get tokens in the DAO Bisq, for example.
The STUT token, as you know, is used to assign Relevance to users. The more Relevance a user has in a concrete skill the more decisions will be able to make and the more STUT tokens will get. For example: new Courses approval, Careers new content update o added Services course proposals (exams, tests, projects, documentation, etc). In this way (similar to Bisq) any user can add value to the Community and been awarded by its contributions, even with similar techniques: whereas that in Bisq holders “color” bitcoins, we “color” TUT tokens creating in this way STUT tokens and assign them to contributors.
This kind of services and contributions acquire even more value when we launch the platform in other languages (Q4)… imagine the team we would need to review, approve, reject courses & other materials in any language.
4.2. Reputational power untied Economic power
Here is where the double token model gets all the sense: it would be unfair that the TUT holder would get contributions for operational tasks without knlowledge or reputation in the skills he is working with. By another hand, the STUT holder can have a lot of Relevance but not economic power (TUT tokens), so the governance about the contributions he can get revolve around him. By last, we need a mechanism to transfer value from one token (STUT) to another (TUT), the “trade decision” deeply described in the Whitepaper.
Each token has its own functions and coexist in a healthy way.
4.3. The TUT token as the only way to access to several services
Any user can pay with TUT tokens a product/service in Tutellus, now in a manual way and soon automatically (wip). Imagine, at the end of 2020, we have millions of users with their relevance tokenized and we offer recruiting services to companies based on those Relevance, updated (in time) and located (in space); in this scenario we can localize people looking for a job in Madrid with high skills in Blockchain, Git and JS. This kind of services can be taken on only in TUT tokens, although for the company will be transparent (it will be an internal operation between Tutellus and the Exchange).
By last and not less important, imagine the TUT token as the gas you need to execute smart contracts by third entities that use our dAPPs, as we describe then.
5. The TUT token as the [future?] decentralized protocol for the EdTech industry
Why are we so obsessed to launch a token with a very clear use inside Tutellus (by students, teachers and companies) but a strange use outside it?
This point is important. In january 2019 we published the TUT protocol Yellowpaper, you have it here. the TUT token has a much longer life than staying inside Tutellus. The TUT protocol includes a set of mechanisms, functionalities and smart contracts that let anyone to execute EdTech decentralized dAPPs without the need to develop a business model as the one we did.
We pretend to open our smart contracts to anyone that wants to create an Educational dAPP and to empower its Community in a simple and cost-effective way. The only thing you will need to execute the smart contracts is gas under the shape of TUT tokens.
This model is very interesting: to become the TUT token in a standard in the EdTech industry. Again, the execution of smart contracts paying the gas with a no-native NEM token (without XEM) is something under development over the Catapult umbrella.
6. Roadmap: where we are and where we go
We are taking advantage of these months to run with the internal functionality we described as the core Catapult DevTeam progress in their Roadmap.
In a parallel way, first services to implement -depending on Catapult updates- with impact in the final user are:
- Wallet creation for STUT and TUT deposit. We’ll provide custody services to users from the STUT side.
- Service to purchase/exchange courses & subscriptions in TUT tokens.
- Service of STUT tokens generation associated to player (video consumption).
- Service of STUT tokens generation associated to Answers.
- Service of STUT tokens generation associated to Notes service.
- Service to convert STUT to TUT tokens (‘trade decision’).
- Token TUT Exchange listing. We are been cautious in this point, due to the complexity & darkness in the Exchanges business. The fact to list the TUT token should add value to the project, not taking it away.
7. NEM Status — Catapult
As you can see, services described in the private chain must be executed with Catapult, and it’s still under development. We hope to have it in production in Q4. We are convinced that the wait will compensate and NEM has always been the best choice for the project.
The kind of services we can implement with Catapult are awesome, its speed (until 4.000 tps in the private chain), the easy-to-develop smart contracts (using Javascript SDK) and the fact that we are the platform with the official certification Catapult course position ourselves in the first line.
Cheers!
