The following piece is the publication of personal notes I took while blueprinting a decentralized inflation oracle. Although the design is incomplete, I found the insights to be interesting and thus worth sharing. You can find the raw notes here and the ETHGlobal HackMoney entry here.

– Me

Aletheia - An Inflation Oracle

The inflation Oracle is the project with which I started my crypto journey. I was and still am, motivated by problems that I understand, that keep me awake at night. I named it Aletheia, after the personified spirit (daimona) of truth and sincerity in ancient Greece.

It started with a tweet by @balajis, who discussed the importance of a decentralized and censor-resistant inflation oracle. That oracle would report the current inflation on-chain, creating an indisputable log. Inflation is vital as it accurately shows the true wealth that society has. It’s no good to be a billionaire (on paper) if you live in Zimbabwe [1].

What we need: a censorship-resistant inflation Feed. The on-chain, crypto oracle version of MIT’s Billion Prices Project. No editorialization, just an undeletable history of prices. Build it pseudonymously. Build it with an eye to a ban. Build it now so it’s ready then.

– @balajis [2]

Although I am very against the “blockchain-everything” movement, this application made sense. Assuming it’s as important as we claim it to be, it would be primed to be censored and misreported, as there is an incentive to do so by both Government and big media. Government bodies have already been caught red-handed, falsifying statistical data to support their policy, such as in Greece, which falsified growth and debt markers to get into the Eurozone. [25].

It’s that incentive that forces us to consider the feasibility of a decentralized inflation oracle which:

• does not depend on centralized secondary data (reports from raw data) and
• is not easy to censor

Our goal is to build a Hyperstructure [3] that computes one of the most critical metrics of our well-being in a way that’s accessible and verifiable by all.

A Hyperstructure is a type of infrastructure with the following characteristics:

• Unstoppable - can’t be stopped by anyone (thus non-upgradeable)
• Free - 0% protocol fee, except blockchain gas costs
• Valuable - accrues value
• Expansive - built-in incentives
• Permissionless - universally accessible and censorship-resistant
• Positive Sum - win-win environment for participants
• Credibly neutral - user-agnostic

The end goal is to make something genuinely permissionless. A global system that incentivizes and keeps track of a fundamental metric of human prosperity.

The goal is to make it hard enough so that they don’t bother.

What’s Inflation, and how is it measured

Reading IMF’s definition [4] of inflation, it’s the rate of increase in prices over a given time. It can be as broad as the increase in the cost of living in a country, or it can be more narrow and concern certain goods, such as food or services. It represents how much more expensive the relevant goods and services became over a certain period, usually a year.

To measure the average consumer’s cost of living, government agencies conduct household surveys to identify a basket of commonly purchased items and track the cost of buying this basket over time. The cost of this basket at a given time expressed relative to a base year is the consumer price index (CPI), and the percentage change in the CPI over a certain period is consumer price inflation, the most widely used measure of inflation.

The case for decentralizing inflation estimation

Inflation affects everything, as the infamous Arthur Heyes noted [5]:

The end game of rampant inflation is always war and/or revolution. Show me a regime change, and I will show you inflation. When you work your ass off only to stand still or get poorer, any “ism” that promises affordable food and shelter for the unwashed masses will reign supreme. If you are starving to death, nothing else matters except Feeding your family. The symptoms of inflation are populism, social strife, food riots, high and rising financial asset prices, and income inequality. (..) Invest wisely and you can maintain or increase your standard of life against the rising fiat cost of energy. Invest poorly and the road to serfdom is real. You will find yourself working harder for a declining standard of living, and your fiat earnings and assets will not be able to keep up with the rising fiat cost of energy.”

– Arthur Hayes

The issue arises when we come to terms with the fact that inflation is not always reported accurately. Either because the official bodies fail to accurately respond to extraordinary events, such as the COVID crisis [38], or because it is in their best interest to falsely report inflation [6]. The second is particularly important, as the Government has an incentive to lie about the real inflation. Of course, Argentina is not the only example of a country [37] that falsified official statistics reports.

A more recent example that made ripples through the world is the inflation in the US, in which the Federal Bank admitted that not only was it miscalculated, but also it was wrongly labeled as “transitory” [7], [8]. Now, it is acknowledged but labeled as unimportant, while we have the first signs of a recession [9]. Finally, the US government misreported all together the Inflation for July 2022 [47] by literally changing the definition to account for a Month-on-Month change in inflation over the usual Year-on-Year. Of course, it was called out, but it begs the question of what will happen if inflation worsens as the world becomes less stable.

