Q2 2026 Security & Compliance Report67 incidents, $764M in losses, 88% from operational failures.
Get the report →

Audit name:

[SCA] EverValueCoin | Locker | Aug2026

Date:

Sep 18, 2026

Table of Content

→Introduction
→Audit Summary
→System Overview
→Potential Risks
→Findings
→Appendix 1. Definitions
→Appendix 2. Scope
→Appendix 3. Additional Valuables
→Disclaimer

Want a comprehensive audit report like this?

Introduction

We express our gratitude to the EverValue Coin team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.

The in-scope EVA subsystem on Arbitrum is a time-locked staking vault with an ERC-721 secondary market and a WBTC revenue router. EVA is locked into weighted, time-bounded positions that accrue WBTC yield; transferable positions may be sold for WBTC; and allowlisted callers split protocol WBTC across the core burn vault, the active SLS vault, and the locker reward pool.

Document

NameSmart Contract Code Review and Security Analysis Report for EverValue Coin
Audited ByKornel Światłowski
Approved ByKhrystyna Tkachuk
Websitehttps://evervaluecoin.com/→
Changelog01/09/2026- Preliminary Report
18/09/2026- Final Report
PlatformArbitrum
LanguageSolidity
TagsERC721, Vault, Staking, Centralization, Marketplace
Methodologyhttps://docs.hacken.io/methodologies/smart-contracts→

Review Scope

Repositoryhttps://github.com/devervalue/evervaluecoin→
Commit679b75ce99883f4907479710f2b9dc4fb42edfcc
Final Commit869ce44932964450a57c804b636387f293903745

Audit Summary

7Total Findings
5Resolved
1Accepted
0Mitigated

The system users should acknowledge all the risks summed up in the risks section of the report

Documentation quality

  • Project overview is provided (README.md and API.md) with architecture diagrams and subsystem write-ups.

  • Roles, use cases, and features are covered for the core path and in depth for the locker and SLS subsystems.

  • NatSpec on EVALocker, PositionMarket, and RevenueRouter usefully supplements the functional docs.

Code quality

  • Run instructions and a Hardhat environment are present (npm install, test, coverage); Ignition and deploy scripts exist.

  • Local Hardhat setup works without external keys; Solidity 0.8.20 is appropriate on production contracts.

  • OpenZeppelin v5 patterns are used (SafeERC20, ReentrancyGuard, Ownable variants).

Test coverage

Code coverage of the project is 89.83% (branch coverage).

  • Deployment and basic user interactions are covered with tests.

System Overview

EVALocker, PositionMarket, and RevenueRouter form the lock-and-revenue slice of the EVA protocol. Users lock out-of-scope EverValueCoin into EVALocker, which custodially holds that ERC-20 and mints an ERC-721 position NFT. Live positions earn WBTC from a weighted single-pool accumulator funded when RevenueRouter, as the locker's distributor, calls distribute. Transferable NFTs may be sold for WBTC on PositionMarket without escrow; the seller keeps the NFT and continues to accrue until buy pays the seller and moves the token, at which point the locker's transfer hook settles rewards to the seller. Out-of-scope EVABurnVault, SLSburnVaultFactory, and SLSburnVault sit on the burn and SLS legs of the same revenue path.

EVALocker inherits ERC-721, ERC-721Enumerable, Ownable, and ReentrancyGuard. lock opens a position in an enabled deployment-time tier; shares equal net principal times the immutable tier weight. Tiers cannot be added or reweighted after deployment; only defaultCurve and enabled are owner-settable. Accrued WBTC is taken via claim, claimMany, or claimAll. Matured positions return full principal through withdraw. earlyExit returns a curve-determined liquid EVA fraction and force-burns the remainder against EVABurnVault via backingWithdraw, forwarding received WBTC to the position owner. Lock fees use the same vault call, send received WBTC to the distributor, and are waived when the pre-quoted payout is zero sats, the distributor is the zero address, or EVA supply is zero. distribute is restricted to the configured distributor and banks the payment into undistributed when totalShares is zero. Owner-proposed renewals escrow EVA and WBTC prizes; acceptRenewal compounds EVA into the position, pays WBTC immediately, restarts the early-exit clock, and may reactivate a matured position. ERC-721 transfers settle accrued rewards to the seller and refund any open renewal offer; the curve clock is not reset. Non-transferable tiers reject the transfer. renounceOwnership is overridden to revert.

PositionMarket is an approval-based, non-escrow, fixed-price marketplace that settles locker NFTs in WBTC. list requires ownership, a transferable tier, and locked EVA of at least minListAmount. The seller may updatePrice or cancel. buy pulls WBTC from the buyer to the seller and the NFT from the seller to the buyer, subject to a buyer-supplied maxPrice. isFulfillable requires an active listing, continued seller ownership, market approval, and an unchanged startSnapshot versus the position startTime, so a post-list renewal invalidates the ask. Unfulfillable entries are removed permissionlessly via pruneStale. RevenueRouter is Ownable and holds the project's WBTC float. Allowlisted callers invoke pay with per-call basis-point splits that must sum to 10,000. The core share is transferred as ERC-20 WBTC to EVABurnVault. The SLS share is resolved through SLSburnVaultFactory activeVault: WBTC is transferred or deposited via increaseBacking, or folded into the core share when no vault is active or the vault backing token is not WBTC. The locker share is delivered by approving EVALocker and calling distribute. Construction requires that both the core vault wbtcAddress and the locker wbtc equal the router's backingToken. The owner may rescue any ERC-20.

