What a year has this been for Rotki! With less than two days left in 2019 this post is meant to highlight the biggest things that happened in the project during the past 12 months, list what we have achieved and look to what is coming in the future.
Year In Review
January started with the publishing of Rotki v0.6.0, the last release before v1.0.
It was a big release containing many bug fixes but also introducing some features like the API query caching or the tax report progress indicator that stay with Rotki even to this date.
Other than that development continued with a good pace.
Work on Rotki continued. The project’s source code was ported to Windows and for the first time Rotki gets to run in a Windows environment.
Trying to port code to Windows is not an easy thing, especially coming from a Linux background, but seeing the end result of the app running inside an all familiar looking windows themed frame is really rewarding.
Apart from that a lot of work on improving the experience of the application was done such as accomodating for Token upgrades starting with the new MLN token.
Rotki participated in ETHCC 2 in Paris and gave a talk on what Rotki is, what is the problem that we are trying to solve and what would v1.0 bring.
The reactions from the audience and the questions we got were really encouraging. People wanted to learn more about Rotki’s mission, how can they try it but most of all when would it be available in Windows and when would v1.0 be released?
To see the full recording of the talk check here.
Development continued in April but rather slowly. This month was dominated by events in Lefteris’ personal life as he became a father!
Slowly development picked up its pace again with various bug fixes done to the app but also some features being implemented. Most notable change that got implemented in May was a complete change in the way assets are handled by Rotki. The application no longer trusted any single token/asset symbol it is given. Instead from here and on it maintains a list of known asset symbols along with their conversions from/to external services. Any asset not in that list is not supported by Rotki. This lets us stop the guessing games about what assets the user has and instead allows us to know all details about each token in question and how it translates in each exchange or price querying website.
If you are interested to learn more about this topic it has been covered extensively in this post.
Development continued with a steady pace towards v1.0.
A lot of work is also happening outside of Github as a website is being built for Rotki which also contains a system that allows premium users to purchase and manage premium subscriptions. Also an API server is being developed for the premiums users of Rotki.
July is definitely dominated by finally reaching the v1.0 milestone.
The Rotki v1.0 release was the biggest release of Rotki up to now (probably will be overshadowed by v1.1.0 though ;)).
It officially launched the purchasing of Rotki premium subscriptions and the website to support it. It also was the first release to utilize the premium API server to provide the users with the ability to save their data in our servers and get extra statistics and graphs for their assets and activity.
Rotki v1.0 also was the first release to be able to run in Windows.
With Rotki v1.0 the users could now for the first time conveniently see notifications in the top right of the front-end about information or warnings that the software wants to show them instead of always having to read the logfiles.
Finally this version had a ton of bug fixes, and new features for a full list of which you should check the release notes.
As if v1.0 in July was not enough, August was a really busy month for Rotki!
As the users started using v1.0, August started with bugfixing of various issues that were reported. Not one, but two bugfixing releases were made within a few days!
In August we also got our first paying premium subscribers, something that boosted our confidence that what we are building is something that people need and that the problem we are solving is worth all the effort we are putting into the project.
We also started getting a lot of feature requests from people in social media and Github
There we talked with many users who were interested in what’s in store for Rotki and we got lots of feedback and advice on how to go forward.
Finally at the very end of the month, a big release containing bug fixes and the most requested features was made. Release v1.0.3 added support for Coinbase which was a feature prioritized via request of a premium subscriber.
It also introduced a dmg installer for OSX users, added a popup warning users when new releases are available and added various smaller features and lots of bug fixes. Check the changelog for more details.
In the meantime traction in social media is slowly increasing. To further improve our online presence we are trying to educate current and potential future users on why Rotki is needed by explaining the problems of centralization, lack of privacy and lack of data ownership that all other portfolio tracking and accounting solutions are facing.
Finally in order to support the Ethereum ecosystem from which we came we also became sponsors of ethereum’s devcon 5 that would take place next month in Osaka, Japan.
October started by unleashing a new Rotki release!
Release v1.0.4 contained multiple features and bug fixes. The most noteworthy feature of that release was the ability to import data from cointracking.info. That feature was requested by a premium subscriber and as such was prioritized. For a full list of changes take a look at the changelog.
The most seminal event of October was of course our participation in Ethereum’s Devcon 5 in Osaka, Japan and the talk we gave there regarding the problems of using centralized tools in order to do accounting for the world of decentralized finance. You can find a recorded video of the talk here.
There was a lot of feedback given to us after the talk and during our presence in the conference. The feedback and questions revolved around upcoming DeFi features but also ideas of monetization for the project. There were ample discussions about the direction Rotki is taking as an opensource application trying to monetize itself and we got many ideas on potential ways forward.
Development also continued albeit in a slower pace due to travelling to the other side of the world for the conference.
In November development continued trying to fix various bugs and prepare the next upcoming release.
The most noteworthy change that occured in November was the rebranding of the project from Rotkehlchen to Rotki. Since even before v1.0 many people were complaining about the difficulty they faced when trying to pronounce or spell the original name. It made it really hard to spread the word about it, recommend it to friends or even google it. As such rebranding to the diminutive form was absolutely necessary. Github, twitter, website all got renamed. For a full list of what changed check this post.
In November we also had to face the problems introduced by the introduction of Maker DAO Multi-collateral DAI and the renaming of the old DAI to SAI. We developed the required code and DB upgrades to handle it and also explained our view on why renaming an asset like that is misguided in this blogpost.
This month, Rotki has been on fire!
December started with the publishing of the last release for the year. Rotki v1.0.5 was released mainly containing the work done for the Maker DAO multi-collateral DAI upgrade. Some minor features and bug fixes were also included in this release. For a full list of changes check the changelog.
After requests from our users we also created two chatrooms where users can chat about Rotki. A Telegram chat and a discord room.
But December, presumably due to the holidays, has been one of our most productive months of work.
We started having two different branches in the project due to the sheer amount of changes happening. The master branch stays as the stable branch where releases are published from. The development branch is where all new work is going to.
The work that Kelsos had started in June in order to switch the entire front-end code to utilize the Vue.js framework was finally finished and got merged.
We also described how would v1.1.0 look in our new year resolutions for 2020 post. Check it out if you would like to see some hints about how v1.1.0 will look like and also some more long-term ideas about Rotki.
What a year has 2019 been for Rotki! We are beaming with pride! So much work has been done, the userbase is steadily growing, we acquired the first paid users and we have gotten more feature requests than we can currently cope with.
We would like to thank all the users who have entrusted us with their business and for all the good wishes and words of support we have gotten over social media. We promise that as we head into 2020 we will not let you down!
Conclusion - 2020 and beyond
Heading into the new decade, we can only be positive about the future of Rotki!
A lot more work will be going into the project in order to fullfill all the feature requests we have been getting. Expect a lot more coming from us and for our online presence to increase and become stronger. The userbase will also steadily keep increasing, which will allow us to perfect the software and make it the best tool for everyone by taking all of your feedback into account.
Stay tuned for more updates and please help us in building the best transparent financial tool that enables you to take ownership of your financial data. Ways to do that are:
As 2019 draws to a close, a lot of users have been asking us when will certain features be implemented, which features are in the pipeline and generally what’s the roadmap for the future of Rotki as an application. This short post attempts to serve as a go-to answer for these questions, clarify the short-term roadmap and give some hints on what will come in the long-term future.
Very recently we have created a develop branch in Rotki in order to facilitate all the big breaking changes that are coming. All PRs by default will now be done against develop and thus all big changes that need to be done will stay in that branch. Once a release is done, develop will merge to master and binaries will be published. PRs against master will be reserved for quick patch fixes that can be done independently of any breaking changes in develop.
The next release coming out of will be v1.1.0 and it will contain, among other things, two major features.
The entire UI is being rewritten and turned from the old-school hand-made CSS + bootstrap abominaton to a proper modern framework thanks to the tireless work done by kelsos. At the time of writing this post the work is almost done and the PR is about to be merged.
What does the average user care you may ask? By far the most important advantage of this change is that adding new UI components and thus features will become much easier. Vue.js is a modular framework which makes it trivial to add new components or modify the looks of the UI. In short adding new features is now going to be made easier. God knows there is a lot in the pipeline that needs to be implemented!
Apart from that the looks of the entire app are getting modernized. All components are now more sleek and pleasing to the eye. For example here is the ethereum token selection.
Proper REST API
The entire ZMQ messaging layer is getting rooted out and replaced by a proper REST API.
What does the average user care about this you may ask? Higher electron versions allow us to have more security in the application and take advantage of all the new electron features. Also with ZMQ no longer being a dependency, a very big and fat dependency is out and final binaries would probably be smaller in size.
Finally with this change Rotki will be getting a very good, well documented and tested REST API. Users will now also be able to work with Rotki via command line interfaces. Below is a screenshot of the docs in the work in progress PR that implements the ZMQ to REST API switch.
When it’s ready. Soon ™.
Other releases after v1.1.0
The next big feature planned after that is implementation of support for Coinbase PRO which should hit in the release right after v1.1.0, presumably v1.2.0.
What would you like to see in the near future implemented in Rotki? Don’t be shy, join us and write up a feature request as a github issue here.
How can I follow the evolution of the roadmap?
As an opensource application, transparency is in the core of Rotki’s ethos. As of the writing of this post our milestones are tracked by Github projects. You can see the current milestones here and inspect which features will be implemented and which bugs will be fixed in which releases.
The current milestones are:
Next patch release: Small issues that may pop up and need quick fixes go here. Patch releases are made if required to make quick fixes to an already existing release.
Next minor release (currently v1.1.0): Most of the current development always targets the next minor release. All new features that are going to be included in the next release end up going there.
Minor release after the next (currently v1.2.0): This is where features that are planned for development go but which we know will not be included in the next minor (feature) release.
The long term vision for Rotki is for it to become the best portfolio management, tracking and accounting application for both crypto and traditional assets. The tool that not only enables you to manage your finances but also does this in an opensource, transparent way allowing you to own your financial data and not have them lying on a centralized server somewhere in the cloud ready to fall into the hands of malicious actors.
In an ideal future it would also be able to track not only one’s investments but also everyday expenses and provide insight and analytics about the entire spectrum of a user’s finances.
There are no specific Github issues made yet for the various things that we are thinking about the long-term future but as a general idea:
Rotki should be able to track traditional assets such as stocks, bonds, real estate and so on.
Rotki should be able to manage a user’s daily expenses and provide insights and analytics into spending habits, savings and so on.
Users of Rotki should be able to track part of their expenses while on the move so a companion mobile app to Rotki desktop should be made.
What else would you like to see implemented in the long run in Rotki? What would you require from an application that is supposed to be the constant and trusted companion to all your financial analysis needs?
Naturally all the above largely depend on how the current userbase of Rotki grows and how succesfull is the monetization of the application. Without any steady revenue stream or funding all of the above are probably really hard to accomplish.
The future of Rotki is bright! There is a lot of demand in the form of feature requests, and the userbase is steadily increasing. Stay tuned for more updates and please help us in building the best transparent financial tool that enables you to take ownership of your data. Ways to do that are:
Yesterday MakerDAO reached a very important milestone. It introduced a new type of DAI stablecoin that can have multiple underlying assets used for collateral as opposed to the old DAI which could only be supported by collateralizing ETH.
Unfortunately at the same time they decided that they were so attached to the name DAI that they wanted to give the same name to the new token. And they could only do this by renaming the old token. Which is exactly what MakerDAO went with as you can see here.
This post is going to explain in detail why from a user’s or an application’s perspective the decision to change the name is quite bluntly put idiotic. Renaming DAI to SAI has zero advantages and introduces a long list of problems as seen below.
Problems introduced by renaming
In this section we will see a writeup of all the problems that the renaming is introducing along with a short explanation for each one.
A contract deployed in the Ethereum blockchain is immutable. The DAI contract is here. If you try to read the symbol attribute it will be DAI. The symbol attribute is part of the ERC20 interface and ignoring it breaks that interface. You can not arbitrarily decide to now call the token by a different name (SAI) while the symbol of the token is DAI.
Right now centralized exchanges are in a tough spot. They have to perform DAI to MCDAI upgrades for their users and then decide on how to name the new assets. If an exchange intends to keep both tokens listed then the naming becomes a problem.
In the end the problem is pushed to the users as can be seen from above. For users SAI is DAI but if as a user you attempt to deposit what you think is DAI to Kraken you will lose it. If that does not constitute a UX nightmare I honestly do not know what does.
Decentralized exchanges do not have much of a choice. They do not hold the tokens for their users so they will not be able to automatically upgrade DAI for them. They need to offer trades in both tokens and then the naming does indeed become a problem.
Software needs to be making assumptions for some basic things. One of these assumptions that software in our field make is on the immutability of contracts and by extension the token contract symbols.
Software libraries that made correct assumptions in the past will now break.
At the moment, the DAI symbol returns the old logo of DAI and the SAI symbol will return an error. All projects using this library (and it’s a lot) will have to update whenever a new version comes out. At the moment there is no version supporting the new naming so all projects using it are displaying the wrong icons.
A lot of APIs, for example price feeds such as cryptocompare have had DAI listed. Now they need to update their APIs in order to point DAI to the price of the new multicollateral DAI and create a new entry for the SAI token which points to the old DAI price. And that is hoping that there is no other cryptocurrency with the SAI symbol. I am pretty sure not every one of these price feeds will follow the new naming and then end-user applications will have to maintain converters between different price feeds using different symbols. It’s a mess.
End user applications
Every single end-user application that deals with crypto and DAI has to adjust. As an example we can take Rotki. If we go with renaming DAI to SAI we have to create a new release that will upgrade the user’s databases renaming the assets and rewritting history. If we do not we will confuse our users.
What is the solution?
At this point nothing can be done. The renaming has to go through since it has already started. But due to all the reasons outlined above it was a terrible decision.
The proper solution would have been a very simple one. DAI stays as DAI and is the symbol of the single collateral DAI. And then the new multi-collateral token is called MCDAI or well … anything other than the same name as the previous token.
Despite all the problems with the renaming the achievement of having a multicollateral DAI is something to be proud of.
All of the above problems in isolation do not sound really bad but if you sum them all up it ends up as a nightmare for all actors involved. It’s a mess for application developers, a mess for users and a mess for service providers. And all of these could have been avoided by simply doing the obvious thing and providing a new name for a new token!
For Rotki a blog post will follow explaining how we will handle the switch from SAI to DAI and how it will be reflected in the databases of our users. If you liked this post and have not tried Rotki yet you can get the latest release from here. By using Rotki you can take ownership of your financial data! Please try it out and provide us with feedback so that the software can improve.