It’s worth noting that this is not just some fear-mongering of some minority of the general public. As the famous economist Robert J. Shiller notes in the not-so-distant 1995, in a fascinating study [40], inflation is always top of mind to everyday people. Everybody seems to understand its perverse effects on daily life, even if there are differences regarding how one should tackle inflation or who is responsible for it.

Turning the Inflation index into a product

Using the inflation index as a data point to create products is not a novel idea. It is already used in Traditional Finance for quite some time, namely as Inflation-Indexed bonds [41] or Treasury Inflation-Protected Securities (TIPS) in the US.

As we read from Investopedia [10], TIPS are designed to protect investors from the adverse effects of rising prices over the life of the bond. As the CPI measures, the par value increases with inflation and decreases with deflation. When TIPS mature, bondholders are paid the inflation-adjusted principal or original principal, whichever is greater. The obvious issue with such products is that they use a CPI index whose integrity we can’t verify for ourselves. Moreover, the CPI is not as reflexive, as it’s measured monthly at best (versus a daily metric).

A sketch

We will talk about:

• Inflation estimation using online prices
• The Oracle problem The proposed architecture of the oracle and the off-chain Agent
• Next steps

Buckle up, Anon.

Inflation Estimation

To estimate inflation, we will be standing on the shoulder of Giants, with Professor Alberto Cavallo from the Billion Prices project [11], [16], [39] leading the charge. In essence, we will be using daily data from online sources to build an index that we will use to compute the real inflation. In essence, we will scrape the price of these items frequently and observe the price differences.

The promise of “The Billion Prices Project” is monumental because it enables regular citizens to calculate a whole country’s inflation accurately. You no longer need substantial capital to perform on-site market research. Still, you can lean on an open-source community to produce the scraping targets and then do the scraping and calculations using readily available hardware.

We apply the “Don’t trust, verify “ mantra to inflation statistics.

Additionally, it has a few benefits [33]:

• The high frequency of data collection enables us to observe short-term patterns
• The online index is built with all the items the retailer offers during data collection. That means that the basket of goods changes as products appear and disappear, making it more accurate.
• There are no forced product substitutions. Products affect the index while they exist, without the complexity of having to replace them with an analog when they are removed from circulation.

Building the Inflation Index

Price changes are calculated at the product level and then averaged inside categories with a weighted arithmetic mean [6], [34].

Three steps produce the following data points, with every stage using the information from the previous one.

• A price change, per item, per time unit (e.g., day)
• A category-level index, per category, per time unit
• A supermarket index, per retailer, per time unit

When way category, we refer to the standard Consumer Price Index (CPI) category classification, as found in various literature and official websites, such as the US Bureau of Labor Statistics[53]. Every product is classified into a relevant category, such as “Cereals and bakery products,” which can be classified into more broad categories, such as “Food”.

We will group products into the former, more specific categories in the calculations.

In practice:

Step 1

Obtain the unweighted geometric average of price changes in category \(j\) for each day \(t\):

Where:

• \(p^i_t\) is the price of good \(i\) at time \(t\)
• \(n_{j,t}\) is the number of products in category \(j\) that are present in the sample that day

Step 2

The second step is to compute the category-level index at \(t\).

Step 3

Finally, the supermarket index is the weighted arithmetic average of all category indexes:

Where:

• \(w^j\) is the official CPI [53] for that category
• \(W\) is the sum of all the weights included in the sample.

That \(S\) value is what we want to find its way on-chain. It compresses the information about daily inflation into a singular index.

Real data example

Based on data obtained by prior work [6], [12], for the United States, we can make the following stipulations:

data:

• 10.2 million observations over 827 days. That’s about 12.334 observations per day.
• 30.000 products
• 22 Categories
• 241 URLs
• 1 Retailer

This produces:

• 12.334 price changes \(R^j_{t, t-1}\) per day, where \(j\) is the category and \(t, t-1\) refers to the current and previous time indices, respectively
• 12 \(I^j_t\) category-level indexes per day, where \(j\) is the category and \(t\) is the time index
• 1 Retailer Index \(S_t\) per day, where \(t\) is the time index

For the United States, there are ample statistics available regarding the national CPI indexes [13], [14].

Product Classification

The classification of products and the weighting of categories is one of the most complex parts of this process. We need to build an index of hundreds of products that includes the following information:

