Platform: Code4rena
Start Date: 05/10/2023
Pot Size: $33,050 USDC
Total HM: 1
Participants: 54
Period: 6 days
Judge: hansfriese
Id: 294
League: ETH
Rank: 36/54
Findings: 1
Award: $10.69
🌟 Selected for report: 0
🚀 Solo Findings: 0
🌟 Selected for report: polarzero
Also found by: 0x3b, 0xSmartContract, 0xnev, ABA, Bulletprime, J4X, Limbooo, MrPotatoMagic, SBSecurity, Sathish9098, asui, d3e4, hyh, ihtishamsudo, inzinko, marchev, pfapostol, radev_sw, rahul, ro1sharkm
10.6913 USDC - $10.69
Contract Overview:
The ENS Multi Delegate contract is designed to address the limitations of traditional delegation contracts by using ERC1155 and proxy contracts. It enables users to delegate their voting power with each delegation represented as an ERC1155 token.
Code Components:
The contract incorporates several features and components, including the ability to approve and delegate votes, manage multiple source/target pairs, and transfer tokens and votes. The ERC20ProxyDelegator is used to facilitate the delegation process.
Key Functionality:
DelegateMulti Functionality: Users can delegate their votes to multiple target addresses in a single transaction, allowing for efficient management of voting power. Token Management: ERC1155 tokens are used to represent ownership of vote tokens, and transfers are tracked through this standard. This enhances token management and transparency. Revocation Limitation: The contract lacks a built-in mechanism for users to revoke or renounce a delegation. The absence of this feature could limit user flexibility.
Issues Identified:
Approval of 0 Votes:
The contract allows users to approve the delegation of 0 votes, which effectively nullifies the delegation. While this may be intentional, it can lead to confusion and should be considered for improvement.
Lack of Delegation Revocation:
The contract does not provide a built-in mechanism for users to revoke delegations at a later time. This absence could be a limitation for users who want to change their delegation preferences.
Self-Transfer with Duplicate Source/Target Pair:
The contract does not check for duplicate source/target pairs when executing the DelegateMulti function. This allows a user to inadvertently perform self-transfers of tokens and votes, which might not be the intended behavior.
Lack of Token Balance Validation:
The createProxyDelegatorAndTransfer
function of the contract lacks validation for the token balance of the msg.sender. This exposes a potential risk where a user might not have enough tokens to perform the transfer which can lead to unintended behavior.
Security Considerations:
The contract appears to be designed with security in mind, utilizing proxy contracts and leveraging the ERC1155 standard for transparency. However, the self-transfer issue and the lack of certain checks could pose potential security concerns.
Recommendations:
Self-Transfer Issue: Implement checks to prevent self-transfers of tokens and votes when duplicate source/target pairs are detected.
Approval of 0 Votes: Consider implementing checks to ensure that a minimum number of votes, greater than 0, must be approved before delegation to avoid approval of 0 votes.
Delegation Revocation: Evaluate whether adding delegation revocation functionality would enhance user flexibility and usability.
Token Balance Validation: Enhance the createProxyDelegatorAndTransfer
function to validate the token balance of the msg.sender before executing the transfer.
Severity Assessment:
Approval of 0 Votes: Low
Lack of Delegation Revocation: Low
Self-Transfer with Duplicate Source/Target Pair: low
Comments:
The ENS Multi Delegate contract introduces an innovative approach to delegation, utilizing ERC1155 tokens and proxy contracts. While the contract shows promise, there are areas that need attention, particularly the self-transfer issue and the lack of delegation revocation functionality.
Architecture Recommendations:
Consider enhancing the architecture to minimize centralization risks and maximize decentralization.
Evaluate mechanisms for mitigating systemic risks, especially related to the self-transfer issue.
Codebase Quality Analysis:
The overall codebase quality is decent, but improvements are possible in terms of usability and security.
Centralization Risks:
There is a centralization risk associated with privileged functions in the contract, specifically the setUri
function. This risk could lead to a single point of failure.
Mechanism Review:
The mechanisms in place such as ERC1155 token representation are efficient and effective.
Systemic Risks:
Addressing systemic risks particularly the self-transfer issue is crucial to ensure the contract operates as intended.
Incorporating these recommendations will enhance the contract's usability and security while maintaining its innovative features. The self-transfer issue should be addressed promptly to prevent unintended consequences. The overall security of the contract is promising, but vigilance is required to maintain the integrity of the delegation process.
12 hours
#0 - c4-pre-sort
2023-10-14T07:21:59Z
141345 marked the issue as sufficient quality report
#1 - c4-judge
2023-10-24T16:41:11Z
hansfriese marked the issue as grade-b