Origin FAQ

→ EWT is the native token of the blockchain. It is part of the core blockchain protocol and is used to pay for transaction costs. It can be seen as the cost of doing computation, similar to how you would pay a cloud provider to use the infrastructure for a computation. Instead of a central cloud provider, the transaction fees in EWT are paid to the validator that created the block that the transaction was included in. The EWT is a utility token that only exists to fund the blockchain network. The main reason for transaction costs are to maintain the infrastructure of the validators (servers + labor cost etc.) and provide spam protection. More info here: https://energyweb.atlassian.net/wiki/spaces/EWF/pages/719847470

→ The certificate tokens are not part of the blockchain protocol, but are smart contract tokens. They have nothing to do with paying transaction fees or the maintaining of the blockchain. They are put on top of the blockchain as part of an application. The smart contract defines how certificate tokens are created, transferred, claimed, etc. This is very different from the EWT utility tokens that are not created by a smart contract but that is an inherent part of the blockchain protocol and are created and managed by the implementation of that protocol in the blockchain clients. Both “tokens” are digital representations of value, but this is probably the only thing that they have in common. The certificate tokens represent a certificate of 1 MWh of energy in compliance with certificate standards like I-REC. The value of the EWT is defined by users that want to interact with the Energy Web Chain and have to pay transaction fees to do so.

→ Creating, transferring, and claiming certificate tokens all represent transactions on the Energy Web Chain. As these actions are performed by calling a function of a smart contract on the blockchain, it means that the user creates a transaction and has to pay transaction fees for that. The smart contract is an application on the blockchain and interacting with this application is creating a computation that has to be paid for. This means that a user has to pay EWT in order to create, transfer, and claim a certificate token. Let’s take the example of creating a certificate: The user requests certification based on generation data, when the request is approved by I-REC, the Origin application calls a function in the smart contract that mints a new certificate token. Creating the certificate token by running the minting function creates work for the computer which has to be paid by the user in EWT. The user pays EWT to the validators that validate that the transaction to create the certificate token is valid (e.g. that it has been approved by the issuer) and adds the transaction to the blockchain. The user has now paid EWT to the validators and has received certificate tokens. If the owner of the certificate tokens now wants to transfer the certificate e.g. to the exchange to trade it and then to another user, the transfer function of the smart contract has to be called and again because this is also a blockchain transaction, the user has to pay EWT to do this. The EWT can be seen as the currency to pay for the transaction fees and the certificate token is the good that you receive. Similar to when you buy a house, you pay for a notary that confirms the buy contract and then you are the owner of the house. The notary is represented by the validators who are paid in EWT and the certificates are the house that you receive. As you can see the certificate token is representing an asset that you own and the EWT (like a house) and EWT is just a currency that you pay to do a transaction (like dollars that you pay to a notary).

The cost is mainly defined by the transaction costs that have to be paid for transactions in EWT.

For more info: https://energyweb.atlassian.net/wiki/spaces/EWF/pages/719847470 .

Users are connected to a blockchain address, but it is no additional user data stored on-chain.

There are two types of entities that have on-chain data: certificate requests and certificates

Certificate request stores:

• requestOwner: The blockchain address of the user which requests the certificate

• certificateOwner: The blockchain address of the user which will receive the issued token. By default, it equals to requestOwner

• data: This is the data encoded in byte code that is stored in the certificate request. It stores the device ID and generation time.

• approved: This stores if the certificate has been approved or not

• revoked: This stores if the certificate has been revoked or not

• isPrivate: Stores if the certificate is issued privately (certificate volume is hidden) or not

Certificate:

• topic: Identifier that categorizes type of certificate (not fully standardized but in future I-RECs could have own identifier)

• issuer: Blockchain address of the issuer of certificate

• validityData: This stores if the certificate is valid or if it has been revoked. It restricts interacting with the certificate (claiming, transferring etc.) if it is not valid.

• data: This is the data encoded in byte code that is stored in the certificate. It stores the device ID and generation time.

• balances: Information about the volume and ownership of a given certificate, when isPrivate was set in the request, the balances will be set to 0 and real balances hidden in encoded Merkle tree.

All other information is stored off-chain. The data that is stored is defined in the backend e.g. https://github.com/energywebfoundation/origin/blob/master/packages/origin-backend-core/src/Device.ts

In the future, users, organizations, and devices will have a representation on-chain as well. In order to represent an organization structure on-chain, an organization will have key management capabilities to manage its users. The plan is that organizations and users (and maybe even devices) have decentralized identifiers on-chain that have claims attached to them. An example would be the claim that Organization A has ownership over Device X. Identities and claims would exist on-chain but their contents would be stored and calculated off-chain. As a result, no sensitive data would be stored on-chain, but instead only references to that data.

There are many advantages to having certificates in the form of a token on the blockchain. To just name a few:

• Traceability: Every transaction is recorded, cannot be forged, and forms a complete history of every certificate.

• Security: A blockchain database can, by design, not be altered by an attacker.

• Ownership & Permissioning: Users have real ownership over certificates and are not dependent on one single application. Very clear and auditable rules about who is allowed to do what in what way.

• Network effects: Many applications in the future can integrate with the certificate and could create added value for the users. Additionally, users that use other applications on the EWC will be incentivized to use Origin marketplace.

• Interoperability: In a future where there are many standards, products, and applications (e.g. I-REC, carbon offsets, PPAs), the issuance on the blockchain can radically streamline processes and reduce admin costs.

Additionally, without having a digital twin of the certificate on-chain, all certificate actions would have to be handled through the specific certificate registry API like the I-REC API. Creating a double record enables more independence from these registries. Even if I-REC holds information in their registry, they are mainly concerned about issuance and redeeming and the registry is optimized for this. A digital twin in the form of a blockchain token is best suited to trace everything that happens between when certificates are traded. Additionally, it will be a big advantage to already have this infrastructure in place when all the network effects and interoperability considerations come into play. By starting this, projects can define a technology standard and will have other players follow it rather than only creating a single application.

Disadvantages can be:

• Synchronization: There needs to be a well functioning system in place to make sure that certificates that are in the Origin marketplace cannot be changed or moved in any way in the I-REC registry. This is solved by working closely together with I-REC and discussing the best way with them.

• Ensuring privacy: When having a digital twin on-chain, privacy is not the default and thus additional features are needed to meet certain privacy requirements from users. This can be solved through various privacy-preserving solutions like the precise proof technique.

ERC-1888 is an extension of ERC-1155 and was specifically created for renewable certificates. ERC-1888 is basically built on top of ERC-1155. It adds the functionalities to lock the token for claiming and to revoke (invalidate) the token (in ERC-1155 there was no such functionality). The creating (minting) and transfer function already existed as part of the ERC-1155 standard.

The issuer uses the token contract to create new certificate tokens, owners use the contract to transfer the tokens and to claim them. The issuer can also use the contract to revoke the certificate token.