• product page: A URL to a specific product at a specific seller
• product unique id: A globally unique ID for this specific product at this specific seller
• product selector: A selector that will be used by the scraper to “find” the price, usually a CSS selector or a regex
• product CPI category: The CPI category that this product belongs to

For example, let’s create a classification, in the form of a JSON object, for Frozen Camel milk sold on Amazon:

{
    "productPage": "https://www.amazon.com/Desert-Farms-Camel-Milk-Frozen/dp/B07P2MC4D4/ref=sr_1_3?crid=371ABCU2GZ7QE&keywords=milk&qid=1658995356&sprefix=milk%2Caps%2C389&sr=8-3",
    "id": "035e6d41-9eed-40f4-8c4b-a921ddc71241",
    "cpiCategory": 12
    "selector": {
        "path": "#corePriceDisplay_desktop_feature_div > div.a-section.a-spacing-none.aok-align-center > span.a-price.aok-align-center.reinventPricePriceToPayMargin.priceToPay > span:nth-child(2) > span.a-price-whole",
        "type": "cssSelector"
    }
}

Imagine a JSON object like the above for every product we intend to use in our measurements.

I envision the index to be built and maintained by the open-source community (e.g a DAO) that will align around this project. I expect it to be a time-consuming enterprise, but otherwise not very complex as the products and their categories are well defined.

Based on comments from Alberto et al.[6], when choosing the retailer (e.g., supermarket), we will need to select an adequately-large supermarket chain that has a considerable percentage of the market. Ideally, we want a chain that is present in most regions of the country so that we avoid local prices. This will reflect the nationwide accuracy of its prices. Finally, multiple supermarkets will offer an even more accurate view of the situation, but this increases the difficulty of the endeavor.

Product Scraping

Product scraping can be trivial with the appropriate css selector and a performant scraper.

A scraper, in our use case, can be as simple as a little program that receives as an input the url and the css selector of a particular product and returns the current price for that product.

It could be as simple as the following naive program in Rust:

use csv::Writer;
use reqwest;
use scraper::Html;
use scraper::Selector;
use select::document::Document;
use select::predicate::{Attr, Class, Name};
use std::fs::OpenOptions;
use url::Url;
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let mut handles: std::vec::Vec<_> = Vec::new();
    let target: String =  String::from("https://www.amazon.com/RICA-Listamilk-Vitamin-refrigerated-pasteurized/dp/B087JZQW2R/ref=sr_1_6?_encoding=UTF8&c=ts&dchild=1&keywords=Dairy+Milks&qid=1627806697&s=grocery&sr=1-6&ts_id=6520438011");
    let selector: String = String::from("#priceblock_ourprice");
    let scraper = Scraper::new();
    let job = tokio::spawn(async move { scraper.scrape_website(&target, &selector).await });
    handles.push(job);
    let mut results = Vec::new();
    for job in handles {
        results.push(job.await);
        println!("{:?}", results);
    }
    Ok(())
}

pub struct Scraper {
    client: reqwest::Client,
}

impl scraper {
    pub fn new() -> Self {
        Self {
            client: reqwest::Client::new(),
        }
    }
    pub async fn scrape_website(
        &self,
        url: &str,
        selector: &str,
    ) -> Result<(), Box<dyn std::error::Error + Send + Sync>> {
        let url = Url::parse(&url)?;
        let response = self.client.get(url).send().await?.text().await?;
        let document = Html::parse_document(&response);
        let selector = Selector::parse(&selector).unwrap();
        for element in document.select(&selector) {
            println!("element: {:?}", element.inner_html())
        }
        Ok(())
    }
}

Reference Architecture

The design is very modular and can easily be decomposed into four distinct systems:

• Off-chain Agent: Responsible for computing the inflation index and posting it on-chain.
• Oracle: Responsible for
  1. digesting the inflation index(or indexes)
  2. compute the canonical Inflation
  3. serve it to other consumers
  4. incentivize the off-chain Agent Feeds, to be honest players.
• DAO: A DAO responsible for managing said the oracle, steers the inflation-adjusted DeFi products, and more.
• DeFi stack: A stack of DeFi products that leverage the ability of the system to “know” the current inflation of various countries.

Off-chain agent

The off-chain Agent should:

• be as performant as possible, enabling users to run it on minimal hardware
• be easy to set up and get it running, ideally by people with low technical expertise
• be installed/setup in a clearly defined and reproducible manner

