Smart Contract Audit Report for Bolide

Management Summary

Bolide contacted Sayfer to perform a security audit on their smart contracts.

This report documents the research carried out by Sayfer targeting the selected resources defined under the research scope. Particularly, this report displays the security posture review for Bolide’s smart contracts.

Over the research period of 40 research hours, we discovered 5 vulnerabilities in the contracts. All of them have been addressed by the Bolide team

Risk Methodology

At Sayfer, we are committed to delivering the highest quality smart contract audits to our clients. That’s why we have implemented a comprehensive risk assessment model to evaluate the severity of our findings and provide our clients with the best possible recommendations for mitigation.

Our risk assessment model is based on two key factors: IMPACT and LIKELIHOOD. Impact refers to the potential harm that could result from an issue, such as financial loss, reputational damage, or a non-operational system. Likelihood refers to the probability that an issue will occur, taking into account factors such as the complexity of the contract and the number of potential attackers.

By combining these two factors, we can create a comprehensive understanding of the risk posed by a particular issue and provide our clients with a clear and actionable assessment of the severity of the issue. This approach allows us to prioritize our recommendations and ensure that our clients receive the best possible advice on how to protect their smart contracts.

Risk is defined as follows:

Audit Findings

Max Token Allowance

Description

The function addXTokens explicitly sets the allowance of the token being added to max.

● addXTokens(address, address):

if ((token) != ZERO_ADDRESS) {
    IERC20Upgradeable(token).approve(xToken,type(uint256).max);
    IERC20Upgradeable(token).approve(multiLogicProxy, type(uint256).max);
    approveTokenForSwap(swapGateway, token);
    XTokens[token] = xToken;
} else {
    xETH = xToken;
}

Mitigation

Ideally, the allowance should be precisely set, depending on the size of transactions required.

Insufficient of Input Validation

Description

Several functions such as setPercentages, initStrategies, addStrategy, deactivateStrategy, and setLogicTokenAvailable do not place validation for the incoming inputs. Similarly, in several functions in the Automation contract like setKeeper, gelatoCheckerUseToken, and gelatoCheckerRebalance, there is no check to ensure that the input address is not a zero address.

Mitigation

Implement input validation for all functions. This will ensure that the functions behave as expected and reduce the risk of vulnerabilities.

Inefficient Array Length Access

Description

The findPath function currently stores the length of the reserve.path array in a local variable before the loop.

● findPath(uint256, address):

uint256 length = reserve.path.length;
for (uint256 i = 0; i < length; ) {
   if (reserve.path[i][reserve.path[i].length - 1] == token) {
      return reserve.path[i];
   }
   unchecked {
      ++i;
   }

Mitigation

The loop should be written like this, directly accessing the length property.

for (uint256 i = 0; i < reserve.path.length; ) {
...
}

Unnecessary Initialization

Description

This contract unnecessarily initializes several variables to zero.

● getStorageAmount(address, address[]):

strategyAmountUSD = 0;
takenAmountUSD = 0;
balanceUSD = 0;
availableAmountUSD = 0;

Mitigation

Just ditch the initialization and simply use your variables.

Lack of Event Emission in a Critical Function

Description

The specified function, although it appears to fill a very important role (namely, adding new tokens to be deposited), emits no event.

Mitigation