Overlayer Disclosed Report

Summary

While testing the LayerZero OFT integration in the audited code, I found that OverlayerWrapCore._credit() contains an arithmetic underflow that causes any token bridging from the hub chain to a spoke chain to permanently destroy user funds. The bug requires no privileged access and is deterministic — every bridge attempt fails identically. Beyond the direct token loss, the underflow permanently corrupts the protocol's Aave collateral accounting -- totalBridgedOut has no setter and the contracts are non-upgradeable, so the accounting error persists indefinitely even if admins manually recover collateral.

---

Vulnerability Details

Root Cause

I traced the bug to OverlayerWrapCore.sol, which overrides the LayerZero OFT _credit() function to track cross-chain token flows via a state variable called totalBridgedOut. The full override at lines 537–544:

function _credit(
    address to_,
    uint256 amountLD_,
    uint32 srcEid_
) internal virtual override returns (uint256 amountReceivedLD) {
    amountReceivedLD = super._credit(to_, amountLD_, srcEid_);
    totalBridgedOut -= amountReceivedLD;  // underflows on spoke chains
}

The companion _debit() override at lines 510–528 increments totalBridgedOut when tokens leave the hub:

totalBridgedOut += amountSentLD;

On the hub chain, this is balanced: _debit always executes before _credit for any given token flow. By the time _credit runs on the hub (tokens returning), totalBridgedOut has already been incremented. Safe.

On a spoke chain, the invariant does not hold. totalBridgedOut is declared at line 63 as uint256 public totalBridgedOut with no initializer, no constructor parameter, and no setter. Default value: 0. When LayerZero delivers a bridge message to the spoke chain and calls _credit(), the subtraction 0 - amountReceivedLD triggers Solidity 0.8.20 checked-arithmetic, reverting with Panic(0x11). The tokens never mint. The message permanently fails.

I noticed the spoke chain is stuck in an unresolvable deadlock:

• To receive tokens via _credit(): totalBridgedOut must be positive
• To make it positive: _debit() must run first
• To run _debit(): tokens must exist on the spoke
• To get tokens on the spoke: _credit() must succeed — which it cannot

The code also gates mint() with onlyHubChain, so the spoke chain cannot acquire tokens via local minting either. Every spoke deployment is completely non-functional.

Why the Protocol Deploys This on Spoke Chains

I looked for a spoke-specific OFT variant that might avoid the _credit override. There is none. OverlayerWrapFactory.deployOverlayerWrap() deploys the same OverlayerWrap contract regardless of chain. The constructor takes a hubChainId parameter that only gates mint() and redeem(), not _credit() or _debit(). hardhat.config.ts configures Arbitrum Sepolia and Optimism Sepolia networks. Deployment scripts configure LayerZero peers for each spoke. The protocol explicitly enables cross-chain messaging to spoke chains via the same contract code that contains the underflow.

LayerZero V2 Message Lifecycle — Why Retry Does Not Save Tokens

LayerZero V2 does not consume failed messages. When _credit() reverts, EndpointV2.lzReceive() reverts atomically -- including _clearPayload(). The payload hash is restored and the message stays in "verified but unexecutable" state. Retrying calls _credit() again on the same spoke where totalBridgedOut is still 0. Same underflow, same Panic(0x11), every time.

The OApp owner can call clear(), skip(), or nilify() to unstick the message queue. None of these mint the missing tokens. They only remove the stuck payload record.

The hub burn is final. The spoke credit never executes. Tokens exist nowhere after the bridge.

---

Impact

Direct Impacts (Unconditional)

Permanent fund loss. When a user calls send() on the hub chain, _debit() burns their tokens. That hub transaction is final. The corresponding _credit() on the spoke reverts deterministically. The user's tokens are destroyed on the hub and never created anywhere. 100% loss for every affected bridge user. This is CWE-191 (Integer Underflow) with direct financial consequence.

Permanent collateral lockup at two levels. When users originally mint OverlayerWrap, they deposit USDC which flows into Aave via AaveHandler. After a failed bridge: totalSupply decreases (tokens burned), totalBridgedOut increases by the same amount, so owTotalSupp = totalSupply + totalBridgedOut stays constant. AaveHandler.supply() at lines 240–241 uses this owTotalSupp as the effective supply cap. The Aave collateral backing the destroyed tokens stays locked — the protocol treats phantom tokens as real.

This lockup operates at two independent levels:

• AaveHandler level: tracks phantom supply, does not release the corresponding Aave position via normal redemption
• OverlayerWrap contract level: after all real users redeem, collateral for phantom supply remains in the contract. rescueNative() at lines 137–148 handles only ETH. There is no ERC20 rescue function for USDC. The collateral is permanently trapped.

