Aura Finance contest - 0xsomeone's results

Providing optimal incentives for VotingEscrow systems.

General Information

Platform: Code4rena

Start Date: 11/05/2022

Pot Size: $150,000 USDC

Total HM: 23

Participants: 93

Period: 14 days

Judge: LSDan

Total Solo HM: 18

Id: 123

League: ETH

Aura Finance

Findings Distribution

Researcher Performance

Rank: 13/93

Findings: 1

Award: $5,188.76

🌟 Selected for report: 1

πŸš€ Solo Findings: 1

Findings Information

🌟 Selected for report: 0xsomeone

Labels

bug
2 (Med Risk)
disagree with severity
sponsor disputed

Awards

5188.7624 USDC - $5,188.76

External Links

Lines of code

https://github.com/code-423n4/2022-05-aura/blob/main/contracts/AuraLocker.sol#L594-L609 https://github.com/code-423n4/2022-05-aura/blob/main/contracts/AuraLocker.sol#L611-L618

Vulnerability details

ALR-02H: Improperly Skewed Governance Mechanism

FileLinesType
AuraLocker.solL594-L609, L611-L618Governance Susceptibility

Description

The balance checkpointing system exposed by the contract for governance purposes is flawed as it does not maintain voting balances properly. In detail, the total supply of votes is tracked as the sum of all locked balances, however, the total voting power of an individual only tracks delegated balances. As a result, governance percentage thresholds will be significantly affected and potentially unmet.

Impact

The governance module may be unusable due to the significant discrepancy between "circulating" voting power supply and the actual voting power of each individual summed up.

Solution (Recommended Mitigation Steps)

We advise the total voting supply to properly track the delegated balances only as otherwise, any system relying on proportionate checkpointed balances will fail to function properly.

PoC

Issue is deducible by inspecting the relevant lines referenced in the issue and making note of the calculations within the getPastVotes individual voting power function as well as the getPastTotalSupply cumulative voting power function.

Tools

Manual inspection of the codebase.

#0 - 0xMaharishi

2022-05-27T15:06:25Z

This is intended behaviour. There is no incentive for users not to delegate their votes. And even if there were, not delegating is the equivalent to having voting power but not voting. Therefore this is not a relevant issue

#1 - dmvt

2022-06-20T14:56:48Z

I'm going to leave this one in play and downgrade the severity. The warden's report is accurate, however, if the required percentages of voting cannot be met, the DAO would simply have to go on a campaign to get people to delegate their votes. This would be annoying but not critically destructive. That said, medium severity makes sense because a bad actor could potentially gather voting power and intentionally disrupt things by not delegating it. I'd recommend implementing the fix suggested by the warden.

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