Skip to content

Latest commit

 

History

History
54 lines (38 loc) · 2.77 KB

030.md

File metadata and controls

54 lines (38 loc) · 2.77 KB

Obedient Lava Monkey

Medium

Improper Fee Calculation in executeBackUnbacked May Lead to Loss of Treasury Fees

Summary

A miscalculation in the fee allocation logic in executeBackUnbacked will cause incorrect fee distribution for the protocol treasury as rounding errors in fee.percentMul(protocolFeeBps) can lead to a portion of the fee being lost.

Root Cause

In BridgeLogic.sol, the fee is split into protocol fees and liquidity provider (LP) fees using percentage math:

uint256 feeToProtocol = fee.percentMul(protocolFeeBps); // Calculates protocol's share of the fee
uint256 feeToLP = fee - feeToProtocol; // Remainder allocated to LPs

However, percentMul truncates results due to integer division, leading to rounding errors. This causes the feeToProtocol + feeToLP to be slightly less than the total fee, resulting in a small portion of the fee being lost. percentMul**, defined in Aave’s math libraries, performs multiplication followed by integer division ((a * b) / 10_000), which inherently truncates fractional results. This truncation ensures the sum of feeToProtocol and feeToLP is slightly less than fee due to the discarded remainder.

Internal Pre-conditions

  1. The protocolFeeBps is set to a valid value (e.g., 10_000 BPS = 100%).
  2. executeBackUnbacked is called with a non-zero fee.

External Pre-conditions

  1. The caller interacts with the contract, triggering executeBackUnbacked.
  2. Dependencies (e.g., percentMul) are assumed to be functional but subject to truncation.

Attack Path

  1. A user backs unbacked tokens via executeBackUnbacked with a specified fee.
  2. The protocol calculates feeToProtocol and feeToLP.
  3. Due to rounding in percentMul, the total of these values is slightly less than the original fee.
  4. The difference is effectively "lost" as it’s not allocated to the protocol or LPs.

Impact

The protocol treasury and LPs collectively lose a small fraction of the fees due to rounding errors, leading to potential financial inefficiency over many transactions. While each transaction's impact is minimal, the cumulative effect could result in significant losses.

Mitigation

Adjust the calculation to ensure no fees are lost by assigning the rounding error to the LPs or the protocol.

uint256 feeToProtocol = fee.percentMul(protocolFeeBps);
uint256 feeToLP = fee - feeToProtocol; // Handles remainder implicitly
assert(feeToProtocol + feeToLP == fee); // Ensures all fees are accounted for