Maia DAO - Ulysses - DevABDee's results

Harnessing the power of Arbitrum, Ulysses Omnichain specializes in Virtualized Liquidity Management.

General Information

Platform: Code4rena

Start Date: 22/09/2023

Pot Size: $100,000 USDC

Total HM: 15

Participants: 175

Period: 14 days

Judge: alcueca

Total Solo HM: 4

Id: 287

League: ETH

Maia DAO

Findings Distribution

Researcher Performance

Rank: 67/175

Findings: 2

Award: $57.72

Gas:
grade-b

🌟 Selected for report: 0

🚀 Solo Findings: 0

Findings Information

Awards

40.0102 USDC - $40.01

Labels

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

External Links

Lines of code

https://github.com/code-423n4/2023-09-maia/blob/f5ba4de628836b2a29f9b5fff59499690008c463/src/interfaces/ILayerZeroUserApplicationConfig.sol#L24

Vulnerability details

The protocol doesn't implement a very important LayerZero function.

It is highly recommended by LayerZero to implement ILayerZeroUserApplicationConfig.forceResumeReceive(), because;

Implementing this interface will provide you with forceResumeReceive which in the worse case can allow the owner/multisig to unblock the queue of messages if something unexpected happens. -LayerZero Docs.

Impact

Better handling of queue msgs in worse case scenarios.

Proof-of-Concept

https://layerzero.gitbook.io/docs/evm-guides/best-practice

Tools Used

Manual Review

Consider implementing ILayerZeroUserApplicationConfig.forceResumeReceive().

Assessed type

Other

#0 - c4-pre-sort

2023-10-11T11:21:41Z

0xA5DF marked the issue as duplicate of #875

#1 - c4-pre-sort

2023-10-11T11:21:46Z

0xA5DF marked the issue as sufficient quality report

#2 - alcueca

2023-10-22T04:49:16Z

Misses the attack angle via underfunded transactions that makes it a valid DoS

#3 - c4-judge

2023-10-22T04:49:21Z

alcueca marked the issue as partial-50

#4 - c4-judge

2023-10-22T04:49:25Z

alcueca marked the issue as satisfactory

#5 - c4-judge

2023-10-22T04:56:29Z

alcueca marked the issue as duplicate of #399

Awards

17.7101 USDC - $17.71

Labels

bug
G (Gas Optimization)
grade-b
sufficient quality report
G-20

External Links

1. Instead of doing same calculation again and again inside a function, consider saving it into a memory variable and then use it

_amount - _deposit is used at many places in the codebase and everywhere it is calculated. Like in the following code. Same calculation will cost more gas, better to cache it into a variable first and then use it multiple times.

        if (_amount - _deposit > 0) {
            unchecked {
                ///@audit-issue G Multiple same calculation will cost more gas, better to cache it into a variable first 
                _hToken.safeTransferFrom(msg.sender, address(this), _amount - _deposit);
                ERC20(_hToken).approve(_localPortAddress, _amount - _deposit);
            }
        }
Optimize the code like this:
        uint256 calc = _amount - _deposit;

        // Check if the local branch tokens are being spent
        if (calc > 0) {
            unchecked {
                ///@audit-issue G Multiple same calculation will cost more gas, better to cache it into a variable first 
                _hToken.safeTransferFrom(msg.sender, address(this), calc);
                ERC20(_hToken).approve(_localPortAddress, calc);
            }
        }

There are more than 10 instances where this optimization needs to be implemented.

#0 - c4-pre-sort

2023-10-15T17:24:13Z

0xA5DF marked the issue as sufficient quality report

#1 - c4-judge

2023-10-26T13:45:13Z

alcueca marked the issue as grade-b

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