Neverland – Security Review of lending protocol

Neverland engaged Composable Security for a focused smart contract security review to harden their protocol before their deployment on Monad.

Basic Information

Project Type: Lending protocol with proprietary vote-escrowed tokenomics.

Service: Smart contract security review.

Results: Through our collaboration, 23 issues, including 1 critical and 3 high vulnerabilities, were successfully identified and resolved.

About the Client

Neverland Money is a lending protocol powered by Monad. It focuses on combining AAVE V3’s lending functionalities with with proprietary vote-escrowed tokenomics, introducing features such as governance via veDUST, along with unique rewards distribution, emission mechanisms, advanced automated yield strategies, and self-repaying loans.

Visit website: https://neverland.money/

About the Service Scope

We have been entrusted with an important first audit of the core functionality, and as always, we intend to do everything in our power to secure our client. We are committed to working closely with them to ensure that the audit not only detects vulnerabilities but also enhances overall security.

The subjects of the test were selected files from the Neverland repository:

GitHub repository: https://github.com/Neverland-Money/neverland-contracts.

CommitID:6c19a5e023c68fb5bdb95389a316e2a6f943a0c6

The audit’s primary focus is on custom-developed features, excluding the forked code from AAVE and Velodrome. Below is an overview of its key components:

• DustLockTransferStrategy: This contract defines a strategy for transferring DUST rewards to users. It allows users to create new veDUST locks, add to existing ones, or perform an early withdrawal with a penalty, managing the distribution from a DUST vault.
• DustRewardsController: This contract manages the distribution of rewards to users based on their staked assets. It is a modified version of Aave’s RewardsController that integrates with a custom IDustTransferStrategy to handle specialized reward transfers, including lock times and token IDs.
• DustTransferStrategyBase: This is an abstract contract that provides a base implementation for DUST reward transfer strategies. It defines the core interface and access control, requiring inheriting contracts to implement the specific performTransfer logic.
• BalanceLogicLibrary: This library contains functions for calculating user and global voting power (veDUST balance) at any given point in time. It uses historical checkpoints and binary search to efficiently retrieve past balances for both individual NFT-based locks and the total supply.
• EpochTimeLibrary: This library provides utility functions for handling epoch-based time calculations, where an epoch is defined as a week. It includes functions to determine the start and end of an epoch, as well as the start and end of the voting window within an epoch.
• SafeCastLibrary: This library offers safe type casting functions to convert between uint256 and int128. It prevents overflow and underflow errors during conversions, which is crucial for financial calculations within smart contracts.
• RevenueReward: This contract is responsible for distributing revenue in the form of various ERC20 tokens to veDUST holders. It allows a designated distributor to deposit rewards, which are then claimable by users based on their proportional veDUST balance over time.
• Dust: This contract implements the DUST token, which is the native ERC20 token of the protocol. It is an upgradeable and pausable token with ownership control, including standard ERC20 functionalities and permit support for gasless approvals.
• DustLock: This contract allows users to lock DUST tokens to receive veDUST in the form of an NFT, which represents their voting power in the protocol. It manages the creation, merging, splitting, and withdrawal of these token locks, with voting power decaying over time.

Initial challenges and constraints

• Time‑boxed two‑week review followed by an iterative retest window.
• Numerous code changes between audit and retest increased the chance of residual issues, requiring careful, later‑commit verification.
• Focus on custom business logic rather than mature, forked components.

Objectives defined at the outset

• Model realistic threats and prioritize tests around user funds, rewards, and protocol revenue.
• Identify vulnerabilities in custom tokenomics and reward flows.
• Provide actionable recommendations and long‑term hardening guidance.

Identified threats

As before every audit, thorough threat modeling is performed. The results are made available to the client for joint analysis.

Key assets that require protection:

• Users’ funds.
• Rewards.
• Protocol revenue.
• Voting power.

Threats and potential attackers goals:

• Theft of user’s funds.
• Influencing/increasing voting power.
• Unfair reward distribution.
• Permanent lock of all revenue rewards.
• Lock users’ funds in the contract.
• Block the contract, so that others cannot use it.

Potential scenarios to achieve the indicated attacker’s goals:

• Influence or bypass the business logic of the system.
• Take advantage of arithmetic errors.
• Privilege escalation through incorrect access control to functions or poorly written modifiers.
• Existence of known vulnerabilities (e.g., front-running, re-entrancy).
• Design issues.
• Excessive power, too much in relation to the declared one.
• Poor security against taking over the managing account.
• Private key compromise, rug-pull.
• Withdrawal of more funds than expected.

More can be found in the report.

Security Review results

A comprehensive security review outlined 26 issues (1 critical, 3 high, 3 medium, 8 low) and eleven additional security recommendations.

Key findings:

• [Critical] Early withdrawal penalty fee bypass – Users could withdraw their entire locked token balance without paying any penalty fees, causing substantial revenue loss to the protocol treasury and completely undermining the penalty mechanism.
• [High] Invalid update of voting power – Inaccurate update of the current total voting power (bias) and the adjustments to slopeChanges.
• [High] Integer division truncation in rewards – Small veNFT holders systematically lose earned rewards due to integer division truncation, creating unfair distribution favoring large holders.
• [High] Permanent reward loss on veNFT burn/transfer – Users permanently lose all unclaimed rewards when their veNFTs are burned, leading to protocol fund leakage and user financial loss.
• [Medium] Self-repaying loan reward receiver persists across veNFT transfers – New veNFT owners unknowingly lose rewards to previous owners until they discover and fix the configuration, causing financial loss and poor user experience.
• [Medium] Missing permanent‑lock check in split – Users could fragment permanent locks to manipulate voting power distribution and undermine the protocol’s permanent commitment mechanism.
• [Medium] Inability to delegate claim permissions by users – Users could not authorize third parties to claim rewards on their behalf, requiring administrative intervention for all claimer delegations and reducing protocol flexibility.

The team started improving the codebase immediately after the audit and we verified during the retest that most important vulnerabilities have been completely removed. One issue with low impact on risk was acknowledged.

Security enhancements:

• The team updated the early withdrawal penalty calculation to use _balanceOfNFTAt(tokenId, block.timestamp) instead of the flash-protected balanceOfNFT() function, removing the bypass vectors that allowed users to avoid penalties through same-block NFT transfers.
• The team fixed the voting power recalculation issue by re-evaluating oldLocked after calling unlockPermanent() in the earlyWithdraw function.
• The team came up with a new mechanism to scale the remainder relative to the supply of the epoch in which it was generated, and accumulate it in scaled form. Once enough is collected, it converts into a full unit. This way, reward distribution remains accurate even as supply fluctuates. They also ensured lastEarnTime always updates on claims so that old epochs cannot be counted twice. All relevant functions (preview, claim, split, merge, transfer, burn) correctly propagate or settle fractional rewards.
• The team integrated DustLock with RevenueReward so that rewards are automatically claimed before any veNFT burn, transfer, or removal operation. When _notifyAfterTokenBurned() or _notifyAfterTokenTransferred() are called, RevenueReward automatically claims all pending rewards via _claimRewardsTo() and sends them to the previous owner, preventing permanent reward loss.
• The team was provided with materials to help increase operational security based on our own materials and those developed by Security Alliance.
• The engagement included Q&A sessions to clarify intent and assumptions, collaborative reproduction of edge cases, and retest verification notes to support the team’s internal documentation and test coverage.

Client rating