To that effect, I started an alpha implementation written in Rust and packaged in a docker container. The container image should have as many sane defaults as possible and be turn-key for most intents and purposes. Although I made various designs regarding the Agent, I find that they are unimportant.

The most important aspect of the Agent must be:

• the efficient scraping of thousands of products per day
• the efficient archival of the data points

Although the Agent will submit a single data point to the blockchain, it should store the raw data in a manner that would be publicly accessible.

Assuming that the data points are stored in a standard and simple format, such as CSV file, we can forecast that ~13.000 observations (data points) (see the example above) will consume about 1.2-2Mb [24] of storage daily, creating a total of about 680Mb per year.

Using various decentralized services for Data Availability or storage, it should be economically feasible for the user to keep a public record of all the raw data they have aggregated, adding more transparency for all system actors. We choose the following services because we want the added benefit of making it hard to censor them.

• Filecoin [17]
• Arweave [18]
• Celestia [19] – It’s worth noting that Celestia is vastly different from the other two solutions. For reasons that we will not go into, it might be an interesting avenue to explore, so I am adding it anyway. Sue me
• Radicle [44] – A p2p network based on Git for code collaboration. The ability to have discussions and link to specific lines of the metadata and a very clean and easy-to-audit log of the history could be an interesting avenue to explore.

The Oracle

Before we discuss the system’s oracle, let’s quickly revisit the oracle problem. The Oracle problem is one of the significant challenges in the broader cryptocurrency space. It’s the general question of how to add arbitrary real-world data into a blockchain and use that data in a dapp. The problem is that the blockchain cannot verify the accuracy of said data natively. Ethereum can’t know if the “price” of ETH is $1800 or $6000, so the apps have to trust the actor that inputs the data about their integrity.

The most accepted design space for this problem is to tackle it using game-theory schemes. We create a system in which a rational actor is rewarded for supplying correct data and punished if the data is false.

In our system, we need an oracle consisting of a set of smart contracts that receive the indexes by the agents and compute the system’s inflation index. The Oracle has been modeled after the MakerDAO [28] Oracle Module [20].

Let’s see them at a high level.

Existing Oracles

There are many Oracle projects in the market. Although things could have changed since Ι did this research, I didn’t love any of them, as they suffered, in my mind, from a case of decentralization theater. Essentially, they were just a couple of bonded validators agreeing to something.

Maybe that’s the only viable solution, but my issue is that it’s impossible to correctly evaluate the bond as the sole incentive against malicious activity. With DeFi being a lego playground, the second and third-order effects are impossible to measure accurately.

I opted not to use Chainlink (the leader in the space) for two simple reasons:

• I didn’t like Chainlink’s army that used to roam Twitter, spamming and harassing anyone who would express an unfavorable view of their tech. I think that it’s no longer the case, but then it was over the top
• I did some research on the first principles of the system, and it didn’t have the security and decentralization attributes that I was looking for [21], [22], [23].

It’s worth mentioning that creating your own Oracle solution proved a feat, so it’s critical to evaluate the required effort and the security assumptions you are making over simply using a solution off the shelf. It’s equally unclear whether a homegrown solution will be “better” than the existing ones since it’s fundamentally a complex problem to solve. Maybe it makes more sense to use a solution off the shelf and factor that into the security model.

I don’t have a clear answer on that, so here are a few oracle providers worth looking into:

• API3 [35]
• Chainlink [31]
• Tellor [45]
• Witnet [36]
• MakerDAO’s Oracle [46]

MakerDAO’s Oracle

It’s worth discussing how Maker’s Oracle works, as I modeled my proposed solution after theirs.

