Integral Logo
  1. News

Post-Mortem Report: Precision Error for Actions in Integral SIZE


A potential vulnerability was identified in the Integral protocol via our Immunefi bounty program. The flaw involved an exploit in the deposit function which allowed an attacker to initialize the total shares of a LP position to a small integer and then directly transfer funds to the contract. This in turn could lead to a rounding error when a legitimate user attempted to deposit funds, effectively decreasing the user’s share to the amount transferred by the attacker. We did not observe the exploit active in production and we have since deployed a patch and the system is back to running as normal. No user funds were lost.

Key Issue

The core problem was a lack of precision for total shares when an initial deposit was of a relatively small amount. This vulnerability enabled an attacker to attempt to force a victim deposit or enqueued trading shares to round down to nearly zero or have substantial rounding errors that biased the accounting of funds in favor of the attacker.

The attacker could only exploit this vulnerability by front-running a victim’s order and stealing the amount the victim intended to swap or deposit for.

The attack vector was as follows:

  1. Attacker sends 1e-6 USDC (0.000001 USD worth) to the TwapDelay contract and it gets enqueued.
  2. At this point the totalShares in the enqueue system is 1 (integer). This is the minimum integer.
  3. Another user (the victim) sends an order to swap 1,000 USDC (1k USD) for WETH.
  4. The attacker sees the order, and front-runs it by sending an amount an order of magnitude similar to or higher, to the TwapDelay contract. In this example, the attacker would send 1,000 UDSC.
  5. At this point, total share (newShares) in the system are 1 * (1,000e6 + 1,000e6 + 1) / (1,000e6 + 1) = 1. Note that the answer would be 1.99999 without truncation or integer limitation but due to truncation, the newShares would still be 1.

Victim’s Share = newShares – totalShares = 1 – 1 = 0

Hacker’s Share = totalShares – victim’s Shares = 1 – 0 = 1 6. The attacker would end with 2,000 USDC worth of order to swap to WETH if there is no revert. If there is a revert at the pool level, the hacker would receive the refund of 2,000 USDC and the victim would receive 0 USDC refund.

The funds at risk were those currently enqueued in the delay before execution. As a result, the attack was only relevant to future swaps or deposits of user funds. Deposits, sell, and buy and atomic swap orders from users were all at risk during this vulnerability. The funds already within the pool were not under threat.


To address the vulnerability, the Integral team deployed a fix which implemented a minimum precision amount, thus preventing such significant rounding errors. This solution ensures that the total shares can’t be manipulated by small initial deposits and transfers.

As an immediate response upon receipt and confirmation of the Immunefi submission, the system was switched to withdrawal-only mode to prevent any exploitation. The fix was subsequently deployed on both the mainnet and Arbitrum versions.

Timeline of Events

July 10 – Received Immunefi report

July 10 – Confirmed and system set to withdraw only

July 11 – Patch developed and deployed

July 11 – trading and deposits turned back on and system returned to normal

Current Status

The system has now resumed regular operation following the implementation of the fix. The patch’s deployment protects users’ deposits, sell and buy orders from being exploited.

The report serves as a reminder of the critical role of community participation in ensuring the safety of DeFi protocols. The Integral team thanks the Immunefi community for their vigilance and support in identifying and addressing this vulnerability. We reiterate our commitment to providing a secure environment for all users.

The Integral team appreciates all efforts aimed at making DeFi safer and more reliable.