Issuing certificates with the EW Origin SDK (Part I)
In this two-part series, we take a closer look at the decentralized issuance and management of renewable energy certificates.
This piece gives an overview of how Energy Web Origin’s software development toolkit (SDK) issuer module uses blockchain to issue and manage energy attribute certificates in a decentralized and transparent way.
Energy attribute certificates, explained
Energy attribute certificates (EACs) are used to prove that renewables such as solar, wind, or hydro have generated a specific volume of electricity in a certain place at a certain time. EACs derive their value from the trust that all stakeholders have in the certificate issuance process. Standards like guarantees of origin (GOs) in Europe, renewable energy certificates (RECs) in North America and international renewable energy certificates (I-RECs) elsewhere have solved this problem by acting as the trusted entity that ensures correct certificate issuance and management.
Traditionally, certificates are issued and managed in centrally managed registries that comply with standards like I-REC. Owners of renewable generators request certificates for a specific device at a specific time and issuers create the certificates in a private database. Users have permissions to access this database and perform actions with their certificates like transferring or claiming them.
Certificates as tokens
In central registries, certificates are just numbers in a database. Registry operators could theoretically create and remove them as they wish. Similarly, a user’s access to the database is controlled by the operator and could be revoked at any time. Of course, in most cases, registry operators will refrain from such activities because getting caught would mean a significant reputation loss and potentially the end of their business. But we think this is not enough.
Imagine an employee in a major corporation tasked with sourcing renewable electricity for dozens of electric load centers around the world. Juggling dozens of different jurisdictional regulations and standards can be complicated and confusing. Using blockchain technology and the Origin software development kit (SDK), we create a more decentralized and transparent certificate issuance process increasing the efficiency and trustworthiness of the entire market for certificates.
But how can certificates be represented on a blockchain and how is this better than just numbers in a database?
Most blockchain projects have the concept of a token, which is one of the biggest innovations in this space. (Sadly, tokens are also what gave rise to many vaporware initial coin offering projects.)
In brief, a token is a digital asset that has a specific owner. This owner can perform actions with the token, like transferring it to another user. There are many advantages to using a token to represent a renewable certificate on a blockchain: every certificate should always only have one specific owner and only this owner (and maybe the issuer, but more on this later) should be able to perform actions with this certificate.
Generally, there are two kinds of tokens: fungible and non-fungible. In the Ethereum world, they are represented by the ERC-20 and ERC-721 token standard. Fungible tokens (ERC-20) are well-suited to represent a commodity that is completely interchangeable, like money. Non-fungible tokens (ERC-721) are mostly used to represent things that have distinctive characteristics that make them unique, like baseball cards or CryptoKitties.
At first glance, it seems like non-fungible tokens are the perfect fit for energy attribute certificates, since the main task of the certificate is to trace the electricity that was produced in a specific device at a specific point in time. Accordingly, prior implementations of the Origin SDK used ERC-721 tokens to represent certificates. But there are some technical limitations to this implementation that made us rethink our approach. For example, it is computationally expensive to split certificates under ERC-721; it also becomes very challenging to efficiently manage “child” certificates once they belong to many different owners.
It became clear to us that certificates need to behave more like the electricity that they represent, allowing them to be split, traded, and bundled more efficiently. Electricity itself is more like a commodity. Every electron in the grid acts the same, no matter if it was generated in a hydro power plant or a solar farm. So we needed to find a way to combine the non-fungible part that provides a proof of origin with a fungible part that represents the actual electricity.
It became clear to us that certificates need to behave more like the electricity that they represent, allowing them to be split, traded, and bundled more efficiently. So we needed to find a way to combine the non-fungible part that provides a proof of origin with a fungible part that represents the actual electricity.
Adopting a multi-token standard for EACs
The solution we settled on is the multi-token standard ERC-1155. It combines a non-fungible token with a fungible component that is similar to ERC-20 tokens and can therefore be transferred and bundled in a similar way. In detail, the non-fungible token stores the device information and time frame of the certificate and the fungible part stores the energy volume that has been generated in that time frame.
For example, a device owner would request certificates for the month of January during which device X generated 100 megawatt-hours (MWh) of renewable energy. The certificate that is minted on-chain would be a multi-token with a fungible part of 100 tokens (or smaller denomination, depending on the use case). These 100 tokens could change ownership in any possible way just like any other fungible token. But the data structure of the multi-token allows every single one of these fungible tokens to carry information about the non-fungible token they belong to. This way, every MWh of energy can be connected to device X and the month of January. The time frame can be made as granular as needed (e.g., hourly), depending on the use case.
Certificates that are represented as tokens on the blockchain have distinct advantages over certificates in a private database. Once a certificate is minted on-chain, the owner actually owns this certificate in the form of a tradable blockchain token. What does this mean? This means that the certificate exists as long as the blockchain is running (which, if not forever, should be at least as long as someone—such as the certificate owners themselves—finds it useful enough to run the validator infrastructure to support it). It also means that only the owner has full control over the certificate. The owner is the only one that can technically perform transactions like transferring the certificate, because it requires a signature of the owner’s private key. Once issued, certificates can no longer be changed, not even by the issuing body, because they exist as an immutable data object on-chain. There are, however, specific techniques that allow issuing bodies to regulate certificates in a limited and pre-defined way, but more on this later.
Having certificates as blockchain tokens also increases their interoperability significantly. They can be transferred and traded independent of some application (e.g., the Origin platform). Anyone can, for example, build an exchange application, integrate the certificate token, and offer certificate trading to users. To transfer certificates, the owner can use a wallet application that has an integration with the token standard or call the smart contract function directly. This is in stark contrast to a central registry where all certificates can become inaccessible if the application is down or even be lost forever if the registry operator shuts down completely.
From simple token to fully functional certificate
There are of course some differences in the requirements for a regular token and a renewable energy certificate. One obvious difference is the need for the certificate to be claimed, meaning that it is locked and can no longer be transferred or changed in any way. For obvious reasons, only claimed certificates can be used for sustainability reporting. In central registries, this is mostly solved by a special “claimed account” where certificates are moved and locked by the permissions set by the registry operator. The Origin issuer module, on the other hand, introduces certificate states. By extending the regular ERC-1155 token contract, it allows for the owner to claim the certificate. Once in claimed state, the certificate is locked on-chain and can no longer change ownership.
Another difference mostly needed to be compliant with the different certificate standards is the possibility to revoke a certificate. Most issuing bodies want to have the power to revoke certificates which have been wrongly issued or whose owner is not authorized to own and trade them. In central registries, this is not a problem because the registry operator is a central entity that has full control over the issued certificates. On the blockchain this is a bit more complicated because there is no central control. The Origin SDK solves this by adding a validity check before every certificate transaction. This allows issuing bodies to revoke certificates that they have issued. Claimed certificates are exempt from this and can no longer be revoked. This ensures that no certificate that has already been used for sustainability reporting can be made invalid.
Certificate-specific logic is added to Origin’s multi-token by following the ERC-1888 standard. This standard is specifically created for renewable certificates and is an extension of the ERC-1155. It has the following data structure:
The topic describes the type of certificate that is issued. Topics are a standardized way of defining the properties of a certificate. Renewable certificates that have been issued according to the I-REC standard could be one example of a topic. The issuer data field contains the blockchain address of the issuing body that created the certificate. Validity data is used to check if a certificate has been revoked and if so, is used to block the transfer or claiming of the certificate. The data field holds the information of the certificate, which is mainly the device information, the time frame, and the issued energy volume. The certificate’s data can look different depending on the standard. But the topic defines what the data field should look like and certificates with the same topic should have the same data structure.
CONTINUE TO PART II: REGISTRIES, THE ISSUANCE PROCESS, AND PRIVACY CONSIDERATIONS.