The oracle agents talk off-chain in a p2p fashion (using a protocol named Scuttlebut [26], gossiping about the values that they gather. Thus, all agents know all other Agent data feeds under regular operation and without significant network issues. Some agents may run an additional “ Relayer “ program and are responsible for grouping the values from these Feeds and submitting the data to the Oracle smart contract.

In short, their current implementation has two modules:

• Feed: Each Feed runs a Feed client which pulls prices through Setzer, signs them with an Ethereum private key, and broadcasts them as a message to the secure scuttlebutt network. Setzer [48] is a service developed by MakerDAO, that reads API endpoints from various known exchanges.
• Relayer: Relays monitor the gossiped messages, check for liveness, and homogenize the pricing data and signatures into a single Ethereum transaction.

The smart contract then takes the median value of the submitted values and considers that value to be the “view” of the MakerDAO system for the world. The deal is submitted with a considerable delay so that the DAO has time to react in case of Oracle’s malicious action. Currently, the Oracle system works with a quorum requirement. For a price to be updated, 13 out of 25 Oracle Feeds must submit data[].

The system must allow the agents to participate in the design, a process that is conducted through the Governance process of MakerDAO. The oracles are run by organizations and reputable individuals in the community. While the organizations are known, only 2 of the individuals are.

Our own Oracle

Now that we have a helicopter view of the MakerDAO’s oracle, let’s look at a high-level overview of the adapted design for our use case:

• Aggregator.sol: The ingress smart contract that is used by the Feeds to submit their inflation index
• Security.sol: Adds a delay to the Oracle Feed so that the system has time to respond to malicious entries
• Mesa.sol: Stores the vital information about the Oracle, admin interfaces for the owner - the DAO
• Reward. sol’Calculates the withdrawal of every inflation Feed

Aggregator

• It’s responsible for aggregating the index from the agents. Agents simply call a public function on the contract and submit an uint256 value
• It’s modeled after the MakerDAO’s median.sol [42] smart contract
• It computes the median value from all the submitted values

For example, this is how median.sol computes the median:

    function poke(
        uint256[] calldata val_, uint256[] calldata age_,
        uint8[] calldata v, bytes32[] calldata r, bytes32[] calldata s) external
    {
        require(val_.length == bar, "Median/bar-too-low");

        uint256 bloom = 0;
        uint256 last = 0;
        uint256 zzz = age;

        for (uint i = 0; i < val_.length; i++) {
            // Validate the values were signed by an authorized oracle
            address signer = recover(val_[i], age_[i], v[i], r[i], s[i]);
            // Check that signer is an oracle
            require(orcl[signer] == 1, "Median/invalid-oracle");
            // Price Feed age greater than last medianizer age
            require(age_[i] > zzz, "Median/stale-message");
            // Check for ordered values
            require(val_[i] >= last, "Median/messages-not-in-order");
            last = val_[i];
            // Bloom filter for signer uniqueness
            uint8 sl = uint8(uint256(signer) >> 152);
            require((bloom >> sl) % 2 == 0, "Median/oracle-already-signed");
            bloom += uint256(2) ** sl;
        }

        val = uint128(val_[val_.length >> 1]);
        age = uint32(block.timestamp);

        emit LogMedianPrice(val, age);
    }

Security

• It’s responsible for adding a delay to the Oracle’s data Feed, so there is time to mitigate an attack
• It follows MakerDAO’s structure of the Oracle-v2 osm.sol [43] module
• With every epoch, it gets an update from the aggregator](#aggregator). Every update makes the previous epoch’s value available to the rest of the system. In other words, the system has a full epoch (a day) to deal with a bad input to the system

Mesa

It’s the very core of the Oracle. I expect Mesa to be the smart contract that interfaces the Oracle with the DAO Governance system, exposing various useful admin functions that only a single address can invoke.

It serves as an index of all the essential information that concerns the system:

• Target URLs for products: An array of JSON objects, as mentioned in the product classification section
• Inflation taxonomy (retailer, country, product category, CPI weights), for example:
  • Retailer: Amazon
  • Country: US
  • Category: food and non-alcoholic beverages
  • CPI weight: 13.52 (for July 2022)[54]
• Whitelisted Ethereum addresses: Addresses that are allowed to submit inflation data
• Owner: Address that can invoke various admin functions. Probably a Gnosis multi-sig or a Compound-style executor
• Based Feed Reward: The base reward for every Feed is discussed below](#gifter)

While we can store the addresses and the rewards on-chain, we can’t keep the rest of that data due to their sheer size. Thus we need to store them somewhere else and then anchor them to the mesa contract.

An idea could be to use something like Arweave (mentioned above), where every individual inflation Feed will pay to host the data and then submit the location_hash to the mesa smart_contract.

A note on Security Models

By using Arweave (or any similar protocol), we expose our system’s security model to that protocol’s. It means that we make a judgment call, acknowledging that protocol as secure enough for the system’s security model we have defined. Of course, if Arweave goes down, we will lose the raw data, and our system’s Governance will need to kick in and find a solution. It’s important to remember, in my opinion, that the final arbitrator of all systems is the social layer, and that’s natural. All these systems and protocols are technological as much as they are anthropological. They are being used and being given purpose and meaning by humans.

The above information can be summarised in the following data structure, in the form of a Solidity struct:

struct OracleInformation{
    string locationHash; // IpoZqWlXiHk3RFaKPTrWKjmCL-s9kcGkuVB4I_D4MRs
    string locationService; // "arweave"
    address[] whiteListedAddresses; // [0x]
    uint256 basedFeedReward; // 100
    mapping(uint8 => uint32) cpiCategoryToWeight // 8.165 = 8165000000000000000 with ERC20-type 18 decimals precision
    address owner;
}

Gifter

It’s responsible for rewarding the Feeds for submitting inflation indexes.

• Computes the rewards for each Feed
• Transfer the reward from the Oracle’s treasury to itself and it available for withdrawal by the Feeds

Reward Formula (Naive Approach)

Use a Euclidean distance [30] from the median as the reward:

Distance

We compute the Euclidean distance between the index supplied by every Feed and the median index chosen by the Aggregator:

Where:

• \(p\) is the median index chosen by the aggregator
• \(q_i\) is the inflation index supplied by every Feed \(i\).

Reward

Where:

• \(T\) is a threshold value set by the Oracle
• \(R_i\) is the reward for Feed \(i\)

DeFi - DAO

I never reached that part of the research, but the most obvious that came to mind was a stablecoin[51] that is stable in the sense of purchasing power, like Volt [56]. It’s an integral part of the solution, as it would render this project viable from a business perspective. It’s a big part of the puzzle and the most lacking in this sketch.

Envisioned Roadmap

The very first step is to ship an MVP of the scraping Agent and align people around this project. While the Agent is being built, work should begin in creating the first list of items (and their relevant metadata) in a way that is open and permissionless (e.g., through a GitHub repository). Through public deliberation, we should arrive at the first list of items that, when fed into the Agent, should start producing daily inflation indices.

Then, it’s time to start building the Oracle and smart contract part of the system, so we have a provable record on-chain.

In short, here is how I would go about it:

• Build Agent MVP: Given a list of targets, scrape product prices and store them on a CSV file
• Build a Product target list for a specific region/country
• Launch MVP of the Oracle tied to a multi-sig Governance
• Address decentralized storage of Agent’s config (target list, etc.)
• Launch Governance, Token, DeFi product
• Launch Agent (stable, easy to install, etc.)

Open Questions

When doing research, I always like to note questions that are still open. Essential matters of research that, for some reason, I can’t dive into right away, but I report them for a later time. In the words of Donald Rumsfeld[], these are known unknowns.

• Do we need a single “canonical” inflation value, or can the Oracle function as an index of Feeds that users (or smart contacts) can choose to follow based on some arbitrary definition of “reputation”
• What should be the mechanism around the reward/punishment of Feeds based on their accuracy
• What should be the mechanism around whitelisting (or not) Feeds to participate in the Oracle
• How viable is it to maintain a classification index of hundreds or thousands of products What are the security assumptions that we are willing to make, and is it worth solving the Oracle problem ourselves, or it’s better to use an off-the-shelf solution
• What are the **helpful ** DeFi products that we can build once we have an accurate indicator of the inflation on-chain

About Privacy

In the case of the crackdown, privacy will be essential in keeping the system operational. Recently, OFAC sanctioned Tornado Mixer [49], which not only resulted in the black listing of addresses that interact with the smart contracts of the service but also the arrest of one of the contributors [50] in the Netherlands.

An inflation oracle, if sufficiently widespread, can be branded as a source of misinformation and thus deemed dangerous or even illegal. With that in mind, we need to be prepared and bake into the system design solutions that enable the users and inflation Feeds to become fully anonymous without leaking any private information, such as IPs.

The following areas should be concerned:

• RPC endpoints for interacting with the blockchain, namely Ethereum. With big RPC providers complying with OFAC. We should consider alternative backups from the start
• The censorship resistance is also a restriction for the kind of blockchain used. Although it would be exciting to test the capabilities of L2s, that would significantly increase the functionality we can implement on-chain. All of them are currently centralized and thus prone to censorship. It’s something worth revisiting once they are decentralized in good time.
• Privacy-enabling services for interacting with said RPC endpoints, so no IP is leaked. Tor or similar VPNs could be of help here.
• If Feeds communicate in a P2P manner (similar to MakerDAO’s oracles), protocols such as Scuttlebutt are not private. Although the ID is a public key, IP will naturally be leaked in the interaction. That means that Feeds will again need to interact behind some kind of VPN or Tor.

The case for using Urbit (and how that could look like)

Urbit is an exciting extension to the above discussion about privacy. I have discussed Urbit in a previous blog post. Still, to give you a TL;DR, Urbit is an entirely new VM that runs an entirely new OS and “exists” in a p2p network with a completely new networking and ID system [52].

There are two ways to use Urbit as part of our solution:

1. Develop the entire Feed to run on Urbit, as an Urbit app
2. Use Urbit as an add-on and leverage the Urbit ID and P2P network
3. Use Urbit as-a-user to coordinate the social layer of the protocol

The first option adds considerable effort and delay to the project, as one has to learn and reason about an entirely new (and vastly different) OS and programming language (Hoon).

The second and third options are far more feasible and could potentially have compelling extensions. In my view, Urbit has nailed two exciting concepts:

• A digitally scarce identity
• A p2p network built on that identity

Without going into much detail, an Urbit ID is scarce as it’s a finite resource (vs. an Ethereum public address that is infinite). Thus, it costs something to acquire, adding a form of Sybil resistance to the identity system. On top of that, we have a P2P network called Ames[55], which is end-to-end encrypted based on that Urbit ID. Only the recipient Urbit ID can decrypt and read a message intended for itself. Thus, every Feed could potentially be tied with an Urbit ID and require that at the protocol level.

Reputation

With a provable identity, we could explore reputation schemes, where Feeds are not rewarded at the protocol level by a specific formula, as described in the Gifter. Based on their reputation, downstream users can elect to follow the inflation metrics produced by specific Feed(s).

P2P network

Suppose we elect that the Feeds should participate in a P2P network to gossip information (like MakerDAO oracles). In that case, we could use the Urbit network instead of Scuttlebutt and leverage the ID again scheme that is part of the network’s protocol.

Social Layer

Considering the censorship resistance, we want to build it into the system. The social layer must also use anon-friendly and resistant tools. Using Discord and Discourse, the usual platforms for social layer consensus, is a no-go, at least in case of a severe crackdown. Urbit’s first app (it’s the killer app if you will) is a Discord replacement, enabling users to use their Urbit, Urbit ID, and Urbit network to communicate. An Urbit will host a discord-type server, and others may join and discuss, using the P2P network to send all traffic and the Urbit ID as their in-network identity.

It’s impossible to limit the use of Urbit, as Urbit’s traffic is encrypted p2p, thus is not possible to know what Urbit’s are tied to what accounts and messages. For extra anonymity, if you put Urbit behind a VPN, no one can connect an Urbit ID to a particular IP, increasing the difficulty of finding real-life people behind the Urbit IDs. On top of that, all Urbit’s network activity is encrypted and packaged in simple UDP packets. The VPN can’t inspect the content of messages, forcing the attacker (e.g., a nation-state) to use Urbit and try to find the Urbit IDs of the perpetrators and try to tie distinct UDP packets to that ID. Finally, finding an Urbit group is impossible unless you are invited to it, or someone shares the Urbit address. Like real-life communities, a high-trust, very close community will be very hard to be penetrated by actors and thus impossible to tie individual Urbit IDs to the Inflation Oracle governance.

Call to Action

What are you waiting for, Anon? Inflation is rampant globally, and it’s only a matter of time before we stop getting accurate information.

Build it!

References

1. The 1 billion Zimbabwe dollar bill. Accessed July 4th, 2022.
2. @balajis twitter. Accessed July 31, 2022.
3. Hyperstructures. Accessed July 31, 2022.
4. Inflation: Prices on the Rise. Accessed July 31, 2022.
5. Pumping Iron. Accessed July 31, 2022.
6. Cavallo, Alberto. “Online and Official Price Indexes: Measuring Argentina’s Inflation.”Journal of Monetary Economics 60, no. 2 (March 2013): 152–165.
7. Bloomberg - Powel ditches transitory inflation tag. Accessed July 31, 2021.
8. Reuters - Fed’s Powell floats dropping “transitory” label for inflation. Accessed July 31, 2021.
9. Financial Times - Is the US in a recession? Measuring the slowdown in the world’s largest economy. Accessed July 31, 2022.
10. Treasury Inflation-Protected Securities (TIPS). Accessed June 28, 2021.
11. Billion prices project. Accessed July 31, 2022.
12. Cavallo, Alberto. “Scraped Data and Sticky Prices.”Review of Economics and Statistics 100, no. 1 (March 2018): 105–119.

13. Archived Relative Importance of Components in the Consumer Price Indexes. Accessed July 6 2021.

14. US Bureau of Labor Statistics. Accessed July 31, 2022.
15. Wikipedia page on the “Known Knowns” phrase. Accessed July 31, 2022.
16. Cavallo, Alberto, and Roberto Rigobon. “The Billion Prices Project: Using Online Prices for Inflation Measurement and Research.”Journal of Economic Perspectives 30, no. 2 (Spring 2016): 151–178.
17. Filecoin. Accessed July 22, 2022.
18. Arweave. Accessed July 22, 2022.
19. Celestia. Accessed July 22, 2022.
20. MakerDAO Oracle Module. Accessed July 22, 2022.
21. Niklas Kunkel, 2021. “ChainLink Oracles for LINK-USD”. Post number 21. Accessed June 28th, 2021.
22. Niklas Kunkel, 2021.Response to ChainLinkGod Accusations. Accessed July 3rd, 2021.
23. Eric Wall, 2021. “What’s Wrong With the Chainlink 2.0 Whitepaper? (For Simpletons)”. Accessed June 28th, 2021.
24. Approximating data set csv size. Accessed July 5th, 2021.
25. Greece condemned for falsifying data. Accessed July 3rd, 2021.
26. Scuttlebutt Protocol. Accessed June 28 2021.
27. MakerDAO oracles-v2 GitHub repository. Accessed June 28 2021.
28. The Maker Protocol: MakerDAO’s Multi-Collateral Dai (MCD) System. Accessed June 28 2021.
29. Robert J. Shiller. The Next New Thing in Finance — Bonds Linked Directly to the Economy, The New York Times, accessed at June 28 2021.
30. Euclidean Distance. Accessed July 2 2021.
31. Chainlink. Accessed June 28 2021.
32. Consumer Price Index. Accessed July 6th, 2021.
33. Cavallo, Alberto. “Are Online and Offline Prices Similar? Evidence from Large Multi-Channel Retailers.”American Economic Review 107, no. 1 (January 2017): 283–303.
34. Weighted Arithmetic Mean. In: The Concise Encyclopedia of Statistics. Springer, New York, NY, 2018. https://doi.org/10.1007/978-0-387-32833-1_421
35. API3 homepage. Accessed July 31, 2022.
36. Witnet homepage. Accessed August 6, 2022.
37. Cavallo, Alberto, Guillermo Cruces, and Ricardo Perez-Truglia. “Learning from Potentially Biased Statistics: Household Inflation Perceptions and Expectations in Argentina.” (pdf) Brookings Papers on Economic Activity (Spring 2016): 59–108.
38. Cavallo, Alberto. “Inflation with COVID Consumption Baskets.” NBER Working Paper Series, No. 27352, June 2020. (Revised October 2020. Harvard Business School Working Paper, No. 20-124, May 2020)
39. Alberto Cavallo, 2016.The Billion Prices Project Using Online Prices for Inflation and Research. MFM Conference - NYU
40. Robert J. Shiller, 1996. “Why Do People Dislike Inflation?,” NBER Working Papers 5539, National Bureau of Economic Research, Inc.
41. CAMPBELL, JOHN Y., ROBERT J. SHILLER, and LUIS M. VICEIRA. “Understanding Inflation-Indexed Bond Markets.” Brookings Papers on Economic Activity 2009 (2009): 79-120. Accessed July 2, 2021. http://www.jstor.org/stable/25652715
42. median.sol source code. Accessed July 22, 2022.
43. osm.sol source code. Accessed July 22, 2022.
44. Radicle.xyz. Accessed July 22, 2022.
45. Tellor. Accessed July 23, 2022.
46. MakerDAO Oracles. Accessed July 12, 2022.
47. Kiely Eugene US Inflation Rate at ‘Zero’ — for One Month factcheck.org. Accessed August 16, 2022.
48. Setzer source code. Accessed August 17, 2022.
49. US Treasury Sanctions Notorious Virtual Currency Mixer Tornado Cash. Accessed August 19, 2022.
50. Arrested Tornado Cash developer is Alexey Pertsev, his wife confirms. Accessed August 19, 2022.
51. Stablecoins – Investopedia. Accessed August 19, 2022.
52. Urbit Overview. Accessed August 19, 2022.
53. Consumer Price Index News Release. August 19, 2022.
54. Cross-Country Indexes, Year-over-Year Change - IMF. Accessed August 19, 2022.
55. Ames - Urbit docs. Accessed August 20, 2022.
56. Volt Protocol. Accessed August 20, 2022.