Truflation Oracle Update [Feb 2022] — Detailed Report

Today, Wednesday the 9th of February 2022, we’ve updated our Truflation Index and Oracle model to incorporate new data and improve the algorithm.

We have launched the Truflation with the idea that it needs to constantly improve across various aspects always to give the most accurate recent information available and become a viable and more unbiased alternative to governmental inflation indexes.

To that end, we are optimizing data and processes around 5 main pillars of Truflation:

1. Raw data
2. Calculation model
3. Oracle algorithm(s)
4. Quality control
5. Decentralization

The implemented changes do not have a significant impact on the raw daily CPI numbers available through the Chainlink Oracle.

However, they do affect the year-over-year % change we have been reporting on our social media, at the difference of ~(-0.7%).

In the current update, we are implementing the following:

1. Raw data

Changing data sets and data points to improve accuracy, frequency, and comparability of data.

We are constantly looking for:

• more data sets and data points to substitute the flawed and outdated government data points
• more data sets per each data point for redundancy, accuracy, and decentralization
• new data providers with the most accurate, granular, scalable, and frequent data updates

We’ve now updated the following data sets across various categories:

Rent category — some data points changed due to calculation model updates with our Pennsylvania State University data provider. The research institute is constantly updating and improving its models, which often means a change to both current and historical numbers.

Food category — data points will change due to an identified code bug. The error in the algorithm was comparing data from 2022 with data from 2020 instead of 2021. The year difference increased the results of the YoY % reported on social media but not the raw daily CPI served through the oracle.

Other categories — All other data will now update whenever providers change their historical numbers.

2. Calculation Model

2a. Corrected small relative importance errors.

Running a quality control audit, we noticed small discrepancies between relative importance in three categories in the basket. The errors were introduced when inputting the weights between the calculation model and the oracle algorithm. They have now been corrected.

2b. Amended the structure of data categories for better scalability.

Using this opportunity to push a bigger update into the oracle, we also introduced small changes into the division of our categories that will help scale the index in the future:

• Divided the Rent category into Owners Rent and Tenants Rent. Currently, the numbers come from a single provider (Penn State University), and the sum remains the same. However, we are working on getting separate alternative data for both categories.
• Divided the Energy commodities category into 3 separate categories.

3. Oracle algorithms

Changing the oracle algorithm to incorporate the most recent calculation model changes and fixtures.

As mentioned above, we made some changes to the calculation model around weights and categories that were then introduced into the oracle’s algorithm.

We also fixed the food category bug that was comparing one data category 2 years apart.

Finally, we enabled the oracle’s historical data changes with each oracle query to better calculate the year-over-year percent change.

Coming from a blockchain background, where recorded data remains immutable, we temporarily froze historical changes when we noticed some small historical fluctuations. After designing and performing a quality control audit, we realized many changes stemmed from our data providers revising their data sets across historical data. Since then, we also learned it is a common practice among data providers, both data aggregators and data generators like large shops reporting on their own data, to constantly improve their data sets and/or calculation methods.

To address this, we now have a new strategies in place:

• an on-chain record of timestamped, immutable inflation rete on the day of acquisition that is the same as the data we release daily throughout our social channels
• an oracle algorithm, that with every query, recalculates the most recent available data for today vs. a year ago
• a record of historical changes to our data

For the time being, we will not be releasing the historical data to the public.

The daily data is available through our Chainlink oracle and the year-over-year % change is also communicated across our social media.

For the daily data accuracy and comparability, we are making sure that each newly introduced data set has data points available for at least 13 months into the past to create a complete the CPI query that includes:

• the raw CPI today,
• the raw CPI a year ago,
• and a YoY % difference.

4. Quality control

Last month we created a multi-step quality control process that helped us quickly identify potential errors and missing data in the data APIs, as well as discrepancies between APIs and scraped data.

In the future, we are considering automating the process and potentially allowing it to run on the protocol nodes as the automated or semi-automated validation process. It is possible that not all issues of data quality and veracity could be automated, so the model might be further supported by manual validation incentivized by our token rewards.

5. Decentralization

In the future, we plan to further improve oracles data decentralization by introducing hundreds of data sets data and obtaining redundancy that allows us to apply algorithms that average the results, flag and exclude outliers and help semi automate or fully automate the quality control processes, and perhaps execute them on the protocol nodes.

One obstacle in this route is the cost of acquiring information from independent sources like data aggregator and corporate businesses selling data.

Our solution is a robust self-sustainable tokenomics and a business model that covers the data cost. In the future, we also want to acquire data from the users willing to share information through a functional incentive design.

In summary, we are focused on constantly improving the Truflation Index and Oracle to bring it closer and closer to the true inflation measurement. This is the first big index update out of many to come.

Join our community on Telegram

Follow us on Twitter

Read our Whitepaper

Start building with Truflation oracle on Chainlink