Irreversible accounting corruption. totalBridgedOut has no setter. The only functions that modify it are _debit() (increment) and _credit() (decrement, which always reverts on spoke chains). After failed bridges, totalBridgedOut grows monotonically with no correction path. No proxy, no UUPS, no upgrade mechanism exists in any of these contracts. The code cannot be patched.

Corrupted end-state. After all real token holders redeem, totalSupply reaches 0 but totalBridgedOut remains positive. External integrations reading the public totalBridgedOut() getter see phantom cross-chain supply indefinitely. Collateral corresponding to the phantom supply sits in the contract with no claimant.

Derivative Impacts (Conditional)

Protocol-wide staking freeze. This requires maxMintPerBlock to be set to a finite production value (not type(uint256).max as used in tests). If phantom-locked collateral accumulates enough Aave yield between compound() calls to exceed maxMintPerBlock, then compound() reverts. Every function in StakedOverlayerWrap — deposit(), mint(), withdraw(), redeem() (lines 34–75) — calls _compound() first. A compound revert freezes all four operations simultaneously, locking every staker out.

Yield on locked collateral. Real collateral in Aave generates yield regardless of whether the overlying tokens exist. AaveHandler.compound() at lines 171-203 distributes 80% of yield to stakers and 20% to the dispatcher. After failed bridges, the protocol earns yield from collateral that backs destroyed tokens. The bridge victims who lost their funds receive none of this yield.

---

Deliberate Exploitation

send() in OFTCore.sol at line 175 is external payable virtual with zero access controls. Any token holder can call it. The cost per call is the token value (burned) plus LayerZero gas (~$2-5). The minimum bridgeable amount is constrained by decimalConversionRate, not by any meaningful floor -- dust-level amounts work. Each call permanently corrupts hub accounting by the bridged amount.

---

Preemptive Defenses

"Admin can fix it via adminWithdraw()"

adminWithdraw() at AaveHandler.sol:142 can physically move aCollateral tokens back to the OverlayerWrap contract. The admin can move the USDC -- I am not claiming the collateral is physically unreachable. But this is an off-path operational recovery, not protocol-level prevention of the loss. The bridge transaction itself causes deterministic, immediate, 100% fund loss for the user. adminWithdraw() does not restore the burned tokens (those are gone from every chain), does not touch totalBridgedOut (no function in the codebase does), and there is no per-user refund mechanism to route recovered collateral to the specific user who lost funds. The accounting corruption persists regardless of admin action -- any subsequent supply() call re-inflates totalSuppliedCollateral using the still-corrupted counter.

"The current testnet deployment doesn't have this code — it's a future deployment issue"

The current testnet deployment predates the totalBridgedOut feature. That is consistent with this being a code audit contest. The in-scope target is the submitted code, not prior deployments. The "currently deployed" language in HackenProof's rules exists to filter out speculation about future features outside the audit scope — not to ignore critical vulnerabilities in the code submitted for security review. The protocol submitted this exact code for audit because they intend to deploy it. The totalBridgedOut feature was added intentionally for cross-chain accounting. Dismissing a critical vulnerability in code submitted for security review defeats the audit's purpose. And critically: the bug requires zero special configuration. Any spoke chain deployment of this code produces the same underflow. The deployment IS the audit target.

"Maybe maxMintPerBlock is set to type(uint256).max"

The compound freeze is explicitly conditional throughout this report. The unconditional impacts — permanent fund loss, permanent accounting corruption, permanent collateral lockup at two levels, complete spoke chain DoS — stand alone as CRITICAL regardless of any maxMintPerBlock setting. The freeze is a severity amplifier, not the core finding.

Steps to Reproduce

cd ~/wirework-jobs/bounty-overlayer-contracts

# Base finding: spoke chain fully bricked (3 tests)
npx hardhat test test/poc-credit-underflow.ts --config hardhat.config.poc.ts

# Escalation angles: TVL divergence, zombie state, collateral lockup (8 tests)
npx hardhat test test/poc-missed-impacts.ts --config hardhat.config.poc.ts

Expected output for poc-credit-underflow.ts:

  PoC: totalBridgedOut underflow on spoke chain _credit
    ✔ Should revert on first _credit (spoke chain receives bridged tokens) due to totalBridgedOut underflow
    ✔ Should confirm mint() is blocked on spoke chain (onlyHubChain)
    ✔ Should confirm spoke chain is fully bricked: cannot receive tokens and cannot mint

  3 passing (459ms)

