- Hacken
- Audits
- energy-web-foundation
- [SCA] Energy Web | Voting | Feb2023
Introduction
We express our gratitude to the Energy Web Foundation team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Energy Web is a global non-profit on a mission to accelerate the energy transition by developing and deploying open-source Web3 technologies.
| title | content |
|---|---|
| Platform | EVM |
| Language | Solidity |
| Tags | ERC1155; EIP2535 Diamonds; Energy Resource Tracking |
| Timeline | 23/12/2022 - 07/02/2023 |
| Methodology | https://hackenio.cc/sc_methodology→ |
Review Scope | |
|---|---|
| Repository | https://github.com/energywebfoundation/greenproof-sdk/tree/master/packages/greenproof-contracts→ |
| Commit | 4d9d110525e716da974f554ce8a29c003527d627 |
Review Scope
- Commit
- 4d9d110525e716da974f554ce8a29c003527d627
Audit Summary
10/10
100%
10/10
10/10
The system users should acknowledge all the risks summed up in the risks section of the report
Document Information
This report may contain confidential information about IT systems and the intellectual property of the Customer, as well as information about potential vulnerabilities and methods of their exploitation.
The report can be disclosed publicly after prior consent by another Party. Any subsequent publication of this report shall be without mandatory consent.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Energy Web Foundation |
| Audited By | Hacken |
| Website | https://www.energyweb.org/→ |
| Changelog | 30/12/2022 - Initial Review |
| 07/02/2023 - Second Review |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Energy Web Foundation
- Audited By
- Hacken
- Website
- https://www.energyweb.org/→
- Changelog
- 30/12/2022 - Initial Review
- 07/02/2023 - Second Review
System Overview
Greenproof contracts are used to issue certificates assuring certain properties of electricity generators. These certificates are used to determine how much electricity parties have left in their disposal according to the amount they have and have not used.
Certificated data is verified by voting among trusted parties. Only those parties who have acquired the necessary verifiable credentials are allowed to participate in the voting. To avoid security risks, no actual data is stored on-chain.
The project aims to achieve a trustable approach on the usage of clean energy, by keeping track of the energy usage of parties that are participating in the system.
Identifier of generation is a hash of generation data and it is called inputHash, generation data is represented by its Merkle tree and is called matchResult.
The system flow, including off-chain part of the project, is given as the following diagram:
Information about the contracts in the scope:
Greenproof.sol: High level contract which plays two roles:
to proxy calls to business logic components.
to initialize and configure logic components.
GreenproofInit.sol: Initializes the necessary supported interfaces on ERC165 for contracts IClaimManager, IGreenProof, IProofManager, IVoting. Used on deployment of Greenproof.sol.
IClaimManager.sol: Interface for Claim Manager Contract and Claim Revocation Registry, which are used inside LibClaimManager.sol contract
hasRole()function.IGreenProof.sol: Interface representation of IssuerFacet.sol contract.
IProofManager.sol: Interface representation of ProofManagerFacet.sol contract.
IRewards.sol: Interface representation of VotingFacet.sol contract. Responsible for rewards related functions.
IVoting.sol: Interface representation of VotingFacet.sol contract. Responsible for voting related functions.
VotingFacet.sol: Exposes API for driving and configuration of the voting. Internal methods are separated into LibVoting library. Since voting is identified by input hash, it has been aliased as
votingID.LibVoting.sol: Contains voting functions used by facets.
IssuerFacet.sol: Contract with main purpose of minting tokens certifying energy attributes. The basis for certification is voting for (
votingID,matchResult), which is completed with consensus. Second purpose of the contract is token transferring.LibIssuer.sol: Contains certificate functions shared by facets.
ProofManagerFacet.sol: Contract claiming certified energy generation.
LibProofManager.sol: Contains claim verification functions shared by facets.
LibClaimManager.sol: Contains functions, which verify authorization in facets.
LibReward.sol: Library managing reward payment.
Privileged roles
Owner: The only account allowed to upgrade contracts, add or remove participants of voting, cancel expired votings and enable or disable reward of voters, who have reached consensus.
Worker: Account who is able to determine generator data by generation identifier. Since this process requires off-chain data workers are off-chain nodes. Only nodes which are able to present certain verifiable credentials are allowed to vote.
Issuer: Is authorized to mint energy certificates and make their data public.
Revoker:
Any user with the revokerRole (defined during contract deployment) is allowed to revoke a certificate.
Claimer: Any user with the claimerRole (defined during contract deployment) is allowed to retire either partially or totally a certificate on behalf of the certificate owner.
Executive Summary
Documentation quality
The total Documentation quality score is 10 out of 10.
Functional requirements are detailed.
Technical description is detailed.
NatSpec is consistent.
Code quality
The total Code quality score is 10 out of 10.
The development environment is configured.
The code follows official language style guides and best practices.
Test coverage
Code coverage of the project is 100% (branch coverage).
Deployment and basic user interactions are covered with tests.
Negative cases coverage is present.
Interactions by several users are tested thoroughly.
Security score
Upon auditing, the code was found to contain 0 critical, 1 high, 8 medium, and 16 low severity issues. Out of these, 20 issues have been addressed and resolved, leading to a Security score of 10 out of 10.
All identified issues are detailed in the “Findings” section of this report.
Summary
The comprehensive audit of the customer's smart contract yields an overall score of 10. This score reflects the combined evaluation of documentation, code quality, test coverage, and security aspects of the project.
Risks
Iterating over a dynamic array populated with a custom number of variables can lead to Gas limit denial of service if the size of array goes out of control.
The system is fully centralized and upgradeable. The audit only covers contract versions within the scope and does not cover the generation and storage model of private keys. We recommend that all privileged role accounts be at least ⅗ multi-sig.
The @solidstate module was audited by Hacken, but since it has been some time since that audit, it should be considered a possible risk and evaluated accordingly.
Greenproof depends on external Claim Manager And Claim Revocation Registry as a source of the roles in the system which are not part of the scope.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2023-0632 | Data Consistency | fixed | High | |
| F-2023-0640 | Contradiction - Missing Validation | fixed | Medium | |
| F-2023-0639 | Best Practice Violation | mitigated | Medium | |
| F-2023-0638 | Inconsistent Data | fixed | Medium | |
| F-2023-0637 | Contradiction - Missing Functionality | fixed | Medium | |
| F-2023-0636 | Requirements Violation | fixed | Medium | |
| F-2023-0635 | Contradiction - Documentation Mismatch | fixed | Medium | |
| F-2023-0634 | Denial of Service (DoS) | fixed | Medium | |
| F-2023-0633 | Denial of Service (DoS) | fixed | Medium | |
| F-2023-0656 | Code Consistency | fixed | Low |
Appendix 1. Severity Definitions
When auditing smart contracts, Hacken is using a risk-based approach that considers Likelihood, Impact, Exploitability and Complexity metrics to evaluate findings and score severities.
Reference on how risk scoring is done is available through the repository in our Github organization:
Severity | Description |
|---|---|
Critical | Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation. |
High | High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation. |
Medium | Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category. |
Low | Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution, do not affect security score but can affect code quality score. |
Severity
- Critical
Description
- Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.
Severity
- High
Description
- High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.
Severity
- Medium
Description
- Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.
Severity
- Low
Description
- Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution, do not affect security score but can affect code quality score.
Appendix 2. Scope
The scope of the project includes the following smart contracts from the provided repository:
Scope Details | |
|---|---|
| Repository | https://github.com/energywebfoundation/greenproof-sdk/tree/master/packages/greenproof-contracts→ |
| Commit | 4d9d110525e716da974f554ce8a29c003527d627 |
| Whitepaper | Provided→ |
| Requirements | Provided (GREENPROOFS-GreenProofsSmartContractFunctionalRequirements-201222-1109.pdf) |
| Technical Requirements | Provided→ |