- Hacken
- Audits
- evervalue-coin
- [SCA] EverValue Coin | OrderBook | Nov2024
Audit name:
[SCA] EverValue Coin | OrderBook | Nov2024
Date:
Dec 31, 2024
Table of Content
Introduction
We express our gratitude to the EverValue Coin team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
EverValue Coin (EVA) is a new token with real value in bitcoins because it is fully backed by Bitcoins. It has a unique and final issuance of 21 million, making it better than Bitcoin in this aspect. It operates in a "smart contract" wallet where new bitcoins are deposited daily but can only be withdrawn by burning EVA tokens.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for EverValue Coin |
| Audited By | Seher Saylik, Andy Cho |
| Approved By | Ataberk Yavuzer |
| Website | https://evervaluecoin.com/→ |
| Changelog | 10/12/2024 - Preliminary Report |
| Changelog | 11/02/2025 - Final Report |
| Platform | Arbitrum network |
| Language | Solidity |
| Tags | OrderBook, ERC-20, DEX |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for EverValue Coin
- Audited By
- Seher Saylik, Andy Cho
- Approved By
- Ataberk Yavuzer
- Website
- https://evervaluecoin.com/→
- Changelog
- 10/12/2024 - Preliminary Report
- Changelog
- 11/02/2025 - Final Report
- Platform
- Arbitrum network
- Language
- Solidity
- Tags
- OrderBook, ERC-20, DEX
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/devervalue/orderbook→ |
| Commit | c591236 |
Review Scope
- Repository
- https://github.com/devervalue/orderbook→
- Commit
- c591236
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
During the audit, five issues were identified: two high, two medium, and one low. The development team promptly addressed and resolved two high, one medium, and one low-severity issue, which were subsequently retested and approved in the final review. One medium-severity issue is acknowledged, as the team confirmed they will not use fee-on-transfer functionality.
This report reflects the final state of the code after all necessary fixes and improvements were implemented.
Documentation quality
Functional requirements are provided.
Technical description is provided.
Code quality
The development environment is configured.
Test coverage
Code coverage of the project is 100% (branch coverage).
Deployment and basic user interactions are covered with tests.
Negative cases coverage is covered.
Interactions by several users are tested thoroughly.
System Overview
The OrderBook Smart Contract is an on-chain decentralized exchange (DEX) implementation that aims to provide a fully transparent and efficient trading platform for ERC20 tokens. Unlike traditional Automated Market Maker (AMM) based DEXes, this system implements a limit order book model, similar to those used in centralized exchanges.
OrderBookFactory — main orderbook contract that manages the creation and administration of order books for trading pairs, allowing users to place and manage buy/sell orders efficiently. It supports features like adding new pairs, updating fees, pausing operations.
OrderBookLib — A library for managing an order book.
PairLib — A library designed for managing trading pairs and their associated order books in decentralized exchanges. It supports creating, canceling, and matching buy/sell orders while handling functionalities such as maintaining trader-specific registries, tracking order states, and calculating trading fees.
QueueLib — A library that implements a queue data structure.
RedBlackTreeLib — A library that implements a Red-Black Tree data structure.
Privileged roles
The owner role can add new pairs, change the enabled status for a trading pair, update the fee for a specific trading pair, set a new fee recipient address for a specific order book, and pause/unpause the contract.
Potential Risks
Insufficient Multi-signature Controls for Critical Functions: The lack of multi-signature requirements for key operations centralizes decision-making power, increasing vulnerability to single points of failure or malicious insider actions, potentially leading to unauthorized transactions or configuration changes.
The reliance on off-chain price management and user responsibility for accurate decimals handling introduces a potential risk of incorrect price submissions, which might result in token mispricing. Without on-chain validation or adjustment for token decimals, the system remains susceptible to errors or exploitation if backend systems or user inputs are compromised.
The matchOrder function's loop, while capped at 1500 iterations, poses a potential DoS risk as processing large orders involving numerous matching transactions could consume excessive gas. This may prevent the completion of order processing, disrupting contract operations for legitimate users.
Findings
console importCode ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2024-7557 | Stuck Order Matching Due to Blacklisted Addresses | fixed | High | |
| F-2025-8721 | Exploitable Order Quantity Leading to Fund Loss | fixed | High | |
| F-2024-7553 | Vulnerability to Fee-on-Transfer Accounting Issues | accepted | Medium | |
| F-2025-8551 | Rounding Issue in fillOrder and partiallyFillOrder Allows Free Token Transfer | fixed | Medium | |
| F-2024-7555 | Use Ownable2Step Rather Than Ownable | fixed | Low | |
| F-2024-7559 | Shortcircuit Rules Can Be Used To Optimize Some Gas Usage | accepted | Observation | |
| F-2024-7556 | Violation of Checks-Effects-Interactions (CEI) Pattern in cancelOrder() | fixed | Observation | |
| F-2024-7554 | Redundant Quantity Check in addNewOrder Function | fixed | Observation | |
| F-2024-7535 | Floating pragma | fixed | Observation | |
| F-2024-7531 | Remove console import | fixed | Observation |
Appendix 1. Definitions
Severities
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. |
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.
Potential Risks
The "Potential Risks" section identifies issues that are not direct security vulnerabilities but could still affect the project’s performance, reliability, or user trust. These risks arise from design choices, architectural decisions, or operational practices that, while not immediately exploitable, may lead to problems under certain conditions. Additionally, potential risks can impact the quality of the audit itself, as they may involve external factors or components beyond the scope of the audit, leading to incomplete assessments or oversight of key areas. This section aims to provide a broader perspective on factors that could affect the project's long-term security, functionality, and the comprehensiveness of the audit findings.
Appendix 2. Scope
The scope of the project includes the following smart contracts from the provided repository:
Scope Details | |
|---|---|
| Repository | https://github.com/devervalue/orderbook→ |
| Commit | c591236aab86b61df2d23630b4b9d192db65a606 |
| Retest commit | 151647111838bf904e2a9a27f8afc5575f9a2cc0 |
| Whitepaper | https://evervaluecoin.com/white-paper/→ |
| Requirements | https://github.com/devervalue/orderbook/blob/master/README.md→ |
| Technical Requirements | https://github.com/devervalue/orderbook/blob/master/README.md→ |
| Deployed contracts | OrderBookFactory - 0x03339ECAE41bc162DAcAe5c2A275C8f64D6c80A0 (Arbirtum Chain) |
Scope Details
- Repository
- https://github.com/devervalue/orderbook→
- Commit
- c591236aab86b61df2d23630b4b9d192db65a606
- Retest commit
- 151647111838bf904e2a9a27f8afc5575f9a2cc0
- Whitepaper
- https://evervaluecoin.com/white-paper/→
- Technical Requirements
- https://github.com/devervalue/orderbook/blob/master/README.md→
- Deployed contracts
- OrderBookFactory - 0x03339ECAE41bc162DAcAe5c2A275C8f64D6c80A0 (Arbirtum Chain)
Assets in Scope
Appendix 3. Additional Valuables
Verification of System Invariants
During the audit of EverValue Coin, Hacken followed its methodology by performing fuzz-testing on the project's main functions. Foundry →, a tool used for fuzz-testing, was employed to check how the protocol behaves under various inputs. Due to the complex and dynamic interactions within the protocol, unexpected edge cases might arise. Therefore, it was important to use fuzz-testing to ensure that several system invariants hold true in all situations.
Fuzz-testing allows the input of many random data points into the system, helping to identify issues that regular testing might miss. A specific, 11 invariants were tested over 50,000 runs. This thorough testing ensured that the system works correctly even with unexpected or unusual inputs.
Invariant | Test Result | Run Count |
|---|---|---|
RedBlackTreeLib::insert. RedBlackTreeLib::remove should insert and remove consistenly | Passed | 50k |
RedBlackTreeLib::remove multiple random removal should adjust the first price correctly | Passed | 50k |
RedBlackTreeLib::next should bring the correct next price | Passed | 50k |
RedBlackTreeLib::next should bring the correct prev price | Passed | 50k |
PairLib::addBuyOrder add any orders successfully | Passed | 50k |
PairLib::cancelOrder remove any orders successfully | Passed | 50k |
OrderBookFactory::addPair add pairs successfully | Passed | 100k |
OrderBookFactory::setPairStatus set the pair status successfully | Passed | 100k |
OrderBookFactory::setPairFee set the pair fee successfully | Passed | 100k |
OrderBookFactory::setPairFeeAddress set the pair fee address successfully | Passed | 100k |
OrderBookFactory::addNewOrder add new orders successfully | Passed | 100k |
Invariant
RedBlackTreeLib::insert.RedBlackTreeLib::removeshould insert and remove consistenlyTest Result
- Passed
Run Count
- 50k
Invariant
RedBlackTreeLib::removemultiple random removal should adjust the first price correctlyTest Result
- Passed
Run Count
- 50k
Invariant
RedBlackTreeLib::nextshould bring the correct next priceTest Result
- Passed
Run Count
- 50k
Invariant
RedBlackTreeLib::nextshould bring the correct prev priceTest Result
- Passed
Run Count
- 50k
Invariant
PairLib::addBuyOrderadd any orders successfullyTest Result
- Passed
Run Count
- 50k
Invariant
PairLib::cancelOrderremove any orders successfullyTest Result
- Passed
Run Count
- 50k
Invariant
OrderBookFactory::addPairadd pairs successfullyTest Result
- Passed
Run Count
- 100k
Invariant
OrderBookFactory::setPairStatusset the pair status successfullyTest Result
- Passed
Run Count
- 100k
Invariant
OrderBookFactory::setPairFeeset the pair fee successfullyTest Result
- Passed
Run Count
- 100k
Invariant
OrderBookFactory::setPairFeeAddressset the pair fee address successfullyTest Result
- Passed
Run Count
- 100k
Invariant
OrderBookFactory::addNewOrderadd new orders successfullyTest Result
- Passed
Run Count
- 100k
Additional Recommendations
The smart contracts in the scope of this audit could benefit from the introduction of automatic emergency actions for critical activities, such as unauthorized operations like ownership changes or proxy upgrades, as well as unexpected fund manipulations, including large withdrawals or minting events. Adding such mechanisms would enable the protocol to react automatically to unusual activity, ensuring that the contract remains secure and functions as intended.
To improve functionality, these emergency actions could be designed to trigger under specific conditions, such as:
Detecting changes to ownership or critical permissions.
Monitoring large or unexpected transactions and minting events.
Pausing operations when irregularities are identified.
These enhancements would provide an added layer of security, making the contract more robust and better equipped to handle unexpected situations while maintaining smooth operations.