Data insights for the Djed Stablecoin
Building a dashboard
The Djed stablecoin protocol is something that has piqued my interests for a while. Maybe partly because I have a soft spot for Cardano projects, but also because, as an algorithmic stablecoin, it was able to survive the collapse of UST and Terra. I do not know the team behind the Djed protocol, but it is somewhat a testiment to them and their product that it is still around.
The economics of Djed is quite interesting, though it does have its drawbacks. My main critique is that it inefficiently uses liquidity. Normal conditions of the protocol require a reserve to debt ratio of 400% — i.e. the value of the ADA reserves must be greater than 4 times the circulating supply of Djed. This inefficiency is the cost this protocol has chosen to pay to ensure security and confidence. Whether or not there is a better or different way to do this, I am not sure — and it is not the purpose of this article to dive into that. If you would like to learn more, I encourage you to read their whitepaper (At least the Minimal Djed part as that is what is currently implemented I believe).
What I wanted to discuss here is my latest project which is intended to provide users live, and historical, metrics of the Djed protocol. I set my self this challenge to create a publicly available dashboard to push me out of my comfort zone and also demonstrate my ability to learn new things quickly. Because I do not plan on monetizing this project, I also wanted to make the site and all data freely available. For those that are interested, this article will detail how I built this project. Everyone else that just wants to see the end product — you can find it here.
Backend
I first needed a way of getting the data. I wanted to not only have live data but also historical, and ideally I wanted to bootstrap historical data so there was something to show from the beginning. Having read through the whitepaper, I knew everything I needed can be found at the reserve smart contract address. The only exception is historical ADA price. In Google Colab, I experimented with different python packages until I found one that had an appropriate Hobby plan and gave me access to the data I needed. For me, this was Blockfrost.
In order to get historical data to bootstrap this project, I could look at all the transactions of the reserve contract and using the utxos that returned to the contract, I could find the ADA, Djed, and Shen reserve values. Because these values cannot be modified without a transaction, this meant that I had accurate, historical data for these metrics. I now needed the ADA price at the time of each of these transactions. Because I didn’t want to pay, my options were limited. I found a csv file of historical ADA prices online, but because the timestamps of the transactions were irregular, I could not get the exact price at that timestamp. To solve this, I used the ADA price at the timestamp before and after each transaction timestamp and normalised them to average out a price. This worked well enough but it means my data before January 12th 2024 is not as accurate. Now that I had historical data, it was easy enough to convert these functions to grab the live values. Once I was happy with them in Colab, I deployed a serverless function on DigitalOcean (I chose this platform because I like their docs and already had an account). I had never done this before and it was a bit tricky my first time. For the benefit of others, I will leave the details of how to do this for another article.
Get Gavin Stein’s stories in your inbox
Join Medium for free to get updates from this writer.
For persistent data storage, I am using Firebase realtime database. I didn’t need anything fancy, and I wanted the overhead and learning curve to be minimal. Interacting with the database is easy enough with the python client. However, the firebase python package is unreasonably large and I could not include it in the virtual environment of my serverless function. So instead, I use the REST API to integrate. This required me to establish some security rules for writing data, and Bearer token Authorization. I have kept security for reading data open because I am making it freely available anyway.
At this point, I now had historical data stored in a database, and a serverless function reguarly updating it (twice an hour). It was now time to move onto the frontend.
Frontend
This is where I faced the steepest learning curve. I am comfortable with JavaScript and I understand how web servers work, but I had never implemented a project into production. I chose to use react and Next.js, and I mainly used TypeScript because of the static typing and to push myself. For styling I experiemented with a few CSS plugins and went with tailwindcss and NextUI. I thought these were great to pickup without much knowledge. I was planning on using Vercel to deploy the app, and using their serverless function architecture for any backend functionality I still needed. However, once I started building, I realised I did not need these at all and could rely on just a fetch() call when the page initializes. This did not affect security of the application because they were hitting publicly available endpoints anyway. Most of the time spent building the frontend was building functions to parse the data from the database and manipulate it for charts, or into other metrics from the whitepaper. I am really happy with how the charts turned out (I used ApexCharts), especially once I added the data overlay functionality.
Deploying with Vercel was surprisingly easy and once I bought a domain (the only cost I permitted myself for this project), connecting it was a breeze.
Learnings
I am so glad I did this project, I learnt more than I imagined about web development. I think for others looking to dabble in this area, react, Next.js and NextUI are great libraries to use. I would encourage you to use serverless functions too if you want something that has low cost and ongoing maintenance (so long as it works for your project). For databases, I’m not sure if I would reuse a firebase realtime database again. It did everything I wanted, but it felt a bit like putting a square block in a circle hole. I saw Vercel has some integrations with other popular database providers so I will experiement with them next time.
Future work
There are a few updates I want to make, mainly to the UI. I also need to add in SEO and make it mobile friendly to enhance its appeal and usability. Maybe in another project, or this one if I want to dabble in trading based on this data, I also want to deploy and connect my own smart contract.
