Introduction
We express our gratitude to the Overlayer team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
The Overlayer protocol is built on top of Ethereum to enhance existing stablecoins by minting overlaid assets backed by Aave. It embeds yield generation, censorship resistance, and trustless access directly into the asset design.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Overlayer |
| Audited By | Khrystyna Tkachuk, Kerem Solmaz |
| Approved By | Ivan Bondar |
| Website | https://overlayer.fi/→ |
| Changelog | 27/02/2026 - Preliminary Report |
| 13/05/2026 - Final Report | |
| Platform | Ethereum, Base |
| Language | Solidity |
| Tags | ERC20, ERC4626, Yield Farming, Staking, Vault, Permit Token |
| Methodology | https://docs.hacken.io/methodologies/smart-contracts→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Overlayer
- Audited By
- Khrystyna Tkachuk, Kerem Solmaz
- Approved By
- Ivan Bondar
- Website
- https://overlayer.fi/→
- Changelog
- 27/02/2026 - Preliminary Report
- 13/05/2026 - Final Report
- Platform
- Ethereum, Base
- Language
- Solidity
- Tags
- ERC20, ERC4626, Yield Farming, Staking, Vault, Permit Token
Review Scope | |
|---|---|
| Repository | https://github.com/Overlayerfi/contracts/tree/main→ |
| Initial Commit | 471a134 |
| Final Commit | 5444017 |
Review Scope
- Initial Commit
- 471a134
- Final Commit
- 5444017
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
{Finding_Table?columns=title,severity,status&setting.filter.type=Vulnerability}
Documentation quality
NatSpec comments are comprehensive across all public and external functions.
Technical description is provided via auto-generated solidity-docgen output and a README with mint/redeem/stake/compound flow overview.
A formal protocol specification document (whitepaper or spec) is not provided.
Code quality
The project makes extensive use of OpenZeppelin v5.0.2 contracts (ERC20, ERC4626, AccessControl, ReentrancyGuard, SafeERC20, Pausable) and LayerZero OFT for cross-chain functionality.
The development environment is properly configured with multi-compiler Hardhat setup, Prettier formatting, and Solhint linting.
Test coverage
Code coverage of the project is 50% (branch coverage).
Core user flows (mint, redeem, staking, cooldown, Aave supply/compound), negative cases, and multi-user scenarios are covered.
Administrative lifecycle functions and the OverlayerBacking proxy have limited coverage.
System Overview
Overlayer is a collateral-backed stablecoin protocol built on EVM-compatible chains. The system centers on OverlayerWrap, an ERC20 stablecoin with mint and redeem against configured collateral (and its Aave interest-bearing aToken). Minting and redeeming are rate-limited per block where minting can be paused; blacklisting is supported with a time-delayed activation (15 days). The protocol uses LayerZero OFT for cross-chain transfers to a designated hub chain.
Collateral is managed through a time-delayed collateral spender pattern: a new spender is proposed by a collateral manager role and must be accepted by the proposed contract after a 10-day interval, limiting single-point-of-failure risk. The OverlayerBacking contract acts as the backing manager entry point, inheriting AaveHandler to supply and withdraw collateral on Aave v3, compound yield, and distribute rewards between the staking vault and a protocol rewards dispatcher.
Staking is implemented via StakedOverlayerWrap, an ERC4626 vault that wraps OverlayerWrap. It supports a cooldown mechanism: when enabled, users request unstake and wait a configurable cooldown (up to 90 days) before withdrawing. During cooldown, shares are burned and the underlying tokens are held in OverlayerWrapSilo, which only the staking vault can withdraw from. StakedOverlayerWrapCore adds blacklisting (with time-delayed activation), redistribution of blacklisted balances, and reward distribution; it triggers backing compound() on mint to harvest yield before new share issuance.
The StakedOverlayerWrap vault does not implement explicit “rewards per share” or epoch-based accounting. Instead, yield is distributed implicitly through share price appreciation, consistent with the ERC4626 vault model, where rewards are reflected in totalAssets(). Deposits and withdrawals occur at the current share price, and deposit/withdraw operations trigger compound() before minting or burning shares. This ensures that accrued yield is realized and reflected in the vault state prior to share supply changes, preserving proportional ownership across participants.
Access control is implemented through SingleAdminAccessControl, a custom pattern on top of OpenZeppelin AccessControl with a single admin, two-step admin transfer (propose + accept), and restrictions on granting or renouncing the admin role directly.
Files in scope
OverlayerWrap.sol – Primary stablecoin token contract. Implements ERC20 functionality and exposes mint and redeem entry points. Includes blacklisting functionality with time-delayed activation.
OverlayerWrapCore.sol – Implements the core mint and redeem logic. Enforces per-block rate limiting (maximum mint/redeem per block with optional whitelist bypass), pause controls, collateral spender validation, and LayerZero OFT integration. Minting and redemption are restricted to the designated hub chain.
CollateralSpenderManager.sol – Manages the collateral spender role with a time-delay mechanism. A new collateral spender must be proposed and can accept the role only after a 10-day delay. Only the proposed address may finalize acceptance. Exposes the currently approved collateral spender for collateral transfers.
OverlayerWrapCollateral.sol – Stores collateral configuration parameters, including main collateral and corresponding aToken addresses and decimals. Serves as a base contract for collateral-aware components. Uses
SingleAdminAccessControlfor administrative initialization and management.StakedOverlayerWrap.sol – ERC4626-compliant staking vault for OverlayerWrap with an optional cooldown mechanism. When cooldown is enabled, users must request unstaking and wait for the cooldown period before claiming assets from the silo. May trigger backing
compound(). Manages cooldown duration and silo integration.StakedOverlayerWrapCore.sol – Implements core staking functionality. Includes ERC4626 logic, blacklisting with time-delayed activation, redistribution of blacklisted balances, and reward distribution via
transferInRewards().OverlayerWrapSilo.sol – Escrow contract used during the cooldown period. Holds OverlayerWrap tokens between unstake request and claim. Only the staking vault is authorized to withdraw funds.
OverlayerBacking.sol – Entry point for backing allocation management. Inherits
AaveHandler. Accepts the collateral spender role from OverlayerWrap and provides asset recovery functionality (excluding protocol-designated collateral).AaveHandler.sol – Integrates with Aave v3 for collateral supply and withdrawal. Implements yield compounding by minting OverlayerWrap from surplus aToken balances and distributing rewards between the staking vault and dispatcher. Supports time-delayed updates to the Aave pool and rewards allocation parameters.
supply()is callable by OverlayerWrap;compound()is permissionless.SingleAdminAccessControl.sol – Custom access control module with a single default admin. Implements two-step admin transfer (propose and accept). Supports role grant, revoke, and renounce operations, with additional protection preventing external grant or renounce of the default admin role.
OverlayerWrapCoreTypes.sol – Defines shared data structures used across the system, including:
Order(benefactor, beneficiary, collateral, amounts) for mint and redeem operations.StableCoin(address, decimals) for collateral configuration.
Privileged roles
OverlayerWrap / OverlayerWrapCore:
DEFAULT_ADMIN_ROLE- Grant/revoke all other roles; can callsetMaxMintPerBlock,executeMaxRedeemPerBlockChange,proposeMaxRedeemPerBlock,whitelistMaxRedeemPerBlockUser,rescueNative; remove collateral managers (removeCollateralManagerRole).GATEKEEPER_ROLE– can disable mint and pause/unpause supply backing functionalityCOLLATERAL_MANAGER_ROLE– can propose new collateral spender (10-day delay); can callapproveCollateral(approve token allowances for current spender).CONTROLLER_ROLE– candisableAccount/enableAccountenforsing blacklisting for the account.BLACKLISTED_ROLE– accounts with this role cannot mint, redeem, or transfer (treated as disabled).
CollateralSpenderManager:
COLLATERAL_MANAGER_ROLE– can propose new collateral spender.
StakedOverlayerWrapCore:
DEFAULT_ADMIN_ROLE– can manageOverlayerWrapBackingaddress.REWARDER_ROLE– can transfer OverlayerWrap rewards into the vault viatransferInRewards().CONTROLLER_ROLE– set blacklisted roles (when blacklist is active); can enable blacklist and redistribution by calling appropriatelysetBlackListTime/setRedistributionTime.STAKE_RESTRICTED_ROLE– account with this role cannot stake or receive shares via deposit/mint.WHOLE_RESTRICTED_ROLE– account with this role cannot transfer, stake, unstake, or withdraw; balance can be redistributed by admin viaredistributeLockedAmount.
StakedOverlayerWrap:
DEFAULT_ADMIN_ROLE– can callsetCooldownDuration(),setWithdrawAaveDuringCompound()
OverlayerWrapSilo:
_STAKING_VAULT– Only the staking vault address (immutable) can call withdraw.
OverlayerBacking:
Owner – accept collateral spender, recover non-protocol assets.
AaveHandler:
Owner – admin withdraw, propose/accept Aave and dispatcher allocation, approvals; onlyProtocol for supply (OverlayerWrap only).
OverlayerWrap (protocol) – only OverlayerWrap can call
supply()(onlyProtocol).
Potential Risks
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 AaveHandler logic depends on external contract OvaDispatcher not covered by the audit. This reliance introduces risks if these external contracts are compromised or contain vulnerabilities, affecting the audited project's integrity.
Interactions with External DeFi Protocols: Dependence on external DeFi protocols (Aave, LayerZero) inherits their risks and vulnerabilities. This might lead to direct financial losses if these protocols are exploited, indirectly affecting the audited project.
Single Points of Failure and Control: Parts of the system rely on a limited set of privileged roles and operational processes. All privileged functions are secured through a Gnosis Safe multi-signature wallet. While this setup simplifies coordination and introduces additional protective mechanisms, it also means that overall availability and decision execution may depend on a small number of entities, increasing sensitivity to operational issues or targeted compromise.
Aave Liquidity Constraints May Delay Direct Redemption of Collateral Token: Redemption into the underlying stablecoin (USDC/USDT) depends on the liquidity conditions of the respective Aave pool. During periods of high utilization or temporary market stress, immediate withdrawal of the base asset from Aave may be limited. However, users are still able to redeem their position from Overlayer by receiving the corresponding Aave aToken on a 1:1 basis. In such cases, the limitation only affects the instant withdrawal of base liquidity from Aave, not the ability to exit the Overlayer protocol or maintain exposure to the underlying interest-bearing position.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2026-1698 | [DualDefense] _credit() Arithmetic Underflow on Non-Hub Chains Causes Permanent Loss of All Cross-Chain Bridged Tokens | fixed | Critical | |
| F-2026-1525 | Hub Chain OverLayer Supply Reduction After OFT Transfers Lead to supply() DoS | fixed | High | |
| F-2026-1523 | Users Can Renounce BLACKLISTED_ROLE and Bypass Administrative Restrictions | fixed | High | |
| F-2026-1524 | Default Admin Can Assign Blacklisted Role Without Enforcing Blacklist Activation Constraints | fixed | Medium | |
| F-2026-1522 | Cooldown Timer Reset on Repeated Calls Leads to Extended Staking on Previously Queued Assets | fixed | Medium | |
| F-2026-1523 | Emergency Disable Function Only Halts Minting Despite NatSpec Claiming Both Mint And Redeem Are Disabled | fixed | Low | |
| F-2026-1523 | Instant Change Of Backing Contract Address Can Disable All Vault Operations | fixed | Low | |
| F-2026-1698 | [DualDefense] Blacklist Bypass via StakedOverlayerWrap Redemption to Unblacklisted Address | fixed | Low | |
| F-2026-1698 | [DualDefense] Denial of Service (DoS) in supplyToBacking via AaveHandler Accounting Desync | fixed | Low | |
| F-2026-1698 | [DualDefense] adminWithdraw Drains Entire Protocol TVL to Reward Pool | fixed | Low |
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/Overlayerfi/contracts/tree/main→ |
| Initial Commit | 471a134a41218fe145dd10be570d8a6755b25b7c |
| Final Commit | 544401733f3c84f3efcbe061b189cb651c156261 |
| Whitepaper | N/A |
| Requirements | ./Readme.md |
| Technical Requirements | ./Readme.md |
Scope Details
- Initial Commit
- 471a134a41218fe145dd10be570d8a6755b25b7c
- Final Commit
- 544401733f3c84f3efcbe061b189cb651c156261
- Whitepaper
- N/A
- Requirements
- ./Readme.md
- Technical Requirements
- ./Readme.md
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.