We aim for a decarbonized energy future and we are inspired by the Energy Web Foundation's statement on their website: "Energy Web is accelerating a low-carbon, customer-centric electricity system by enabling any energy asset owned by any customer to participate in any energy market."

As we enter the era of the data economy we see a lot of innovative solutions built on decentralized platforms like the Energy Web. Ocean protocol is first mover in this field by tokenizing data assets and building service portfolios around datasets like compute-to-data and automated market making using the Balancer protocol.

Our solution is based on the premise that we can bridge both protocols for the sake of strengthening either one of them. The Energy Web is building trust, leveraging verifiable certificates of renewable energy production using an SSI infrastructure whereas Ocean focuses on data assets at the center of their value proposition.

What it does

An excellent use case for the proposed bridge is the balancing of power, according to natural flows of electricity. You need to consume power the moment it is generated, therefore the energy grid is architected around energy planning partners. They have the responsibility for balancing consumption and production of power at each hour of the day. Renewable energy sources are quite challenging here because of the intermittency of power generation. To aim for decarbonization we need a near-realtime power production forecast. Needless to say, the availability of reliable (metered) data is key to this.

For this purpose we are going to use the trust network of EnergyWeb to identify renewable energy producing devices and leverage the data infrastructure of Ocean to curate and verify production data of these devices. A simulation model shows the effects of this integration.

How we built it

The solution is a 3-step process:

  1. Register producing devices in EnergyWeb and collect metered data
  2. Peg the device to an Ocean Market datatoken pool having the metered data as the underlying dataset
  3. Signal device behavior by Stakers, Auditors and Optimizers using the datatoken pool

ad 1.) we cloned the EW-DOS origin repo and managed to get a dashboard with devices. Unfortunately to register a device ourselves, you need to have undergone some formal approval process so that's too inconvenient for this submission. However, we are able to simulate having a device registered and attach metered data to it, therefore we used the data.csv file of the solar-simulator package as an example.

ad 2.) Building upon the solar-simulator package, we used the i-rec registered devices to add a dropdown field in the Ocean Market front-end populated with these devices in order to have an EnergyWeb registered device use their metered data as a proxy for the datatoken pool. Selecting a device will populate all meta-data fields of the Publishing form, having a basic integration between EnergyWeb and Ocean Market.

ad 3.) This is where the actual Tokenized Power Balancing job is done. Once we have a datatoken pool with metered data as an underlying dataset, stakeholders are going to use it to add value. Stakers signal curation by investigating the behavior of the power producing device as inferred by EnergyWeb EACs (and the claims thereof), but also by relying on other stakeholders like Auditors verifying metered data with sell orders in EnergyWeb Exchange and Optimizers making power production forecasts based on this metered data and possibly other datatoken pools having weather history and forecast datasets. For a detailed interplay between these stakeholders, see our documentation.

The output of 3. is accomplished by using an energyweb branch of the tokenspice2 simulation model looking primarily at the effects of the Optimizer.

Challenges we ran into

Energy Web EW-DOS toolkit is not as friendly as we hoped for. In order to get new devices registered, we could not find out how to do that easily without getting stuck in some accreditation process. So we have to assume we can register a new device and call the Ocean API to publish a data token pool on the fling.

Also, tokenspice2 is still a WIP. We had a lot of issues getting it up and running and still we ran into trouble with a new setup of the SimState. Fortunaltely we did manage to code up the Energy Web agents as stakeholders into the simulation. The coding up of the EW Staker agents is then up to the strategy but alas, no time left to really have some implementation running.

Accomplishments that we're proud of

The idea is solid and reasonably straightforward to implement once we get all the bugs out of tokenspice2. Nice thing about data token pools is that we can have a pool for both the EWPublisherAgent (device pegged to Ocean) with an underlying dataset and a pool for the EWOptimizerAgent with the forecasts as an underlying dataset.

Both datasets have a static URL (S3 bucket) and are updated every hour through a crontab entry for the sake of the simulation. We can hook up these sets again for real implementation in Ocean Market pools, updated with real-time and verified (metered) data.

What we learned

Integrating 2 innovative implementations is hard...

What's next for Tokenized Power Balancing

  1. Update the tokenspice2 model to really have some Energy Web simulations going on.
  2. Port tokenspice2 to cadCAD to have more Optimizer policies in play
  3. Get in touch with Energy Web engineers to work on the EW-DOS

Built With

+ 7 more
Share this project: