Creol DLT

While DLT is often use to describe any sort of technology using a form of blockchain, the Creol DLT components is made up of many blockchain elements. Currently it is comprised of a few elements

This section will focus on the first two. creol-eth and creol-carbon-eth

Creol-Eth

Creol-Eth is the primary repository for smart contracts pertaining to storing and managing the state of the built environment it is deployed for. At present time it is centered around Lighting and Lighting control. More extensions for HVAC/Blinds/etc are currently being developed and this document will be updated when they are deployed. It relies on a hardware device described in creol-hardware to be installed in the building to cryptographically sign and report information about the DALI system. This pseudo-Oracle provides state information to the contracts about each LED found within a space. For more detailed information on how these interact checkout the Intro to the Creol Network page.

Background

This suite of contracts enable complete autonomous and trustless tracking of a deployed built environment, ensuring that the energy usage reported is correct and verifiable. The main motivation for this component is to ensure that reporting and auditing of energy usage within a built environment is easy to track and is verifiable. The smart contracts present this functionality. By enabling this, the second component creol-carbon-eth is able to trustlessly offset against these metrics without the need for 3rd party verification or auditing.

Quick Start

  1. npm install will install all the required packages to run these smart contracts.
  2. Run truffle compile to compile the contracts with the dependencies such as openzeppelin/oraclize (now provable) etc.
  3. Contracts can then be deployed with Remix IDE

LEDState

This contract pertains to the state of an LED found within a built environment that is controlled using DALI by either the Creol Hardware or by another DALI/Creol enabled device. While the inner workings of the contracts can be found in the NatSpec of the contracts. A high level overview of what it does is as follows:

constructor (bool defaultState, address _roomContract,address _roomOwner, uint256 _daliShortAddress, uint256 _LEDDim, uint256 _LEDWattage) The constructor takes a defaultState of the LED (on/off), LED Wattage and the DALI Dim of 0-254 (Representing 0-100%) Each LED contract requires a “RoomContract” which is the room contract to which the LED is deployed to. As well as the owner of the room.

These are automatically taken care of when deploying new hardware and using the RoomState contract to do so. The LEDFactory.sol ensures that this is done properly using the LEDStateInterface.sol and the LEDLibrary.sol as a gas optimization.

Each LED maintains individual control of its:

  • State
  • Wattage
  • DALI Short Address
  • Dim Settings

And tracks:

  • Total Burn hours
  • Daily Runtime
  • Weekly Runtime
  • Monthly Runtime

In addition, when state changes occure the LED contract automatically calculates a cumulative burn time and then adds that value to the elapsed time since deployment.

Considerations

While the system is heavily reliant on outside information, the firmware running the hardware is written in such a way that tracks faults and sets the state to Off if the LED fails in some sort of way. It is far from the self-signing Pythias enabled LEDs that would completely close this system to be fully trustless, but those are work in progresses by various entities in the IoT space.

RoomState

This contract hold groups of LED contracts within structs defined by the hardware currently known as “CreezyPi”. The hardware deploys this contract when it is the first to be initialized in a room. Subsequent groups are then deployed based on the DALI groups found within the room. It also extends the group functionality to modfiying the Dim and State of the LEDs found in the system. function addCreezy is responsible for adding the entirety of the DALI system that is deployed and detected by the CreezyPi. Currently this process is manually done by the end user when they are in the room and have the Creol dApp. However, in future, this will be handled automatically using the Creol BIM module.

GridMix

This is a simple Oracle service used to retrieve the current Grid mix of a country using the electricityAPI. The entire purpose is to simplify the calculation of real time offsets when burning the creol-carbon-eth VCS subtokens to account for the usage. Currently, this is hardcoded using a test API key. However, users wishing to use this service will have to provide their own API key in the future.

Note on Security

While this set of contracts provides the base level of usage to be functional. It still is under heavy development and is subject to change. That being said, it also requires a security audit as well as more in depth, state checking/verification of inputs to ensure fuzzing doesnt render the system useless. This is largely mitigated by using ACL (Access Control Lists) to manage the ownership but does not prevent the user from misusing or sending false input to the contracts.

Creol-Carbon-Eth

Creol-Carbon-Eth is the primary repository for smart contracts pertaining to carbon crediting and offsetting. It is currently based on the standard of the VCS (Verified Carbon Standard) system. Carbon credits exist as special purpose ERC-721 NFTs and are then subtokenized into ERC-20s to represent each gram in the tonne of carbon the credit represents. For regulatory reasons, Creol is currently the only entity that is able to issue these NFTs on the Creol Network, although work is being done to transition this to a completely permissionless, trustless carbon accounting system. For now, users will have to purchase already tokenized credits from Creol or receive them as part of the subscription arrangement with Creol.

Background

The primary motivation for this set of smart contracts is to build a VCS duplicate system that is able to be micro offset to a single gram used within a space able to result in by the second micro offsetting if desired by the consumer.

CarbonVCU

This is the NFT that represents the VCS like credit that was onboarded onchain. It has a metadata and is mintable as VCS credits are often done in lots and sets that are identical except for the issue number. These NFTs function exactly how normal ERC721 tokens do and carry all the same features such as non-fungibility, transferrability etc. More details on the exact mechanisms can be found in the NatSpec of the contract.

VCUSubToken

This the ERC-20 Sub tokenization of the VCU NFT that is a burnable token. By burning the tokens you are effectively “offsetting” or “retiring” them just like in traditional carbon registry systems.