An early withdrawal must apply the configured penalty regardless of a same-block veNFT ownership change.
The answer in 30 seconds
Neverland Money engaged Composable Security to review custom tokenomics and reward contracts for its Monad lending protocol. Carlos (Bloqarl) and 0xluk3 performed the two-week assessment as contractors for Composable Security, which owned the client relationship; this was not a direct Zealynx engagement.[1][5]
The pivotal issue was a critical business-logic mismatch inside DustLock. The early-withdrawal path calculated a penalty from balanceOfNFT(), while that view intentionally returned zero after an ownership change in the same block. A transfer followed by earlyWithdraw() could therefore make the configured penalty zero. The August 14, 2025 retest records that the calculation was changed to a non-flash-protected balance path and marks the finding fixed.[1]
This is a technical engagement narrative, not a customer transformation story. Public evidence supports the relationship, mechanism, and recorded remediation, but not a monetary outcome, production deployment at the evidence cutoff, or Neverland's approval of this Zealynx narrative.
The buyer decision: can one balance function serve two security goals?
The review covered Neverland's custom-developed tokenomics, emissions, rewards, and supporting libraries while excluding forked Aave and Velodrome code. DustLock represented locked DUST positions as vote-escrowed NFTs, or veNFTs, whose voting power decayed over time.[1][5] Neverland's own site describes the broader product as a Monad-native, non-custodial lending platform governed through vote-escrow tokenomics.[2]
Composable Security publicly describes smart-contract audits, retesting, and security consultations as its services.[3] For a protocol team designing an early-exit mechanism, the decision is deceptively simple: which state should determine the penalty? The value used must represent the user's economic obligation at withdrawal time. It must not inherit unrelated behavior intended for governance, anti-flash-loan protection, or display logic.
The system invariant was:
An eligible early exit must apply the configured penalty independently of a same-block transfer, delegation, or voting-power guard.
The dangerous assumption: a safe voting-power view is a safe fee input
balanceOfNFT() had flash protection: after the veNFT changed ownership, it returned zero for that block. That behavior can be useful when voting power should not be reused immediately after a transfer. It was unsafe as an input to a withdrawal fee.
The penalty calculation multiplied the configured penalty rate by balanceOfNFT(tokenId). This coupled two different meanings of "balance":
- governance meaning: voting power currently safe to count;
- settlement meaning: the position amount against which an early-exit penalty must be charged.
The first value could intentionally become zero. The second could not.
How the connected failure path worked
The canonical report documents a short cross-function sequence rather than a failure isolated to one line:[1]
- A user owns a veNFT with an active lock.
- The veNFT is transferred in block N.
- The ownership-change guard makes
balanceOfNFT(tokenId)return zero during block N. - The new owner calls
earlyWithdraw(tokenId)in the same block. - The penalty calculation multiplies the configured rate by zero.
- The early withdrawal proceeds without the intended penalty.
Every component behaves according to its local rule. The invariant fails because a governance-oriented guard crosses into economic settlement.
How the review tested the invariant
The investigation treated the penalty as a state-transition property rather than checking only the configured percentage.
1. Identify every input to settlement
The review traced the early-withdrawal amount back to the balance function it consumed. This exposed that the calculation depended on a context-sensitive voting-power view rather than an obligation-specific value.
2. Enumerate state changes that alter the input
Ownership transfer was not merely an NFT operation. It changed the return value used by the withdrawal path. Testing transfer and withdrawal in sequence revealed the discrepancy.
3. Separate protective semantics from accounting semantics
A zero value meant "do not count this voting power in this block," not "the locked position has no value." Distinguishing those meanings made the violated invariant explicit.
4. Retest the exact bypass after remediation
The report records that the team changed the penalty calculation to _balanceOfNFTAt(tokenId, block.timestamp), avoiding the flash-protected balanceOfNFT() path. The August 14 retest says the same-block transfer bypass vectors were removed and marks the finding fixed.[1]
Before, intervention, and verified after-state
| Before the review | Review intervention | Verified after-state |
|---|---|---|
| The fee calculation consumed a voting-power view that returned zero after a same-block transfer | Connected ownership-change behavior to the early-withdrawal settlement path | The retest records use of _balanceOfNFTAt(tokenId, block.timestamp) instead of balanceOfNFT() |
A transfer followed by earlyWithdraw() could reduce the calculated penalty to zero | Reproduced the multi-step state transition and reported it as critical | Composable Security marks NRL-6c19a5e-C01 fixed on August 14, 2025 |
| Governance protection and fee accounting shared one context-sensitive value | Recommended an obligation-specific basis for the calculation | The retest says the documented transfer-based bypass vectors were removed |
The public report also records 14 of 15 vulnerabilities fixed and one low-severity issue acknowledged after the wider retest. Neverland's own public audit repository independently identifies Composable Security as the auditor and says the August 2025 critical and high-risk findings were remediated and verified.[1][4]
Why local tests can miss this class of bug
A unit test that creates a lock and calls earlyWithdraw() from the same owner can confirm the percentage while missing the bypass. The dangerous value appears only after a neighboring state transition changes the semantics of a shared read function.
A stronger test matrix crosses the settlement action with the events that can alter its inputs:
| Transition before exit | What to assert |
|---|---|
| no ownership change | configured penalty is applied |
| transfer in the prior block | configured penalty is applied |
| transfer in the same block | configured penalty is applied |
| self-transfer or approved transfer | transfer form cannot change the obligation |
| permanent-lock state change | accounting uses the updated lock state |
The reusable lesson is not "avoid balanceOfNFT()." It is to prevent a view designed for one security domain from silently becoming the source of truth for another.
A checklist for tokenized lock and vesting systems
Before shipping an early-unlock path, test these questions:
- Economic source of truth: Is the penalty based on locked principal, remaining duration, voting power, or another explicitly defined quantity?
- Context-sensitive reads: Can transfer guards, flash protection, delegation, checkpoints, or block timing force that quantity to zero or stale data?
- Cross-function sequences: Do transfer, merge, split, extend, delegate, and unlock preserve the same fee obligation?
- Actor changes: Can a new owner obtain different settlement terms solely because ownership changed?
- Boundary timing: Do same-block and epoch-boundary actions produce the intended result?
- Fix adjacency: Does correcting the fee path preserve governance accounting and permanent-lock behavior?
- Retest evidence: Does the verification identify the corrected path, commit or version, date, and residual scope?
Impact and evidence limits
The strongest supportable result is the verified control change: the documented same-block transfer sequence no longer supplied the flash-protected zero value to the penalty calculation in the retested code.[1]
No public source establishes the amount of DUST economically exposed, a realized treasury loss, exploitation, funds saved, or loss avoided. The report's illustrative token and dollar figures explain its hypothetical scenario; they are not evidence of actual value at risk and are deliberately omitted here. The report also warns that numerous remediation changes increased residual-risk probability and recommends another audit iteration.[1]
Neverland now publishes a public contract mirror with mainnet addresses, but that mirror was created after the reviewed private repository and does not contain the original or retest commits. It provides current architecture context, not commit-level corroboration of the 2025 fix.[6]
Evidence and attribution
- Client-authored: Neverland's audit repository names Composable Security as auditor for the August 22, 2025 report and records remediation and retest verification.[4]
- Partner-authored canonical record: Composable Security's report identifies Neverland as client, Composable Security as provider, Carlos (Bloqarl) and 0xluk3 as contractors, the initial and retest commits, finding NRL-6c19a5e-C01, and its fixed status.[1]
- Partner-authored narrative: Composable Security describes the scope, decision context, constraints, mechanism, and remediation.[5]
- Current public source mirror: Neverland's tokenomics repository documents the current contract architecture, but not the historical audit commits.[6]
- Zealynx role: contractor auditor under Composable Security; Composable Security owned the Neverland client relationship.
- Evidence cutoff: the finding-specific retest dated August 14, 2025 and report dated August 25, 2025.
- Publication limit: public disclosure of the report does not itself establish Neverland or Composable Security approval for Zealynx to publish this derivative narrative. The page remains unpublished pending written approval.
Reviewing a tokenized lock or early-exit mechanism?
Zealynx can test whether fees, voting power, rewards, and ownership changes preserve the same invariant across complete transaction sequences. Review the smart contract audit service or request a scoped tokenomics review.
Frequently asked questions
What caused the Neverland early-withdrawal penalty bypass?
The fee path used balanceOfNFT(), which intentionally returned zero after a same-block ownership change. A transfer immediately followed by earlyWithdraw() could therefore calculate a zero penalty.[1]
Why was this a system invariant rather than a single-function bug?
The failure required behavior from the NFT transfer path, the ownership-change flash guard, the voting-power view, and early-withdrawal settlement. Each local behavior looked plausible; their composition broke the fee obligation.
How was the issue fixed and verified?
The report says the calculation changed to _balanceOfNFTAt(tokenId, block.timestamp) rather than the flash-protected balanceOfNFT(). Composable Security retested the issue on August 14, 2025 and marked it fixed.[1]
Did Zealynx contract directly with Neverland Money?
No. Neverland engaged Composable Security. Carlos (Bloqarl) contributed as a contractor auditor under Composable Security, which owned the client relationship.[1][5]
Does fixed mean the deployed protocol was guaranteed secure?
No. Fixed describes the finding in the retested scope. It is not a warranty about deployment, later code, or the absence of other vulnerabilities. The report recommended a further audit iteration because remediation involved numerous changes.[1]
Sources
[1] https://raw.githubusercontent.com/ComposableSecurity/.github/main/reports/2025_08_Neverland.pdf — Neverland Money Smart Contract Security Audit [2] https://neverland.money — Neverland Money [3] https://composable-security.com — Composable Security [4] https://github.com/Neverland-Money/security-audits — Neverland Security Audits [5] https://composable-security.com/blog/neverland-security-review-of-lending-protocol — Neverland security review [6] https://github.com/Neverland-Money/neverland-tokenomics — Neverland Tokenomics