Vesu Lending Protocol Critical Liquidation Logic Rounding Error

Notice: This page is a freshly imported case study from an original repository. While the original content had a similar format, some sections may not have been fully completed. Please help fill in any empty sections or any missing information you can find. If you are new here, please read General Tutorial on Wikis or Anatomy of a Case Study for help getting started.

Notice: This page contains sources which are not attributed to any text. The unattributed sources follow the initial description. Please assist by visiting each source, reviewing the content, and placing that reference next to any text it can be used to support. Feel free to add any information that you come across which isn't present already. Sources which don't contain any relevant information can be removed. Broken links can be replaced with versions from the Internet Archive. See General Tutorial on Wikis, Anatomy of a Case Study, and/or Citing Your Sources Guide for additional information. Thanks for your help!

Vesu Protocol Logo/Homepage

Vesu is a fully permissionless lending protocol on Starknet that allows anyone to lend, borrow, and create custom lending pools with advanced features like lending hooks and ERC-4626 vTokens. In May 2025, a critical yet unused feature—receive_as_shares—was found to contain a rounding error in its liquidation logic, potentially allowing attackers to extract unearned value by manipulating share calculations. The vulnerability required a complex setup to exploit, but was discovered early and responsibly disclosed by a whitehat hacker. Within five days, the Vesu team removed the vulnerable code, secured the protocol through a full migration, and implemented safeguards like contract whitelisting and multisig upgrades—all without any user funds being lost.

About Vesu Lending Protocol

Vesu Lending Protocol is a fully open, permissionless lending system built on Starknet, designed to function as public infrastructure without a governance token or centralized control. It enables anyone to supply assets, borrow against them, or even create new lending pools, making it highly flexible and inclusive. Participants include lenders, borrowers, liquidators, and pool admins—all accessible to any Starknet account without restrictions.

Vesu operates on an overcollateralized lending model, where borrowers must deposit more in collateral than they borrow. If a borrower’s loan-to-value (LTV) ratio exceeds the set limit, their position becomes eligible for liquidation, typically involving discounted sale of collateral to repay the debt. Vesu’s lending pools are isolated by design—users share risks only within the pool they join, and anyone can create new pools to support new markets or strategies.

A standout feature of Vesu is its modular design and lending hooks—programmable, third-party extensions that customize how supply, borrow, or liquidation actions are handled. This enables developers to craft unique lending experiences tailored to specific needs. The protocol also issues vTokens (ERC-4626 compatible) representing user deposits and accrued interest, and relies on flexible oracle integrations (such as Pragma) for pricing collateral and loans.

Each pool defines its own risk parameters, interest rate models, and LTV thresholds, allowing for highly differentiated markets. Supply and borrow rates dynamically adjust based on demand and configuration, and APYs may also include additional rewards. Overall, Vesu offers a composable, secure, and user-centric framework for decentralized lending on Starknet.

The Reality

Vesu's lending protocol had a flawed rounding convention in its liquidation logic, specifically when the receive_as_shares flag was activated. This flaw could have allowed incorrect accounting of value during liquidations, potentially leading to the unintended creation of excess value in user positions.

What Happened

A critical liquidation bug in Vesu's lending protocol was responsibly disclosed before exploitation.

Key Event Timeline - Vesu Lending Protocol Critical Liquidation Logic Rounding Error

