Ethereum Credit Guild - mahdikarimi's results

A trust minimized pooled lending protocol.

General Information

Platform: Code4rena

Start Date: 11/12/2023

Pot Size: $90,500 USDC

Total HM: 29

Participants: 127

Period: 17 days

Judge: TrungOre

Total Solo HM: 4

Id: 310

League: ETH

Ethereum Credit Guild

Findings Distribution

Researcher Performance

Rank: 97/127

Findings: 1

Award: $35.78

🌟 Selected for report: 0

🚀 Solo Findings: 0

Findings Information

Awards

35.7813 USDC - $35.78

Labels

bug
2 (Med Risk)
satisfactory
sufficient quality report
duplicate-966

External Links

Lines of code

https://github.com/code-423n4/2023-12-ethereumcreditguild/blob/2376d9af792584e3d15ec9c32578daa33bb56b43/src/tokens/ERC20RebaseDistributor.sol#L364-L374

Vulnerability details

Summary

distribute credit tokens extends the distribution period, this leads to delay distribution of unminted rebase rewards, which is not preferred and can harm some users.

Impact

improper calculation of rebase rewards

Proof of Concept

function testExtendDistributionPeriod() public { // initial state: 2 addresses rebasing, both of them have 100 tokens vm.prank(alice); token.enterRebase(); vm.prank(bobby); token.enterRebase(); token.mint(alice, 100); token.mint(bobby, 100); // distribute 120 profits and then jump to targetTimestamp( end of the distribution period ) token.mint(address(this), 120); token.approve(address(token), 120); token.distribute(120); // t1 = first distribution time uint256 t1 = block.timestamp; // t2 = middle of t1 and end of distribution period , where we perform second distribution uint256 t2 = block.timestamp + token.DISTRIBUTION_PERIOD()/2; // t3 = end of the distribution period (first distribution) uint256 t3 = block.timestamp + token.DISTRIBUTION_PERIOD(); vm.warp(t3); // as we expected after the distribution period at t3, each rebasing address has 160 tokens // in this scenario no one calls distribute from last distribution // scenario 1 : balance in t3 = 160 assertEq(token.balanceOf(alice), 160); assertEq(token.balanceOf(bobby), 160); // now consider a scenario where a user perform distribute before end of the distribution period // now we go back sometime ago to t2 (in the middle, between start and end of the distribution period) // in this scenario someone distributes 12 token at this time vm.warp(t2); token.mint(address(this), 12); token.approve(address(token), 12); token.distribute(12); // now we go forward to t3 // as we see every address has 148 tokens, unlike the first scenario // If we don't perform distribution at t2 // scenario 2 : balance = 148 // this clearly demonstrates that extending distribution period delays token distribution which is not preferred since some users may exit rebase early and they don't get all the distributed rewards in their holding time . vm.warp(block.timestamp + token.DISTRIBUTION_PERIOD()/2); assertEq(token.balanceOf(alice), 148); assertEq(token.balanceOf(bobby), 148); })

Tools Used

Manual Review

Consider using a distribution rate for calculating rebase rewards, and adjust rate based on the distribution amount in different periods.

Assessed type

Other

#0 - c4-pre-sort

2024-01-03T16:51:21Z

0xSorryNotSorry marked the issue as sufficient quality report

#1 - c4-pre-sort

2024-01-03T16:51:38Z

0xSorryNotSorry marked the issue as duplicate of #1100

#2 - c4-judge

2024-01-29T22:05:37Z

Trumpero marked the issue as satisfactory

AuditHub

A portfolio for auditors, a security profile for protocols, a hub for web3 security.

Built bymalatrax © 2024

Auditors

Browse

Contests

Browse

Get in touch

ContactTwitter