 These are driving principles behind development in ROTC. So let's start. So who am I? I have been doing application development, local, mobile, and web since 2010. Most of the time of this was doing open source. And I have been a ROTC contributor since 2018, handling parts of the front end, infrastructure, packaging. So what you do in a startup, pretty much touching all over the code base. So let's start with the problem today. The problem today is that we don't have enough decentralization. A lot of the software we use daily is close source. It runs on data centers. And there, you don't have ownership or control of your data. They can use it to train machine learning algorithms, use it for whatever reason. There is no transparency. And you have to trust that they use it as the claim. They might claim that they have encryption, but you don't have any way to verify that there is no master key, and there is no way to be sure that all the claims are true. Then your data can leak. This can happen with different ways, like, for example, accidents. And in turn, got too much access, but didn't know what they were doing. And all your private information is public, or hacks, or some companies just outright sell data. There was a nice John Oliver episode about data brokers that was really scary on how much information they could get about people, even sensitive information, like health care, and the exact point where people were living. Then other problems are that the companies can go out of business, and then basically you lose access to all your data. Another problem can be that they can de-platform you. Something happens, your account is locked, and then, poof, all your data is gone. We can see some examples. So for example, Dapr started blocking all the Russian users, so basically they lost access to their funds. Then we had the case of SNAPs that employees were abusing data access to just spy on users. And as we saw, Uber was hacked recently by a teenager. So it's easy to, you know, if your public information goes out, then there is no way back. Then we had the ledger hack, like people were receiving mail after their homes, which can be really scary because their public addresses, their private addresses, the home addresses, were outside in public. So let's talk about open source. What is open source? Like, there are 10 criteria that define open source. The main idea is that open source software is freely distributed along with the source code, and it doesn't limit the usage. There is no discrimination against people and against usages. Everyone can use open source software. We also have cases of software that has public available code, but it isn't open source. Some examples include the delayed open source license that a UNISO can now have, maybe MongoDB server site public license. And in a lot of cases, I can understand the reason behind that because it's really hard for open source projects to fight against big companies. The reason for the server site public license is that AWS was taking all of MongoDB, selling it as a service, and then the developers didn't have the funds. And they had to maintain and fix the issues. So why open source? There are some strong benefits of building open source. You can have a strong community involvement. You can have transparency, reliability, security. And it also makes attracting talent easier, and it avoids also vendor lock-in. So community involvement. There are people around, like someone needs a feature. We might be overwhelmed, and someone with technical knowledge can come and contribute to the code base, and add their feature that they want to use, so other people can also use it. Then non-technical people can contribute with translations, making the app available to a bigger amount of people, or documentation, or just open issues. The code is really transparent. You don't have to trust what the developer claims that the software does. You can easily read the code, or other people can read the code, and verify that these claims are actually true. And open source software tends to be more reliable and secure. It's peer-reviewed, so anyone can read the code, and it's easier to spot flaws earlier than closed source. We have software we always use that is really robust. For example, Firefox, the Linux kernel, Theorem Client, Centinix, and this is highly reliable software we use everywhere, and it's all open source. Then open source can make attracting talent really easy, because it's always easier to hire someone that you have previously worked with, you had the good interaction, and then maybe you also text your code, and you can see in an easier way that someone is a good fit for your culture, which is not always the case when doing some small interviews and giving some kind of task. And then, like I said, you can avoid vendor locking. You always have access to the source code, you always have access to the application, you can check the data, you can access the data. So in case you want to move and migrate from a platform, it becomes really easy, because you can access everything. So the biggest problem with open source is funding, because it's hard to monetize open source software. We had some major incidents, for example, it was the log for Jhack, or open source hard bleed. And what we found out out of this is that you had a couple of overwhelmed software developers maintaining infrastructure critical software, and everyone using it, but they were always underfunded. No one was paying for that. And this led to huge security problems. So there are different ways to fund, but it's always difficult. For example, you can accept donations, you can have, as we do in Rocky, we can get grants for integrations with other protocols. Get-con grants is something that helps us a lot to build the software. And then we have premium subscriptions, but this doesn't really work, because it's hard to monetize retail. And as a new small software, it's hard for us to actually have the amount of people that we would need to have a sustainable source of income. So let's talk about local first software. In local first software, you control your data. Everything happens on the machine you control. There are three major principles. So the network is optional. Local data is the primary data. And security and privacy are really fundamental. So by network is optional. We don't mean that you don't have access to the network. Like you can use your Wi-Fi. You can use your local network to access blockchain data, maybe get your trades from centralized exchanges. What this means is that all the processing of this data happens locally on your machine. Data is not pushed to a remote server. It's not pushed to a remote API. Everything happens transparently on your machine. So your local data is primary. Unlike all these clouds up, like using Google Drive, the primary source of data is Google Drive. Any copies, if you have, are usually some kind of cache, some secondary copy. And while it's unlikely in the case of Google Drive, if your cloud provider goes out of business, then you might lose everything. Then because everything is stored locally on your machine, it's more secure and it's harder to leak than if you had everything on the data center because you are the owner, you control the machine, and you can actually better protect them. So let's talk about Rotki. That's a nice project we are building. Rotki is a portfolio tracker and accounting tool that is open source, local first, and it's focused on privacy. And unlike what some people believe, the Rotki team is not only left-arist. Like, we know he's kind of super humor, but he cannot do everything on his own. Currently, the Rotki team consists of seven people, six developers, and one person handling operations. From the developers, we have left-arist, which most of you, if not everyone, knows. Then he does backend business development. He does a lot of stuff. Then I'm doing mostly front-end, back-end infrastructure. Like I said, then we have Jabir that handles also back-end. Luki is working with me on front-end. And he has been a really great help. And then we have Isaac and Alexei, which are our newest members, that also do back-end. And finally, Celina, left-arist wife, that really helps us with the non-technical stuff that the company needs. And we are really glad to have her. So we are building Rotki across three basic principles. Rotki is open source, it's local first, and it uses encryption to store the data. With this, we can guarantee that the functionality is transparent. You don't have to actually trust us. You can verify on how we handle your data and how the app works. Because it's a local app, you own the data. We don't have access to your data. We don't know anything about your data. Any address, any account, any key you put on Rotki stays locally encrypted in the database in your machine. We don't have access to any of that. And also, you have access to the code. If anything happens to us, hopefully it will not, but if anything happens to us, someone can pick up the software and keep providing value to the users. So let's talk about Rotki's architecture. Rotki is split into parts. One is the Python backend, and the other is the frontend. The frontend is really simple. It just calls the backend, and it's what you see when you open the app. The backend does all the data processing. It calls open APIs, open nodes, or maybe you can also add your local nodes. So if you run your own Ethereum node, Rotki can hit it, and it will be immensely faster than hitting public nodes. And then we have two databases. One is the encrypted user DB that uses SQL Cypher to encrypt. And this is where your private data stays. And then we have the global DB that usually has access to information. The way we package Rotki is the double way. So we have an electron app that is available for Mac OS, Linux, and Windows. And we now support also Apple Silicon Macs. And then we have the Docker image, where you can deploy on a machine you control, and you can access it via web. Although you should be careful there, because Rotki was formally designed as a local app. So it would be better if you have a proxy in the front for security reasons. And then there is another way to run Rotki if you own DubNode. There is a DubNode package, and we are in close collaboration with DubNode, which makes things really easier. And we want to improve the experience there. So for example, we are working to make auto configuring your local nodes in Rotki automatic. So Rotki does portfolio tracking. At the moment, we support Ethereum, Kusama, Polkadot, Avalans, Bitcoin, Kus, and Bitcoin, along with a number of centralized exchanges and DeFi protocols. In the next release, we are doing work so that it makes it easier for us to support multiple VM chains. So slowly, we will start adding support for multiple VM chains, starting with optimism. So in Rotki, you can see your account history. Lefteris had a talk on Tuesday talking about how we do transaction decoding. Here, you can see how this looks inside the app. In this example, you can see me basically migrating 400 sites to die and then selling them for 1.7 nith on Kiber. Then we have accounting. Accounting in Rotki is customizable. We try to be as general as we can so that we can support as many jurisdictions. You can parametrize how you generate your PNL report. And then you can export a CSV that you can pass to your accountant and do your tax report. Another great feature we have is Ethereum staking. You can see your staker's performance. You can see your daily stats. And you can see aggregated information about everything. And another part of Rotki is insights. So we have graphs for statistics. Although they are a bit problematic because you have to open the app every day so that we don't rely at the moment on chain history because that's quite hard. Although we want to do that in the future. But at the moment, we depend on snapshots. So you have to open the app every day so that the app can collect these snapshots. This is important. If you value your privacy, please run a full node. It's really important for us. An easy way would be to get your DAB node, have your full node running GIF, or Ergon, or Nethermine. And then you can use Trueblocks as an indexer because in Rotki at the moment, we have a problem. Because there is no easy way to get an accounts transaction. We have to rely on Ifrscan. And this can be problematic from a privacy perspective because Ifrscan rates limits you. And you have to put an API key. And if you put an API key, you basically connect all your information, like your email address, your IP address, your accounts. And probably, they have a good privacy policy. But you have to trust them for that because they are close source software. So the best idea would be to have something like Trueblocks running and Trueblocks can index the chain and can detect a lot of these transactions, which can then fit to Rotki. And this way, you could do a really privacy-focused portfolio tracking and accounting. Plus, as a bonus, if you run Rotki on DAB node, you can access your portfolio through the VPN locally in your mobile device. So that's like we met the user using Rotki in such a way in Ifrscan, and it was a really happy moment because we don't actually have any documentation on how to do that. So it was really nice. I guess it went a bit fast. So yes. So if you want to reach out, you can reach out through Discord. And please, please, really, we built Rotki for the community. We built it for us and for other people. So it would be nice if you give it a try. Like download the app, run it, test it, give us feedback. We always hear feedback. And the way we build the app is based on the user's feedback. So please do and let us know. Then you can follow the Rotki app account on Twitter. Most of the times, it's Leveri's tweeting from there, not always. And you can also buy a premium subscription. It is a bit of support to us. Doesn't help us sustain the project, but it still helps us a lot. And with this, you can actually unlock the full Rotki experience because the free version has some limitations. Yes, so what's a bit fast? Thank you, Kelsus. Do we have questions in the audience? I'm liking a lot of these small projects, and I'm liking a lot of them. But I find them. I have, how do you finance Rotki? That's my question. The funding. Yeah, the funding. How is your, are you in freedom to release a business model? Because at the end of the day, you all have to eat. I know you have to eat. Yeah, exactly, exactly. So funding is really hard. Like I said, we currently have funding through Kitcoin Grants, which is one of our biggest sources of support. And then Lefteris is trying to find ways so that we can get grants or integrating with different protocols. So these, I think, are the main ways of funding and pay salaries. Of course, as an open source project, we do it out of passion. So our salaries are not the best. Like we are below market rate. But it's something we love to do. So yeah, it's hard. It's hard. And then we have the premium subscription. At the moment, our premium subscription is 10 euros per month. You can imagine how many users you would want to be able to sustain the project out of this subscription model. Hi. This might have been covered in the other presentation that Lefteris did. You said you rely on EtherScan for transactions. But I assume you've looked at things like the graph, which is more decentralized. What do you think of that? Yeah, so we use the graph. But in our use case, it's not a perfect fit. Because there is no unified model of the subgraphs. So for every protocol we support, we have to add a new subgraph. And this actually gives us a huge maintenance cost, because we have to go and implement on our side the schema, handle every subgraph in a different way. And then as soon as the subgraph breaks, we have to fix it, communicate with people that are maintaining the subgraphs. And then we have to release a patch release to fix that for our users, because the app is broken. And this is why we're trying to find a way that is more unified and more generic and that doesn't need the extra maintenance cost. Because the way the ecosystem works, new protocols pop up. And we have to support them, because our users also want the support for these protocols. So it's really hard for us to go and implement each subgraph for its protocol and become some maintenance help for our small thing. Thank you again, Kelsos. Thank you.