As a consequence of the foreseen significant increase in stochastic generation in the electrical grid, the need for flexibility and coordination at demand side is expected to rise. Decentralized energy markets are among the most promising solutions allowing to boost coordination between production and consumption, by allowing even small actors to capitalize on their flexibility. The main purpose of Hive Power is to develop a blockchain-based platform to support groups of prosumers that want to create their own energy market. The core element of this framework is the so-called Hive, i.e. an implementation of an energy market based on blockchain technology (see our white paper on hivepower.tech to have detailed informations about Hive Power platform).

Energy tokenization:

One of the most meaningful aim of Hive power is to tokenize the produced/consumed energy and to save the related information on a blockchain. For that reason an ERC20-compliant smart contract was deployed on the Ropsten network in order to create a hive token, called DHT, which has the following fixed value:

1 DHT = 1 cts = 0.01 CHF
The basic idea of Hive is that LOAD owns a certain amount of DHTs and sends part of them to the producers (typically SOLAR, but also the external grid through QUEEN) to buy energy. In the following chapter this aspects will be exhaustively described.

Operation mode:

A set of applications runs on the aforementioned devices to actuate the Demo Hive platform, a part of them developed by Hive Power. In this article only the main behavior of the demo testbed will be described, avoiding to explain all the code in details. The following image reports the software interactions inside the demo and outside with the Ropsten network.

As written in our whitepaper, periodically the real Hive platform will save data about the tokenized energy on a blockchain. This is quite unconvenient in a demo testbed because the period can be too long. For that reason the demo software considers virtual days with a duration of just 10 minutes. This means the SOLAR worker produces in 10 minutes the same energy really performed in 24 hours. Similarly the power measurements, in a real application performed off-chain and usually acquired every 15 minutes, in Demo Hive are measured every 5 seconds. As shown in Fig. 2, during the virtual day of 10 minutes the power measurements are saved by the workers in QUEEN (black arrows) in an InfluxDB database, a time-series oriented DBMS commonly used in monitoring applications. When the simulated day ends, the workers energies are calculated and tokenized in DHTs considering the following static tariffs.

Buy on grid: 20 cts/kWh
Sell on grid: 5 cts/kWh
Buy in the Hive: 10 cts/kWh
Sell in the Hive: 10 cts/kWh
Consider that LOAD/SOLAR worker can only buy/sell energy. Instead QUEEN, managing the interface with the grid, is allowed to perform both the operations. At the end of a simulated day a tokenization algorithm tries to maximize the hive autarky using the following rules.

At Hive Power we are working hard on our demo testbed to continuously improve it and add more functionalities. Key links:

Hive Power homepage: https://hivepower.tech

Whitepaper: http://whitepaper.hivepower.tech Twitter:https://twitter.com/hive_power Telegram: https://t.me/hivepower
profile link: https://bitcointalk.org/index.php?action=profile;u=1019190