Files in Scope

  • EVALocker.sol — Time-locked EVA staking that mints ERC-721 positions and pays WBTC through a weighted single-pool accumulator. Principal flows are lock, claim / claimMany / claimAll, withdraw, earlyExit, distributor-only distribute (banked into undistributed when totalShares is zero), and owner-proposed renewals accepted via acceptRenewal; lock fees and early-exit burns call core-vault backingWithdraw unless the fee or burn quote is waived.

  • PositionMarket.sol — Approval-based fixed-price WBTC marketplace for locker position NFTs, with no escrow. Sellers use list, updatePrice, and cancel; buyers call buy with a maxPrice; unfulfillable listings are removed via pruneStale; isFulfillable checks ownership, approval, and startSnapshot against renewal.

  • RevenueRouter.sol — Ownable WBTC splitter with allowlisted pay. Each payment is split across a core-vault transfer, an active SLS transfer or increaseBacking (folded to core if no vault or token mismatch), and EVALocker distribute via approve-and-call; construction requires locker wbtc and core wbtcAddress to match backingToken; the owner may rescue any ERC-20.

Privileged roles

EVALockersol

  • owner (inherited from Ownable): Configures lock parameters, manages renewal offers, and sweeps surplus tokens.

    • Can call proposeRenewal to propose new terms for a position and escrow EVA and/or WBTC prizes.

    • Can call cancelRenewal to cancel a pending renewal offer and reclaim escrowed prizes.

    • Can call setTierCurve to set the early-exit curve assigned to future locks in a tier.

    • Can call setTierEnabled to enable or disable opening of new locks in a tier.

    • Can call setDistributor to set the address authorized to call distribute.

    • Can call setLocksPaused to pause or unpause opening of new locks.

    • Can call setLockFee to set the lock fee in basis points (capped at MAX_LOCK_FEE_BPS).

    • Can call setMinLockAmount to set the minimum EVA required to open a position.

    • Can call setBaseURI to set the ERC-721 metadata base URI.

    • Can call sweepWbtc to transfer surplus WBTC above unclaimed rewards and escrow to a recipient.

    • Can call sweepEva to transfer surplus EVA above locked and escrowed amounts to a recipient.

    • Can call transferOwnership to transfer contract ownership.

    • Can call renounceOwnership to renounce contract ownership.

  • distributor: Sole address authorized to credit WBTC rewards into the locker pool.

    • Can call distribute to pull WBTC from the caller and credit it across live position shares.

PositionMarketsol

  • owner (inherited from Ownable): Configures listing size requirements and contract ownership.

    • Can call setMinListAmount to set the minimum locked-EVA size required to list a position.

    • Can call transferOwnership to transfer contract ownership.

    • Can call renounceOwnership to renounce contract ownership.

RevenueRoutersol

  • owner (inherited from Ownable): Manages payment callers and token recovery.

    • Can call setCaller to grant or revoke authorization to call pay.

    • Can call rescue to transfer any ERC-20 tokens held by the router to a recipient.

    • Can call transferOwnership to transfer contract ownership.

    • Can call renounceOwnership to renounce contract ownership.

  • allowedCaller: Authorized to execute revenue splits from the router's WBTC balance.

    • Can call pay to split held WBTC across the core vault, active SLS vault, and EVALocker per supplied basis-point shares.

Potential Risks

System Reliance on External Contracts: Core locking, revenue routing, and position-market settlement depend on externally deployed ERC-20 assets referenced only by address (wBTC / backing token and EVA) in EVALocker, RevenueRouter, and PositionMarket. Functions such as lock, distribute, pay, claim, and buy read balances and transfer those tokens. Misbehavior, freezes, or non-standard ERC-20 semantics in those external assets can halt or distort locker rewards, revenue splits, and NFT settlement.

Control Risks from Whitelisted Users: RevenueRouter gates pay behind isCallerAllowed. Allowed callers choose split parameters (coreBps / slsBps / lockerBps), whether to call increaseBacking, and any additionalEva coverage increase. Compromise or misuse of a whitelisted caller can redirect protocol WBTC float across the core vault, active SLS vault, and EVALocker without an owner transaction.

Coarse-Grained Authorization Model: A single Ownable owner on EVALocker, RevenueRouter, and PositionMarket controls disparate powers including renewals, distributor wiring, pauses, listing floors, and fund movement, with no contract-enforced multi-signature or governance quorum. Compromise of one owner key grants that full function surface on the affected contract rather than a narrowly scoped role.

