The Witnet explorer: version 1.1

It is my pleasure to introduce version 1.1 of the Witnet explorer. This release fixes several small functional and visual bugs in the existing API endpoints. Furthermore, it introduces a new API endpoint which can be used to query supply metrics and a new data request overview type.

The supply info API endpoint

This new endpoint introduces the feature to easily query supply info statistics in plain format as requested by Github issue #1. This endpoint is currently used by CoinMarketCap and CoinGecko to display the correct Witnet supply statistics. The endpoint essentially allows users to query the supply statistics as introduced by the witnet-rust node supply RPC function. The API endpoint is constructed as follows:

https://witnet.network/api/supply_info?key=<parameter>

<parameter> can be any value from the following self-explanatory options:

blocks_minted
blocks_minted_reward
blocks_missing
blocks_missing_reward
current_locked_supply
current_time
current_unlocked_supply
epoch
in_flight_requests
locked_wits_by_requests
maximum_supply
current_supply
total_supply

The data request history overview

This new view allows users to fetch an overview of all past values retrieved by the same data request. Instead of looking up a specific hash value, you can look up the SHA256 hash of the data request bytecode. The bytecode of a request can be read from the smart contract launching the data request or by compiling a data request using the witnet-toolkit as specified in the documentation.

There are two possible variations for the history overview. The first one will show only exact matches for a data request. This implies that both the sources and data request parameters such as number of witnesses and defined fees have to be an exact match. It is also possible to retrieve an overview where only the sources match.

An example of a data request history overview for a Bitcoin price request can be found in below screenshot:

In the card on the top left, the history type (data request bytes hash or RAD bytes hash) and hashes are shown as well as how many matches there are. The top right card shows the relevant parameters for this data request. In the bottom card there are two tabs. The first tab shows the data requests which have been completed up until now. It details the data request timestamp, transaction hash, number of errors, number of liars and final result. The second tab shows the RAD script. The RAD script details the queried sources, how they are filtered and aggregated.

Note that only the 100 most recent matches are shown. The API endpoint allows to control which section of the data request history is fetched through supplying start, stop and amount parameters. The start and stop parameters are the epochs boundaries between which you want to fetch historical requests.

The data request report which was introduced in the first release of the explorer now also contains links to these overviews.

This view is particularly useful for developers who want to peruse the results of their past data requests.