EclipseFi

Resonance Security2 Oct 2024Repository, no commit named

Audit

Resonance Security reviewed EclipseFi on 2 Oct 2024: 6 findings, 0 critical; 3 marked fixed, 3 open.

No open critical findings

Open the report Open EclipseFi’s security record

Report stored on IPFS. Content hash QmeyHfBvp1G5j8mUh2JQR2kmhyeU1Xn3dnC6xEKE4nPj6E

Trustblock does not review code.

Findings6

Statuses are the security firm’s own, from its report.

Severity	Open	Fixed
Critical	0	0
High	0	0
Medium	2	0
Low	1	3

MediumExternal dependency on incentive distribution in lp_stakingOpen

The lp_staking contract relies on external sources to send incentives for distribution to stakers, as it lacks the ability to mint rewards internally. This creates a vulnerability where stakers may not receive expected rewards if the external sources fail or are compromised. An attacker or misconfigured system could disrupt reward distribution, leading to loss of user trust and participation in the staking mechanism.

MediumExternal Dependency on Incentive Distribution in single_sided_staking contractOpen

The single_sided_staking contract relies on external sources to send incentives for distribution to stakers, as it lacks the ability to mint rewards internally. This creates a vulnerability where stakers may not receive expected rewards if the external sources fail or are compromised. An attacker or misconfigured system could disrupt reward distribution, leading to loss of user trust and participation in the staking mechanism.

LowLack of parameter validation in try_update_date_config functionOpen

The try_update_date_config function in the voter contract lacks proper validation for critical parameters such as genesis_epoch_start_date, epoch_length, and vote_delay. While the function allows updating these values, it does not perform any validation checks to ensure that the provided inputs are within acceptable ranges or follow a logical sequence (e.g., future dates, minimum/maximum values for epoch length and vote delay).