Certificate structure

Certificates are issued for a specific device and time frame. There are two different issuer modules in Origin that issue certificates that have similar structures. There are public certificates that are issued by the public issuer and private certificates that are issued by the private issuer. Both public and private certificates are implemented based on the ERC-1888 standard (https://github.com/ethereum/EIPs/issues/1888 ‑ ). ERC-1888 builds on the widely accepted ERC-1155 multi-token structure (https://eips.ethereum.org/EIPS/eip-1155) and extends it with a claiming functionality. The main reason why Origin is building on a concept of a multi-token structure stems from the fact that this allows us to have a fungible and a non-fungible part. This means that the multi-token is a combination of a digital entity that has distinctive characteristics and one that is completely interchangeable.

In the case of certificates in Origin, it becomes clear why this is such a suitable data-structure. Much of the data that is stored in a certificate is inherited from the generation device. This, together with the time frame for which the certificate is issued, makes every certificate unique. There can never be two certificates from the same device and the same time frame. But at the same time, the electricity that the certificate represents is just a commodity. Every electron in the grid is the same, no matter if it was generated in a hydropower plant or a solar farm. Certificates in Origin are therefore non-fungible tokens, in which all the unique device information is stored, combined with the energy volume that is implemented as a number of fungible tokens. Every fungible energy token is therefore immutably tied to the certificate that holds all the information about the origin of this electricity but is itself interchangeable.

This implementation allows for the certificate to be transferred and split into arbitrarily small units in a very efficient manner but still stay anchored to device and generation time. Transfers of the certificate, or parts of it, equal the transfer of ERC-20 tokens. This also enables partial ownership, as the percentage that the user owns of a certificate can easily be represented by the percentage of fungible tokens the user owns of that certificate. This makes it very easy and efficient to distribute the full generation volume of the certificate to buyers on a very granular level. Note that only because this granularity is possible on a technical level does not mean that regulation allows it.

Data Structure

The ERC-1888 multi-token that represents a certificate on-chain has the following data structure:

1 2 3 4 5 6 struct Certificate { int256 topic; address issuer; bytes validityData; bytes data; }


Topic: The topic is an integer number that describes the type of certificate that is issued. Topics are a standardized way of defining the properties of a certificate. By using topics, stakeholders know the data structure of a certificate just by checking the topic number. Examples of different topics could be certificates that are issued according to different standards like REC, I-REC or GO but also completely different certificate-like structures e.g. carbon offsets or flexibility offerings. Every certificate with the same topic should have the same standardized data structure. This makes it really easy to work with.

Issuer: The issuer data field contains the blockchain address of the issuer that created this certificate. Generally, there should only be a small number of local issuers (mostly even only one) that are authorized to issue certificates in accordance with regulation. The address of these issuers should be publicly known and therefore act as a proof of authenticity on certificates. Because of the public key cryptography utilized by the blockchain, every stakeholder can be sure that only the issuer that holds the private key belonging to this address is able to issue the certificate. As a result, certificates that contain the address of a known issuer can be trusted to be real and regulatory compliant. In the case that there are different issuers, it can also be clearly distinguished without any doubt who issued which certificates.

Validity Data: Validity Data is a callback function that returns either true or false based on predefined criteria. It is used to check if operations like claiming or transferring a certificate are valid. This functionality is needed because the issuer reserves the right to suspend any non-claimed certificate at any time. Reasons for suspending a certificate could be a default on a payment to the registry or that the issuer finds out that it was issued based on false evidence. In the case that the issuer suspends the certificate, the validity data function will return false and make it impossible to transfer and especially claim the certificate. There are also other rules that can be implemented, the expiration time of the certificate could be one example.

Data: Next to the fields explained above, there is a lot of additional data that is part of the certificate. Some of the mentioned previously is device id and the time of generation. But the data field can host any arbitrary set of information ranging from device-inherited like technology (solar, wind, etc.), vintage and location to certificate specific like a right to obtain carbon offsets. But the exact data fields, naming, and units can vary depending on the certificate’s standard. As the ERC-1888 standard wants to keep it as generalized as possible, it does not require anything more specific than this data field in which all other information is contained. The topic is used to still give users and developers information about the data structure of the certificate. As explained above, every certificate with the same topic should have its data structured in the same way to allow for easy interaction.

The fungible part of the certificate representing the energy volume is minted together with the creation of the certificate according to the ERC-1155 standard:

1 2 // CertificateId => (owner => balance) mapping (uint256 => mapping(address => uint256)) internal balances;


Balances: Every certificate that is issued has an id and a number of fungible tokens attached to it. The balance is a mapping that connects the certificate id with an owner address and the number of fungible tokens that this address holds. The amount of tokens that are minted by the issuer is based on the produced energy for a specified time frame. The user that requests the certification is also the initial owner of issued fungible tokens. Depending on the defined rules, the minimum tradable and claimable energy volume should represent one fungible token (e.g. 1 MWh in many standards). When the tokens are traded, the balance mapping updates to account for the new ownership structure. The id of the certificate, however, does not change and always connects the fungible tokens with the unique certificate data, independent of the changing owners.

Private data structure

The private data structure is identical to the public structure with only one difference. In private certificates, the fungible part of the certificate has not been minted publicly on-chain. The energy volume data is stored off-chain in a private database of the issuer with a reference to the data stored on-chain. This means, that only the non-fungible part, containing device ID and time frame is minted and publicly available on-chain. As a result, there is a digital trace of a certificate that was issued for a specific device for a specific time and is now in the ownership of a user but the number of certificates (e.g. each 1 MWh) is hidden.

Even though the energy volume information is stored on the private database of the issuer, there exists a reference to this data on-chain. Origin uses the precise proof privacy technique to store a proof about the off-chain data on-chain. Precise proofs are used to track the off-chain data and ensure that it is not maliciously altered. By using cryptography, it can be verified that all actions performed by the issuer have been correct, once the data is revealed e.g. to an auditor or the broad public. Precise proofs make use of merkle trees to achieve these desirable properties. Data is hashed together until the merkle tree root hash is created. The hashes are randomized by hashing the actual data together with random strings of data called “salts. The root hash with the data scheme represents the commitment that is published on-chain. Learn more about precise proofs here: https://energyweb.atlassian.net/wiki/spaces/EWF/pages/617054209


1 2 3 4 5 6 7 8 9 10 export interface IOffChainProperties { rootHash: string; salts: string[]; schema: string[]; } export interface IOnChainProperties { propertiesDocumentHash: string; url: string; }