Platform: Code4rena
Start Date: 13/02/2024
Pot Size: $24,500 USDC
Total HM: 5
Participants: 84
Period: 6 days
Judge: 0xA5DF
Id: 331
League: ETH
Rank: 60/84
Findings: 1
Award: $25.73
🌟 Selected for report: 0
🚀 Solo Findings: 0
🌟 Selected for report: nuthan2x
Also found by: 0x0bserver, AM, CaeraDenoir, DanielArmstrong, JrNet, Kirkeelee, KmanOfficial, Krace, Limbooo, Meera, SovaSlava, SpicyMeatball, TheSavageTeddy, agadzhalov, aslanbek, atoko, csanuragjain, d3e4, imare, jesjupyter, juancito, kartik_giri_47538, kutugu, max10afternoon, offside0011, pkqs90, turvy_fuzz, xchen1130, zhaojohnson, ziyou-
25.7286 USDC - $25.73
https://github.com/code-423n4/2024-02-althea-liquid-infrastructure/blob/main/liquid-infrastructure/contracts/LiquidInfrastructureERC20.sol#L198-L237 https://github.com/code-423n4/2024-02-althea-liquid-infrastructure/blob/main/liquid-infrastructure/contracts/LiquidInfrastructureERC20.sol#L441-L445
During a distribution, whenever the distribute()
is called the distributableERC20s
array is accessed and the addresses are read from here in order to perform the required distributions per approved holder. If the distributableERC20s
array values were to change at any time during the current distribution, the distribute()
function may perform inaccurate distributions upon the newly assigned distributableERC20s
array, unexpected transfers of various tokens or even result in failed transfers bricking the distribute()
function.
Initially distributableERC20s
has only 3 ERC20s to distribute amongst. For example USDT, USDC, ETH.
distribute(50) is called, and distribution commences (lock in place) - 100 eligible wallets. Transaction done in batches of 50.
First 50 with distribute() is called.
Admin/owner changes distributableERC20s
using setDistributableERC20s()
to TUSD, ETH, USDC.
distribute(100)
is called again for the last 50 wallets - either transfers the incorrect distributions for the wrong ERC20 tokens to those wallets or fails due to insufficient balance within the contract.
Manual Code Review, VS Code
In order to mitigate this risk, there is two suggestions:
Upon starting a new distribution round/lock, store a copy of the distributionERC20s array valid for the current distribution which can be removed from storage after it has ended. This copy would be referenced to throughout the current distribution.
Only allow the distributableERC20s array to be modified only when there is no distribution currently taking place (when !LockedForDistribution).
Token-Transfer
#0 - c4-pre-sort
2024-02-22T06:06:44Z
0xRobocop marked the issue as duplicate of #260
#1 - c4-judge
2024-03-04T15:33:06Z
0xA5DF marked the issue as satisfactory
#2 - c4-judge
2024-03-08T15:13:03Z
0xA5DF changed the severity to 3 (High Risk)
#3 - c4-judge
2024-03-08T15:26:19Z
0xA5DF changed the severity to 2 (Med Risk)