BlueLabs is a Web3 infrastructure supplier that bridges decentralized finance (DeFi), multi-chain environments, and digital commerce. Their protocols enable straightforward, secure cross-chain transactions, enhanced liquidity aggregation, and simple payment solutions. Through cutting-edge cryptography and user-friendly interfaces, BlueLabs aims to advance digital asset adoption and usability. This audit prioritizes the most important smart contracts powering BlueLabs Vaults so that they are secure, stable, and efficient for the multi-chain operations and commerce-based applications of the platform.

During the audit, several vulnerabilities in BlueLabs' smart contracts with a severity of low to high were discovered. Below is a brief summary of the key issues discovered during the analysis:

Known and fixed Bugs

1. Function _updatePool() returns early and does not account for extra rewards when there is no first reward.
2. Missing slippage protection in BaseVault.sol.
3. Incorrect accounting when reward and extraReward tokens are the same.
4. Missing check for active L2 Sequencer in _getOraclePrice() function.
5. Use of incorrect MAX_RANGE value, allowing unintended strategy range.
6. Reentrancy attack risk in claim() function due to ERC777 token callback.

Main Audit Challenge

Bug Breakdown

In the OracleRewardVault contract, the _updatePool() function plays a key role in handing out token rewards. These rewards are categorized as reward and extraReward within the code. 

It works as follows: it checks if there are any rewards to distribute by comparing the current rewardBalance with the last recorded lastRewardBalance.If they are equal or there are no shares to distribute (_shareTotalSupply == 0), the function simply returns.

There is a bug in this approach, however. It doesn't account for the case where the main reward token is not paying out but the extraReward token is being distributed. This exclusion results in the extra rewards not being accounted for and thus an uneven distribution of rewards.

Scenario

• The primary reward token stops emitting rewards for a period.
• The current epoch ends for the primary reward.
• The extraReward token, however, continues to emit rewards.
• Due to the faulty early return condition, the extra rewards are never distributed to users.

Solution

To resolve this issue, we need to tweak the _updatePool() function, specifically its early return condition. It shouldn't exit too soon if the primary rewardBalance is still the same, especially when extraReward tokens are still being issued.

Recommendation

Adjust the logic in _updatePool() to make sure that the function doesn’t exit prematurely when the rewardBalance hasn’t changed. Also, it accurately tracks the extraReward tokens that are still being distributed.

Conclusion

The BlueLabs audit also identified some critical security and operational vulnerabilities that could have compromised user funds and the stability of the platform altogether. One of the main problems was the _updatePool() function not accounting for additional rewards, causing an uneven reward distribution and potential loss of funds for users. By fixing this problem and other vulnerabilities, BlueLabs has enhanced the security of its protocol, which will bring greater trust and efficiency to users conducting multi-chain DeFi activities.

Ensure your platform remains secure and your users' trust unshaken—choose AuditOne to fortify your smart contracts and build a foundation of security and reliability.
‍‍

Book your Free Security Consultation:

Google Calendar: https://calendar.app.google/Ai15eyQhiV5c1pBXA
Telegram: https://t.me/m_ndr

‍