Expected output for poc-missed-impacts.ts:

  PoC: Missed Impact Angles -- Phantom Supply Downstream Effects
    ANGLE 1: TVL / Supply Reporting Divergence
      ✔ totalBridgedOut() is publicly readable and inflated after phantom bridge
      ✔ owTotalSupp in AaveHandler.supply() stays inflated -- totalSuppliedCollateral tracks phantom supply
      ✔ Multiple failed bridges amplify the divergence -- totalBridgedOut grows unbounded
    ANGLE 2: Redemption Edge Cases Under Phantom Inflation
      ✔ After ALL real users redeem, totalBridgedOut remains positive -- protocol in zombie state
      ✔ Redeem flow itself is NOT distorted -- _withdrawFromProtocol uses local balance, not owTotalSupp
      ✔ But collateral backing the phantom supply is LOCKED -- protocol holds excess collateral that nobody can claim
    ANGLE 3: Rate-Limit Consumption from Phantom Yield via maxMintPerBlock
      ✔ Demonstrates that compound() and user mints share the same belowMaxMintPerBlock gate
      ✔ Quantification: phantom yield per block is negligible at normal APY

  8 passing (524ms)

---

Proof of Concept

The test environment uses MockEndpointV2 to simulate LayerZero message delivery without mainnet forking. The spoke chain scenario is produced by deploying OverlayerWrap with hubChainId=1 on Hardhat network (chainId 31337). Since block.chainid != hubChainId, the spoke chain condition is active.

test/poc-credit-underflow.ts — 3 tests:

• Test 1 proves _credit() reverts with Panic(0x11) when totalBridgedOut == 0. This mirrors exactly what happens when LayerZero delivers a bridge message to a spoke chain deployment.
• Test 2 proves mint() reverts on spoke chain (onlyHubChain modifier). Both token-acquisition paths are blocked.
• Test 3 confirms the circular deadlock is unresolvable — no sequence of valid function calls allows a spoke chain to accumulate positive totalBridgedOut before receiving its first _credit().

test/poc-missed-impacts.ts — 8 tests:

• ANGLE 1 (3 tests): Phantom totalBridgedOut is publicly readable and inflates after failed bridges. At 45% phantom in the test scenario, the reported effective supply is nearly 2x real circulating supply. Amplifies linearly with each failed bridge.
• ANGLE 2 (3 tests): After all real users redeem, totalBridgedOut remains positive (zombie state). Individual redemptions work correctly (_withdrawFromProtocol uses local balance, not owTotalSupp). But 5,000 USDC remains locked in the contract after legitimate redemptions — no extraction path exists.
• ANGLE 3 (2 tests): compound() and user mints share the same belowMaxMintPerBlock gate. Phantom yield at realistic Aave APY consumes 0.00003% of a typical 50,000 OW/block cap — mechanically real but practically negligible.

---

Remediation

The fix is one function guard. totalBridgedOut tracking is only meaningful on the hub chain, where it feeds into AaveHandler.supply() for collateral accounting. On spoke chains, there is no AaveHandler interaction.

Option A — Hub-chain guard on _credit() (recommended):

function _credit(
    address to_,
    uint256 amountLD_,
    uint32 srcEid_
) internal virtual override returns (uint256 amountReceivedLD) {
    amountReceivedLD = super._credit(to_, amountLD_, srcEid_);
    if (block.chainid == hubChainId) {
        totalBridgedOut -= amountReceivedLD;
    }
}

This is consistent with the existing onlyHubChain pattern already applied to mint() and redeem(). One additional guard closes the gap.

Option B — Symmetric guards on both _credit() and _debit():

For full correctness in both bridge directions:

function _debit(
    address from_,
    uint256 amountLD_,
    uint256 minAmountLD_,
    uint32 dstEid_
) internal virtual override returns (uint256 amountSentLD, uint256 amountReceivedLD) {
    (amountSentLD, amountReceivedLD) = super._debit(from_, amountLD_, minAmountLD_, dstEid_);
    if (block.chainid == hubChainId) {
        totalBridgedOut += amountSentLD;
    }
}

Option C — Checked subtraction with a descriptive revert (minimum viable fix):

require(totalBridgedOut >= amountReceivedLD, "OverlayerWrap: spoke credit underflow");
totalBridgedOut -= amountReceivedLD;

This surfaces the bug clearly but does not fix the spoke chain deadlock. Option A is the correct fix.

---

Financial Impact Quantification

• A single bridge attempt of any amount causes 100% permanent loss of the bridged tokens for that user
• The HackenProof 2% TVL threshold is met by any user bridging a meaningful balance — no special conditions required
• For the 1% of user deposit criterion: a user bridging their full balance loses 100% of it
• Collateral is locked at two independent levels (OverlayerWrap contract + AaveHandler/Aave pool) with no per-user recovery path
• Grief attack economics: ~$5 per call in LZ gas for permanent protocol-wide accounting corruption, regardless of token amount bridged