Arcade.xyz - 0xastronatey's results

The first of its kind Web3 platform to enable liquid lending markets for NFTs.

General Information

Platform: Code4rena

Start Date: 21/07/2023

Pot Size: $90,500 USDC

Total HM: 8

Participants: 60

Period: 7 days

Judge: 0xean

Total Solo HM: 2

Id: 264

League: ETH

Arcade.xyz

Findings Distribution

Researcher Performance

Rank: 43/60

Findings: 1

Award: $312.74

🌟 Selected for report: 0

🚀 Solo Findings: 0

Findings Information

🌟 Selected for report: ktg

Also found by: 0x3b, 0xastronatey, 0xbranded, 0xmuxyz, 0xnev, BenRai, Viktor_Cortess, caventa, oakcobalt, sces60107

Labels

bug
2 (Med Risk)
downgraded by judge
satisfactory
duplicate-283

Awards

312.7392 USDC - $312.74

External Links

Lines of code

https://github.com/code-423n4/2023-07-arcade/blob/88dcbdedebc506284fcfb3f14d20fc789ce811cf/contracts/NFTBoostVault.sol#L342

Vulnerability details

Impact

there's a potential business logic flaw related to the updating of user voting power when the multiplier of an NFT changes. The multiplier of an NFT can be updated by the manager using the setMultiplier function:

function setMultiplier(uint256 id, uint256 multiplier) external onlyManager { // Set multiplier multipliers[id] = multiplier; // Emit event emit SetMultiplier(id, multiplier); }

the voting power of a user who deposited an NFT is updated when they make a new deposit or withdrawal, or when someone calls the updateVotingPower function:

function updateVotingPower(address user) public { // Get user's current balance and NFT uint256 balance = balances[user]; (uint256 id, uint256 value) = userNFTs[user]; // Calculate user's new voting power votingPower[user] = getVotingPower(user, balance, id, value); }

This vulnerability could result in a user having more or less voting power than they should according to the current multiplier of their deposited NFT. This could potentially influence the outcome of a vote in a way that's not reflective of the current state of deposited tokens and NFTs.

For example, if the manager reduces the multiplier of a certain NFT and doesn't update the voting power of the users who deposited that NFT, those users would have more voting power than they should. This is a more subtle kind of business logic flaw.

To mitigate this vulnerability, the contract could implement a mechanism to automatically update the voting power of all users who have deposited a certain NFT when the multiplier of that NFT changes. This would ensure that the voting power of all users always accurately reflects the current multipliers.

However, this could be expensive in terms of gas costs if there are many users who deposited the same NFT. An alternative mitigation could be to implement a mechanism where the voting power is calculated dynamically when it's accessed, based on the current balance of the user and the current multiplier of their NFT, instead of storing the voting power in a state variable.

Assessed type

Other

#0 - c4-pre-sort

2023-08-01T01:32:56Z

141345 marked the issue as duplicate of #203

#1 - c4-pre-sort

2023-08-01T09:14:51Z

141345 marked the issue as duplicate of #431

#2 - c4-judge

2023-08-10T14:12:27Z

0xean changed the severity to 2 (Med Risk)

#3 - c4-judge

2023-08-11T16:06:04Z

0xean 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