What’s new in Origin release C

An overview of new features and updates to EW Origin’s SDK

Here at the Energy Web Foundation (EWF), we are focused on decarbonizing the energy sector. Our Energy Web Decentralized Operating System (EW-DOS) is a technology stack of open-source software and standards designed to achieve that vision. A primary component of EW-DOS is the EW Origin SDK, which supports digitalized renewable energy and carbon markets. This is the latest need-to-know update about important Origin developments.

December 2018 marked the deployment of Origin’s release B. Now one year later, we’re releasing a new version—you guessed it—Origin release C. Queue mandatory rocket emojis 🚀🚀🚀!

A lot has changed in a year here at EWF. We launched Energy Web Chain (EW Chain), and we released a technical roadmap for our Energy Web Decentralized Operating System (EW-DOS). But what has changed with our Origin SDK?

Well, for starters, we started positioning Origin more as an SDK — a set of open-source modules that helps developers build energy attribute certificate (EAC) tracking and trading platforms. We’ve also noticed that a part of our ecosystem considers Origin a product, which was never EWF’s intention. We always imagined Origin as a set of open-source libraries that helps companies build a product around energy traceability use cases.

For the Origin team, 2019 was a year of features. We added a lot of them. Here’s a brief description of the most interesting ones:

Users, organizations, and devices

While release B mainly focused on use cases after issuance of certificates, release C takes a step back and introduces support for users, organizations, and devices. Users can now register onto the system through a registration form. We also added support for grouping users under an organization. Users with device manager rights can register and manage devices. There’s also support for KYC-ing both devices and organizations. This way, a local issuer or a platform owner can approve each organization and device before they enter the active state on the platform.

Device managers can also request certification of smart meter reads through the UI. Once the local issuer approves the submitted meter reads, the device owner will receive the certificates.

Demo of a device approval process where the local issuer has to approve a pending request (notice the quick change of addresses, that’s the new in-browser key management support — explained later).

Solar simulator

To make the process of demoing and playing around with the SDK simpler, we’ve created a solar simulator. The solar simulator is a simple package that simulates the generation events and adds meter readings to selected devices. The simulator is built by generalizing real production data through the year based on a device in Germany, so watch out if you’re trying to simulate something for a location that’s in the southern hemisphere.

Matcher upgrades

Our market matcher went through multiple upgrades, both on the UI and the backend fronts. The two most significant customer-facing updates are on demand management and automatic posting of supply.

Users can now see and manage all of the active, paused, and archived demands. We also enabled duplication of demands. This allows an easy set up of similar demand profiles. Buyers that have a specific preference on what device type they want to target, but would like to set up different prices for different regions, can now achieve precisely that with just a couple of clicks.

Release C also brings additional simplifications of the procurement process for a buyer. New filtering options enable buyers to create extremely granular demands. By filtering supplies on the marketplace, buyers see only a couple of options out of hundreds of offers initially displayed. And with a multi-select feature, buyers can select two or more offerings and one-click buy.

Demo of quickly creating new demand by duplicating the original and changing a region and price criteria.

We didn’t forget about the sell side. Sellers can now set one fixed price for all newly issued certificates. Once the local issuer approves the certificates, the system will automatically place them on the market for the defined price. A simple set-and-forget strategy.

And for more-advanced sellers that want to approach the marketplace more strategically, we’ve added a feature that allows sellers to create supply from a portion of the certified volume. This means that sellers can split their monthly generation into two or more offerings with different prices.

Notifications

For all critical actions in the system, there’s now an easy way to set up notifications. Some actions require a response from other stakeholders (e.g., local issuer, platform operator), which means that there might be days between submitting a registration request and getting access to the platform. To avoid visiting the platform daily and checking if access is granted, Origin now allows us to set up a simple emailing service based on events in the system.

Dev-specific changes

There’s also many changes on a purely technical level. We migrated our multiple repositories into one monorepo. This should make the discovery of Origin-related repositories easier. We also moved our repository to a simple /origin URL under our GitHub organization.

In release C, we had a massive simplification and refactoring of smart contracts. We went down from 38 to just 4 smart contracts. Contracts are now based on OpenZeppelin upgradeable smart contracts, which, you guessed it, makes upgrading smart contracts way easier. We’re also using OpenZeppelin’s contracts for ERC-721 implementation.

To avoid going through the pains of installing MetaMask, we’ve developed support for in-browser key management. It’s a less-secure approach, and we do not advise to use it in production. But it allows a simple onboarding of new users without having to pop open a MetaMask window before a user even sees what’s behind the obstacle.

Most of the packages now have Docker support. We added .env files for a more straightforward system configuration. Origin went through a small cleanup where we removed packages and dependencies that were of no use. We also renamed a couple of packages so utils-demo is now migrations, asset-regisry is now device-registry.

Looking at the upcoming release D

We aim to roll out release D somewhere between May and July (2020!). Release D should be our first production-ready release. To be production-ready, we plan to go through a code audit by an independent 3rd party.

Release D should also bring:

1. I-REC integration: audited and approved by the I-REC standard itself. Also fully open-source and designed in a way that anyone can use it without using the Origin’s full-stack.
2. Redesign of underlying token: currently, our token is an ERC-721 token. We’re going to migrate to ERC-1888 with support for private issuance and transactions.
3. Order book trading: our matcher will migrate to a full order book-style trading. Current implementation follows the notion of an order book, but in the future, we want to have it fully fleshed out and have a concept of bids and asks on top of which users can build supply and demand.
4. Inventory management: together with migration to order book trading, we would like to create a better overview of inventory. This should enable users to have a better grasp on certificates that they own, have claimed, and have open bids and asks for.
5. UX: we didn’t spend too much time on making our UI pleasant and understandable. For the next release, we want to clean it up and make it more approachable.

How to follow along?

There are two simple ways. First, you should follow us here on Medium! We’re planning on issuing monthly SDK updates with an overview of what was developed in the previous month and what to expect in an upcoming month. Secondly, if you’re a developer interested in Origin, you can follow all our architecture/product decisions on our GitHub. We’re adopting ADR as a way to document and signal any architectural changes.