Delegate - m4ttm's results

Securing onchain identities by linking cold and hot wallets

General Information

Platform: Code4rena

Start Date: 05/09/2023

Pot Size: $50,000 USDC

Total HM: 2

Participants: 16

Period: 6 days

Judge: GalloDaSballo

Total Solo HM: 2

Id: 284

League: ETH

Delegate

Findings Distribution

Researcher Performance

Rank: 9/16

Findings: 1

Award: $216.92

Analysis:
grade-b

🌟 Selected for report: 0

🚀 Solo Findings: 0

Findings Information

🌟 Selected for report: pfapostol

Also found by: Banditx0x, DadeKuma, m4ttm

Labels

analysis-advanced
grade-b
A-01

Awards

216.9188 USDC - $216.92

External Links

1. Audit Approach

StepTaskDetails
1Run TestsTests run successfully
2Coverage80% test coverage for contracts in audit scope
3SlitherReviewed Slither results, no vulnerabilities discovered
4SuryaGenerate graphs to understand the overall project structure. Provided an initial insight to the contract inheritance and function call flow
5Solidity MetricsGenerate metrics reports to obtain initial insight on the codebase, noting areas of potential concern
6Code ReviewLine by line code review
7Test ReviewReview of each test and it's purpose

2. Mechanism Summary

DelegateRegistry is used to create delegations and contains methods for various types of contracts including ERC20, ERC721 and ERC1155. Generic contracts are also supported. Two ERC721 tokens are minted to the user when depositing tokens into a delegate escrow. These are the DelegateToken which receives delegation rights for a given time period, and the PrincipalToken which is used to represent ownership of the escrowed token and can be used to reedem it at the end of the time period. CreateOfferer provides functionality to create delegate tokens directly from Seaport.

3. Centralisation Risks

3.1 Owner is able to change the DelegateTokenURI and royalties

The deployer owns the MarketMetadata contract and is able to change the DelegateTokenURI and royalties. This could lead to unexpected losses for users if royalties are changed without them knowing, or mislead users if the DelegateTokenURI is changed.

4. Quality Analysis

4.1 Codebase

The code is well structured and organised into separate contracts, each with a clear purpose. In depth functionality is logically separated into libraries. NatSpec comments are well used throughout the codebase. The automated findings show that some styling conventions such as line lengths and underscores before internal/private functions are not adhered to.

4.2 Documentation

The code is well commented with NatSpec comments, which are clear and informative. This could be improved by adding supplementary external documentation with diagrams outlining the workings of the core functionality.

4.3 Tests

Tests are clearly structured and cover most of the core functionality but coverage could be better than 80%. Testing could be further improved with the use of fuzz testing, or formal verification to give users the extra assurance that their funds are safe.

5. Architecture Improvements

5.1 Combine DelegateRegistry and MarketMetadata into a single factory contract

DelegateRegistry is used to create and view delegation hashes, and MarketMetadata is used to set the DelegateTokenURI and royalties. Combining these into a single deployed contract simplifies the system and makes this easier to read when using block explorers and tools using live data.

Time spent:

25 hours

#0 - c4-judge

2023-09-24T16:09:47Z

GalloDaSballo marked the issue as grade-b

#1 - GalloDaSballo

2023-09-24T16:10:04Z

Acceptable submission

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