Absence of Timelock Mechanisms for Critical Operations: Privileged paths such as RevenueRouter rescue and setCaller; EVALocker setDistributor, setLockFee, proposeRenewal, and sweeps; and PositionMarket setMinListAmount execute in the same transaction with no mandatory delay. Harmful or erroneous admin actions take effect before external observers can react on-chain.

Scope Definition and Security Guarantees: The audit does not cover all code in the repository. Contracts outside the audit scope may introduce vulnerabilities, potentially impacting the overall security due to the interconnected nature of smart contracts.

Dependency on External Logic for Implemented Logic: The implemented lock-fee conversion, early-exit redemption, and revenue-split logic highly depend on external contracts not covered by the audit (EVABurnVault, SLSburnVaultFactory, and SLSburnVault). EVALocker lock and earlyExit call EVABurnVault backingWithdraw and treat the measured WBTC delta as the payout to the distributor or the position owner. RevenueRouter pay reads SLSburnVaultFactory activeVault, queries SLSburnVault backingToken, and may invoke increaseBacking or transfer WBTC to those sinks. This reliance introduces risks if those excluded contracts are compromised or contain vulnerabilities, affecting locker exits, fee burns, and routed WBTC distribution.

Findings

Code
―
Title
Status
Severity
F-2026-1910Missing Purchase Price Bound Enables Uncapped Wallet Drain
fixed

High
F-2026-1910Missing Zero-Payout Waiver Blocks Early Exit Until Maturity
fixed

Medium
F-2026-1910Unchecked Vault Token Identity Permanently Locks Payer Revenue
fixed

Medium
F-2026-1904Missing Stake-Age Gate In distribute Allows Flash-Lock Yield Capture
accepted

Medium
F-2026-1911Missing Monotonic End-Time Guard Allows Live Term Shortening
fixed

Low
F-2026-1910Unusable Admin Recipient In Offer Refund Freezes Locked Principal
fixed

Low
F-2026-1908Missing Two Step Ownership Pattern
unfixed

Observation
1-7 of 7 findings

Identify vulnerabilities in your smart contracts.

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

Repositoryhttps://github.com/devervalue/evervaluecoin→
Commit679b75ce99883f4907479710f2b9dc4fb42edfcc
Final Commit869ce44932964450a57c804b636387f293903745
Whitepaper-
RequirementsREADME.md, LockerReadme.md, API.md
Technical RequirementsREADME.md, LockerReadme.md, API.md
  • Scope Details

    Commit
    679b75ce99883f4907479710f2b9dc4fb42edfcc
    Final Commit
    869ce44932964450a57c804b636387f293903745
    Whitepaper
    -
    Requirements
    README.md, LockerReadme.md, API.md
    Technical Requirements
    README.md, LockerReadme.md, API.md

Asset

Type

contractsEVALocker.sol [https://github.com/devervalue/evervaluecoin]Smart Contract
contractsPositionMarket.sol [https://github.com/devervalue/evervaluecoin]Smart Contract
contractsRevenueRouter.sol [https://github.com/devervalue/evervaluecoin]Smart Contract
  • Asset

    contractsEVALocker.sol [https://github.com/devervalue/evervaluecoin]

    Type

    Smart Contract

    Asset

    contractsPositionMarket.sol [https://github.com/devervalue/evervaluecoin]

    Type

    Smart Contract

    Asset

    contractsRevenueRouter.sol [https://github.com/devervalue/evervaluecoin]

    Type

    Smart Contract

Assets in Scope

contracts\EVABurnVault.sol - contracts\EVABurnVault.sol
contracts\EVALocker.sol - contracts\EVALocker.sol
contracts\EVAMarket.sol - contracts\EVAMarket.sol
contracts\EVAMarketWbtc.sol - contracts\EVAMarketWbtc.sol
contracts\EverValueCoin.sol - contracts\EverValueCoin.sol
contracts\Payer.sol - contracts\Payer.sol
contracts\PositionMarket.sol - contracts\PositionMarket.sol
contracts\RevenueRouter.sol - contracts\RevenueRouter.sol
contracts\SLSburnVault.sol - contracts\SLSburnVault.sol
contracts\SLSburnVaultFactory.sol - contracts\SLSburnVaultFactory.sol
contracts\SLSPayer.sol - contracts\SLSPayer.sol
contracts\token.sol - contracts\token.sol

Appendix 3. Additional Valuables

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.

Frameworks and Methodologies

This security assessment was conducted in alignment with recognised penetration testing standards, methodologies and guidelines, including the NIST SP 800-115 – Technical Guide to Information Security Testing and Assessment →, and the Penetration Testing Execution Standard (PTES) →, These assets provide a structured foundation for planning, executing, and documenting technical evaluations such as vulnerability assessments, exploitation activities, and security code reviews. Hacken’s internal penetration testing methodology extends these principles to Web2 and Web3 environments to ensure consistency, repeatability, and verifiable outcomes.

Disclaimer