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 | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for EverValue Coin |
| Audited By | Kornel Światłowski |
| Approved By | Khrystyna Tkachuk |
| Website | https://evervaluecoin.com/→ |
| Changelog | 01/09/2026- Preliminary Report |
| 18/09/2026- Final Report | |
| Platform | Arbitrum |
| Language | Solidity |
| Tags | ERC721, Vault, Staking, Centralization, Marketplace |
| Methodology | https://docs.hacken.io/methodologies/smart-contracts→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for EverValue Coin
- Audited By
- Kornel Światłowski
- Approved By
- Khrystyna Tkachuk
- Website
- https://evervaluecoin.com/→
- Changelog
- 01/09/2026- Preliminary Report
- 18/09/2026- Final Report
- Platform
- Arbitrum
- Language
- Solidity
- Tags
- ERC721, Vault, Staking, Centralization, Marketplace
Review Scope | |
|---|---|
| Repository | https://github.com/devervalue/evervaluecoin→ |
| Commit | 679b75ce99883f4907479710f2b9dc4fb42edfcc |
| Final Commit | 869ce44932964450a57c804b636387f293903745 |
Review Scope
- Commit
- 679b75ce99883f4907479710f2b9dc4fb42edfcc
- Final Commit
- 869ce44932964450a57c804b636387f293903745
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Project overview is provided (
README.mdandAPI.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, andRevenueRouterusefully 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.20is appropriate on production contracts.OpenZeppelin v5 patterns are used (
SafeERC20,ReentrancyGuard,Ownablevariants).
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-onlydistribute(banked intoundistributedwhentotalSharesis zero), and owner-proposed renewals accepted viaacceptRenewal; lock fees and early-exit burns call core-vaultbackingWithdrawunless 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, andcancel; buyers callbuywith amaxPrice; unfulfillable listings are removed viapruneStale;isFulfillablechecks ownership, approval, andstartSnapshotagainst renewal.RevenueRouter.sol — Ownable WBTC splitter with allowlisted
pay. Each payment is split across a core-vault transfer, an active SLS transfer orincreaseBacking(folded to core if no vault or token mismatch), and EVALockerdistributevia approve-and-call; construction requires lockerwbtcand corewbtcAddressto matchbackingToken; the owner mayrescueany ERC-20.
Privileged roles
EVALockersol
owner (inherited from Ownable): Configures lock parameters, manages renewal offers, and sweeps surplus tokens.
Can call
proposeRenewalto propose new terms for a position and escrow EVA and/or WBTC prizes.Can call
cancelRenewalto cancel a pending renewal offer and reclaim escrowed prizes.Can call
setTierCurveto set the early-exit curve assigned to future locks in a tier.Can call
setTierEnabledto enable or disable opening of new locks in a tier.Can call
setDistributorto set the address authorized to calldistribute.Can call
setLocksPausedto pause or unpause opening of new locks.Can call
setLockFeeto set the lock fee in basis points (capped atMAX_LOCK_FEE_BPS).Can call
setMinLockAmountto set the minimum EVA required to open a position.Can call
setBaseURIto set the ERC-721 metadata base URI.Can call
sweepWbtcto transfer surplus WBTC above unclaimed rewards and escrow to a recipient.Can call
sweepEvato transfer surplus EVA above locked and escrowed amounts to a recipient.Can call
transferOwnershipto transfer contract ownership.Can call
renounceOwnershipto renounce contract ownership.
distributor: Sole address authorized to credit WBTC rewards into the locker pool.
Can call
distributeto 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
setMinListAmountto set the minimum locked-EVA size required to list a position.Can call
transferOwnershipto transfer contract ownership.Can call
renounceOwnershipto renounce contract ownership.
RevenueRoutersol
owner (inherited from Ownable): Manages payment callers and token recovery.
Can call
setCallerto grant or revoke authorization to callpay.Can call
rescueto transfer any ERC-20 tokens held by the router to a recipient.Can call
transferOwnershipto transfer contract ownership.Can call
renounceOwnershipto renounce contract ownership.
allowedCaller: Authorized to execute revenue splits from the router's WBTC balance.
Can call
payto 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-1910 | Missing Purchase Price Bound Enables Uncapped Wallet Drain | fixed | High | |
| F-2026-1910 | Missing Zero-Payout Waiver Blocks Early Exit Until Maturity | fixed | Medium | |
| F-2026-1910 | Unchecked Vault Token Identity Permanently Locks Payer Revenue | fixed | Medium | |
| F-2026-1904 | Missing Stake-Age Gate In distribute Allows Flash-Lock Yield Capture | accepted | Medium | |
| F-2026-1911 | Missing Monotonic End-Time Guard Allows Live Term Shortening | fixed | Low | |
| F-2026-1910 | Unusable Admin Recipient In Offer Refund Freezes Locked Principal | fixed | Low | |
| F-2026-1908 | Missing Two Step Ownership Pattern | unfixed | 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/evervaluecoin→ |
| Commit | 679b75ce99883f4907479710f2b9dc4fb42edfcc |
| Final Commit | 869ce44932964450a57c804b636387f293903745 |
| Whitepaper | - |
| Requirements | README.md, LockerReadme.md, API.md |
| Technical Requirements | README.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
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.