DIGG Oracle Update

Published in

BadgerDAO

5 min readJul 24, 2021

On July 14, 2021, DIGG migrated away from a Chainlink oracle, and reverted to the original oracle design used at the token’s launch in January, 2021.

This article explains what happened and what it means for the future of DIGG.

But first, a quick refresher on DIGG.

The Basics

DIGG is a rebasing asset pegged to the price of Bitcoin.

When the price of DIGG is above 1.05 BTC or below .95 BTC, a rebase occurs, increasing or decreasing the supply of DIGG in all wallets and smart contracts according to the following formula:

% Rebase = .1*((DIGG / BTC ratio) — 1)

If DIGG is trading between .95 and 1.05 BTC there is no change to the supply of DIGG (equilibrium).

For example, if BTC is trading at $30,000 and DIGG is trading at $33,000 the rebase will be a positive 1% expansion of DIGG.

The daily rebase occurs at 20:00 UTC.

You can track the history and expected daily rebases of DIGG at digg.finance.

Role of the Oracle

How does the DIGG smart contract get the DIGG/BTC ratio to calculate the rebase?

Like most crypto assets, DIGG is traded on both decentralized exchanges like Sushiswap and Uniswap, and centralized exchanges like Gate.io, Bilaxy, etc.

Tokens trade at different prices on different exchanges due to supply and demand dynamics on the particular exchange.

The job of the oracle is to gather price data from across the exchanges and derive a single fair price used in the daily rebase.

In doing so, the oracle must make a number of design choices:

Data Sources: Some centralized exchanges are notorious for engaging in wash trading or other activities that create false volume and distort prices. A good oracle must discriminate between inauthentic behavior and genuine trading.
Sampling & Interval: Longer look back periods generally create less volatile price movements than shorter ones. Averaging prices sampled evenly across the period (eg. every hour) creates a more representative sample of the price over time but could be gamed by market participants who know the exact time the price readings are taken.
Price Formula: The most common of these are VWAP (volume weighted average price) and TWAP (time weighted average price). TWAP is the simple average of price snapshots over a period of time. This method tends to dampen the effect of a handful of large trades during the period. VWAP weights pricing data by volume, which incorporates the information from trades in proportion to their size.

V1 Oracle

The initial DIGG oracle was designed by Badger and calculates the DIGG/BTC ratio off-chain. It’s key features are:

Data Sources: Since DIGG was not listed on centralized exchanges at launch, only Sushiswap and Uniswap (v2) are considered.
Methodology: The DIGG/BTC ratio is a TWAP (simple average) of 24 readings from the Uniswap and Sushiswap pools taken at one hour intervals over a period that resets at 19:00 UTC. This is currently a manual query, but work is in progress to automate it. Before performing the rebase, the DIGG contract checks that the price is at least 10 minutes and not more than 24.5 hours old.

This oracle was in use between January and April 2021, and then reactivated on July 14.

V2 Chainlink Oracle

In late April 2021, DIGG migrated to a Chainlink oracle.

There were several reasons for this choice:

DIGG was now listed on several centralized exchanges so it was desirable to include this activity in the calculation; and
Desire to have DIGG pricing determined by a neutral third party (Chainlink) rather than code developed by Badger

The Chainlink oracle has the following design parameters:

Exchanges: The Chainlink Oracle requires at minimum 2 CEX and 2 DEX data sources, with a minimum of $3m daily volume spread evenly across these.
Methodology: The DIGG price is calculated using a VWAP over 24 hours that begins 2 hours before the daily rebase (18:00:00 UTC).The DIGG / BTC ratio is obtained by calling the getLatestRoundData() function from the Chainlink oracle.

After the launch of the Chainlink oracle, DIGG underwent a series of negative rebases and trading volume shrank below the needed $3m daily threshold.

As the second round of UMA KPI options began in July, some members of the DIGG community noticed that the daily rebase was not performing as expected and identified at least one equilibrium rebase when a positive one was expected (July 8, 2021).

After a call with Chainlink, it was determined that the oracle was not functioning as intended because volume had fallen below the $3m threshold. This was causing data from centralized exchanges with very thin liquidity to be overly weighted in the index.

For example, one centralized exchange was reporting a DIGG/BTC ratio that was over 10% lower than other data sources despite only having .25 DIGG available to trade at those levels.

Chainlink did not think it was possible to alter the data sources or weighting to correct this problem, and so the team decided that the best near term solution was to revert to the original oracle that excludes CEX data.

Future Oracle Upgrades?

Today, the DIGG original oracle is operating as designed based on Uni V2 and Sushi liquidity pools.

Going forward, there is an ongoing discussion about the future of the DIGG oracle with the goals of:

Fairly incorporating all trading across centralized and decentralized exchanges;
Quickly adding new price data sources as DIGG becomes active in more places across DeFi and other chains;
Making the rebase process more transparent and credible, eg by outsourcing the data collection and rebase calc to a trusted outside protocol such as Chainlink or Uma;
Finding a more precise calculation method that avoids the limitations of the VWAP and TWAP, for example by averaging the two or using a TWAP that takes a larger number of measurements.

If you’d like to dive deeper in or get involved and help shape the future of DIGG, here are some further resources: