The Introduction of HNT Price Oracles

The biggest developments in the Helium blockchain ecosystem right now are around HNT and Data Credits.

• HNT is the native cryptoasset produced by the Helium blockchain that's distributed to miners and other network stakeholders.
• Data Credits (DCs) are the unit of transaction on the Network, and are spent when completing transactions like sending data to/from a device, sending HNT from wallet to wallet, adding Hotspots, and asserting a Hotspot's location.

HNT and DCs are linked in a very simple, powerful way: DCs are produced by burning HNT. (This is based on a concept called "Burn and Mint Equillibrum, and the Messari team has some great initial reading and pointers here.) Most of the work to faciliate this is done. The HNT burn transaction already exists on the blockchain, and we recently completed the state_channel work which enables us to track data credit usage per account.

DCs are actually pegged to a $USD amount: $0.00001. This means that, at any time, a user can know the price of their transactions in advance in $USD. For example, we have a great calculator that lets you calculate the cost of sending device data.

How many DCs are produced by burning HNT?

But if HNT converts to DCs, what's the conversion rate? Don't we need to know the price of HNT in $USD before this can happen? Yes. And to find the answer, we're implementing a what's typically called a "price oracle". Specifically, we're opting for a system built on multiple oracle feeds from network participants.

HNT Price Oracles

To establish the price of HNT in $USD, we've chosen to implement a price oracle model based on what the Maker community announced and has been using successfully since last year.

At a high level, the system works like this:

• Some number of participants/entities submit HNT/$USD feed transactions using a key pair known to be from an approved feed.
• The prices are submitted every N hours, or when a participants/entity notices a big movement in the $USD price.
• The blockchain establishes an external $USD price of HNT by calculating the median of the price inputs.
• This price is used for HNT / DC conversion until a point at which a new price is determined using the method above.

Who are the Oracles? How were they chosen? What are their responsiblities?

The price feeds are supplied by a group of nine (9) Oracles, composed of companies, organizations, and indivduals. They are:

• Helium, Inc
• Decentralized Wireless Alliance (DEWI)
• Seven (7) Anonymous Individual Community Members

We've chosen to keep the names of the individual feed contributors anonymous as it's essential to prevent any external attempts at extortion or blackmail. The names of large companies and organizations that supply feeds, however, are public and it's easier for them to combat potential attacks and bad actors. The selection criteria for the Anonymous Individual Community Members were as follows:

• Have they been a long time, active member of the Helium Community?
• Do they contribute actively and positively to the betterment and progression of the Helium Network?
• Do they have a complete technical understanding of the Helium network and our token system?
• Are they capable of challenging Helium and other community members on the roadmap and technical decisions?
• If their names were to be known, is it likely that most fellow community members would deem them trustworthy?

If the answer to all of the above was "yes", they were a candidate for being an Oracle. This list was assembled and randomized, then each participant was approached, in order. If yes, they were added. If no, we moved on.

It's worth noting that being a price Oracle does not confer any special status on the companies, organizations, and indivduals. It's largely a clerical role, and does not come with any sort of compensation (or even swag). Also, it's not expected that the current set of Oracles will be in this role for all eternity. (That would be a lot to ask.) And we expect to expand the group in the future as the system evolves. For example, in the event that a major, trusted exchange does start to offer HNT, we would likely look to add their price as an Oracle.

How is the price of HNT actually calculated?

Most of the code that handles the HNT price oracles can be found in blockchain-core. But if you're not fluent in reading Erlang (guilty), here's the summary of how things are designed:

Every 50 blocks (roughly every 50 minutes) the blockchain will attempt to establish a new price of HNT. (This 50 block number is defined in a new chain variable). To do this:

1. The blockchain looks for recent price submissions from valid Oracles (submitted using a new transaction called price_oracle_submission). A valid price submission is anything that was submitted within the last 25 hours but is older than 1 hour. This gives us the ability to do a trailing 24 hour median while also having a buffer against wild price inputs in the most recent 60 minutes. (Think of it like a bleep filter on "live" televsion. They aren't bleeping four letter words live. It happens because there is a bit of lag.)
2. If there are enough new, valid price submissions in the 24 hour window, a new price will be calculated. For this to happen, a majority of the price Oracles need to have submitted a price in the window - ((N / 2) +1 ). So, in our system of 9 Oracles, we would need valid prices from at least 5. (If there aren't ((N / 2) +1 ) new prices, no new HNT price is calcuated.)
3. If there are at least 5 new prices, we then proceed to sort order the list low to high, and take the median. So, if we had 7 valid submissions of $.20, $.22, $.235, $.238, $.25, $.27, $.45, the blockchain would select $.238, and use this as the external price of HNT for all HNT / DC burn transactions until a new price is established (which could be as soon as 50 blocks).

With the price of $.238 established, the blockchain will now use this as the input to all burn transactions.

New Chain Variables

As part of this work, we're proposing a series of new Chain Variables. They are:

Proposed Chain Variable	Rationale
price_oracle_public_keys	Array of ed25519 binary public keys of price oracles
price_oracle_refresh_interval	Number of blocks between price recalculation
price_oracle_height_delta	Delta allowed between current block height and the price_submission txn
price_oracle_price_scan_delay	Number of seconds to delay scanning for prices
price_oracle_price_scan_max	Number of seconds to stop scanning for prices

When this work is fully merged, they will be part of the complete list of chain variables.

What's Next?

We're putting the final touches on the Oracle system as we speak. In the coming days we plan to do the first test run with the current group of Oracles, and then refine things a bit more before Data Credits and burning HNT formally goes live in the coming weeks. Exciting times.