Q1 2026 Security & Compliance Report44 incidents, $482M in losses, insights from 11 industry leaders.
Read the report

Audit name:

[SCA] Overlayer | Wrap | Feb2026

Date:

Mar 12, 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 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

NameSmart Contract Code Review and Security Analysis Report for Overlayer
Audited ByKhrystyna Tkachuk, Kerem Solmaz
Approved ByIvan Bondar
Websitehttps://overlayer.fi/
Changelog27/02/2026 - Preliminary Report
13/05/2026 - Final Report
PlatformEthereum, Base
LanguageSolidity
TagsERC20, ERC4626, Yield Farming, Staking, Vault, Permit Token
Methodologyhttps://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
    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

Repositoryhttps://github.com/Overlayerfi/contracts/tree/main
Initial Commit471a134
Final Commit5444017

Audit Summary

15Total Findings
15Resolved
0Accepted
0Mitigated

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 SingleAdminAccessControl for 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 call setMaxMintPerBlock, executeMaxRedeemPerBlockChange, proposeMaxRedeemPerBlock, whitelistMaxRedeemPerBlockUser, rescueNative; remove collateral managers ( removeCollateralManagerRole).

  • GATEKEEPER_ROLE – can disable mint and pause/unpause supply backing functionality

  • COLLATERAL_MANAGER_ROLE – can propose new collateral spender (10-day delay);  can call approveCollateral (approve token allowances for current spender).

  • CONTROLLER_ROLE – can disableAccount / enableAccount enforsing 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 manage OverlayerWrapBacking address.

  • REWARDER_ROLE – can transfer OverlayerWrap rewards into the vault via transferInRewards().

  • CONTROLLER_ROLE –  set blacklisted roles (when blacklist is active); can enable blacklist and redistribution by calling appropriately setBlackListTime / 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 via redistributeLockedAmount.

StakedOverlayerWrap:

  • DEFAULT_ADMIN_ROLE – can call setCooldownDuration(), 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-1525Hub Chain OverLayer Supply Reduction After OFT Transfers Lead to supply() DoS
fixed

High
F-2026-1523Users Can Renounce BLACKLISTED_ROLE and Bypass Administrative Restrictions
fixed

High
F-2026-1524Default Admin Can Assign Blacklisted Role Without Enforcing Blacklist Activation Constraints
fixed

Medium
F-2026-1522Cooldown Timer Reset on Repeated Calls Leads to Extended Staking on Previously Queued Assets
fixed

Medium
F-2026-1523Emergency Disable Function Only Halts Minting Despite NatSpec Claiming Both Mint And Redeem Are Disabled
fixed

Low
F-2026-1523Instant 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
1-10 of 15 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/Overlayerfi/contracts/tree/main
Initial Commit471a134a41218fe145dd10be570d8a6755b25b7c
Final Commit544401733f3c84f3efcbe061b189cb651c156261
WhitepaperN/A
Requirements./Readme.md
Technical Requirements./Readme.md

Assets in Scope

contracts
overlayer
CollateralSpenderManager.sol - contracts › overlayer › CollateralSpenderManager.sol
interfaces
IOverlayerWrapDefs.sol - contracts › overlayer › interfaces › IOverlayerWrapDefs.sol
OverlayerWrap.sol - contracts › overlayer › OverlayerWrap.sol
OverlayerWrapCollateral.sol - contracts › overlayer › OverlayerWrapCollateral.sol
OverlayerWrapCore.sol - contracts › overlayer › OverlayerWrapCore.sol
OverlayerWrapSilo.sol - contracts › overlayer › OverlayerWrapSilo.sol
StakedOverlayerWrap.sol - contracts › overlayer › StakedOverlayerWrap.sol
StakedOverlayerWrapCore.sol - contracts › overlayer › StakedOverlayerWrapCore.sol
types
OverlayerWrapCoreTypes.sol - contracts › overlayer › types › OverlayerWrapCoreTypes.sol
overlayerbacking
AaveHandler.sol - contracts › overlayerbacking › AaveHandler.sol
OverlayerBacking.sol - contracts › overlayerbacking › OverlayerBacking.sol
shared
SingleAdminAccessControl.sol - contracts › shared › SingleAdminAccessControl.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