Date	Event	Description
May 22nd, 2025 7:54:00 PM MDT	Vulnerability First Reported	The vulnerability was first reported to Immunefi.
May 22nd, 2025 11:19:00 PM MDT	Report Escalated To Vesu	Immunefi escalated the report to the Vesu team.
May 23rd, 2025 2:48:00 AM MDT	Vesu Involves Argent Team	Vesu team involved Argent’s security team to assist with technical assessment.
May 23rd, 2025 6:28:00 AM MDT	Vesu And Argent Analysis	Vesu & Argent team completed initial analysis and started to engage with whitehat on Immunefi.
May 23rd, 2025 6:44:00 AM MDT	ChainSecurity Now Engaged	ChainSecurity engaged for technical assessment and assistance with remediation plan.
May 24th, 2025 9:00:00 AM MDT	Remediation Plan Developed	Remediation plan developed and reviewed in collaboration with ChainSecurity. Done at EOD in UTC + 2 assumed 5 PM.
May 27th, 2025 9:00:00 AM MDT	Implementation And Testing	Fix and Vesu migration contracts and script implemented and tested. Lending pool curators notified. Done at EOD in UTC + 2 assumed 5 PM.
May 28th, 2025 5:00:00 AM MDT	Migration Sequence Initiated	Migration initiated in
May 28th, 2025 2:30:00 PM MDT	Smart Contracts Migrated	Migration of Vesu contracts, lending pools, backend and frontend completed and verified.
May 28th, 2025 2:40:00 PM MDT	Migration Complete Post	Vesu posts that it has successfully completed a planned protocol migration and confirms that all user funds are safe. No action is required for Borrow and Multiply users, while Earn users simply need to tap “Migrate” to upgrade to the new vTokens. Users who haven't migrated yet will still continue earning interest and DeFi Spring rewards. The migration automatically completes with the user's next interaction with Vesu, and support is available via Discord or their blog for further assistance.
June 4th, 2025 2:02:00 AM MDT	now	vesurevealed
June 4th, 2025 2:51:00 AM MDT	Immunefi Glad For Praise	Immunefi graciously accepts the praise.
June 4th, 2025 3:13:00 AM MDT	Alexxander Glad For Praise	Alexxander, the white hat, humbly accepts the praise.
June 5th, 2025 10:07:00 AM MDT	Story Published On Rekt News	The incident is published in a Rekt News article as a rare positive DeFi story where the protocol Vesu discovered and patched a critical rounding error bug before it was exploited. A whitehat hacker named Alex responsibly reported the issue through Immunefi, prompting Vesu to act swiftly—engaging top security teams, deploying fixes, and migrating the protocol within five days without any loss of funds. The article highlights Vesu’s proactive security process, contrasting it with the usual chaos in DeFi, and praises the quiet competence that prevented what could have been a multi-million dollar exploit.

Technical Details

The Vesu rounding convention vulnerability was a critical flaw in the liquidation logic of the Singleton::liquidate_position function, specifically when the receive_as_shares flag was activated. This flag allowed liquidators to receive repayment in pool shares rather than the underlying collateral assets. While the feature was never used in practice, its inclusion introduced a subtle but severe rounding error that could be exploited to mint more value than contributed—essentially printing free money under certain conditions.

The vulnerability’s exploitation path required a multi-step attack: a malicious actor could deploy a custom lending pool extension contract, spin up a new pool, and use flashloans to manipulate the liquidation logic. By exploiting the flawed rounding convention within the receive_as_shares path, the attacker could have drained funds by liquidating positions in a way that improperly calculated the exchange rate between shares and collateral.

Total Amount Lost

Vesu's vulnerability was discovered and responsibly disclosed before it could be exploited.

No funds were lost.

Immediate Reactions

Recognizing the complexity and risk, the Vesu team acted quickly after the bug was responsibly disclosed on May 23, 2025, via Immunefi. Within hours of whitehat Alex submitting the vulnerability through Immunefi, the report was escalated to Vesu’s team. That same afternoon, Vesu engaged security experts from Argent and ChainSecurity to assess the issue. Rather than panic, the team quickly formulated a plan, initiated a full protocol migration, and began implementing fixes—all while maintaining user fund safety and system functionality.

Ultimate Outcome

Within five days, they developed and tested a full protocol migration and issued a fix. The fix included removing the receive_as_shares feature entirely, as it wasn’t essential to core protocol functionality. Additionally, they whitelisted pool extension contracts, restricting who could deploy custom extensions and thereby minimizing a key attack surface.

Total Amount Recovered

No funds were lost.

There do not appear to have been any funds recovered in this case.

Ongoing Developments

To ensure long-term safety, the updated protocol contracts were made upgradeable, managed by a 3-of-5 multisig with external signers, allowing secure and flexible governance in case future upgrades are necessary. The incident reinforced the importance of treating security as a continuous process—not just audits, but also bug bounties, partnerships with security firms like Argent and ChainSecurity, and responsive, transparent handling of issues.

Individual Prevention Policies

No specific policies for individual prevention have yet been identified in this case.

For the full list of how to protect your funds as an individual, check our Prevention Policies for Individuals guide.

Platform Prevention Policies

Policies for platforms to take to prevent this situation have not yet been selected in this case.

For the full list of how to protect your funds as a financial service, check our Prevention Policies for Platforms guide.

Regulatory Prevention Policies

No specific regulatory policies have yet been identified in this case.

For the full list of regulatory policies that can prevent loss, check our Prevention Policies for Regulators guide.