BlazeSwapDelegation Manual Review Findings

BSD-01M: Improper Plugin Layout Assumption

Type	Severity	Location
Logical Fault		BlazeSwapDelegation.sol:L217

Description:

The code of withdrawRewardFees assumes that the first address in the list of plugins will be the BlazeSwapDelegation contract itself and as such starts iteration from the value of 1, however, this may not always be the case.

Impact:

Should the plugin layout be corrupted, the withdrawRewardFees function will be inoperable causing fees to be locked in the system.

Example:

Copy
211function withdrawRewardFees() external lock {
212    address[] storage plugins = BlazeSwapPairStorage.layout().pluginImpls;
213    BlazeSwapDelegationStorage.Layout storage l = BlazeSwapDelegationStorage.layout();
214    IWNat wNat = l.wNat; // gas savings
215    address payable rewardManager = l.rewardManager; // gas savings
216    uint256 totalRewards;
217    for (uint256 i = 1; i < plugins.length; i++) {
218        bytes memory result = DelegateCallHelper.delegateAndCheckResult(
219            plugins[i],
220            abi.encodeWithSelector(IIBlazeSwapReward.unclaimedRewards.selector)
221        );
222        totalRewards += abi.decode(result, (uint256));
223    }
224    uint256 balance = wNat.balanceOf(rewardManager);
225    uint256 extraBalance = balance - totalRewards;
226    if (extraBalance > 0) {
227        address feeTo = l.manager.rewardsFeeTo();
228        require(feeTo != address(0), 'BlazeSwap: ADDRESS_ZERO');
229        BlazeSwapRewardManager(rewardManager).sendRewards(feeTo, extraBalance, false);
230    }
231}

Recommendation:

We advise the plugin to be evaluated in relation to the address it is pointing to instead, simply issuing a continue instruction when it matches the BlazeSwapDelegation plugin.

Alleviation:

The BlazeSwap team evaluated this exhibit and stated that the layout is in fact enforced by the initializePair function present in a separate contract. While the layout may still not be proper if the contract is utilized in a different context, we consider this exhibit as addressed given that it currently fits the purposes of the BlazeSwap system.

BSD-02M: Potential Flash Loan Manipulation

Type	Severity	Location
Logical Fault		BlazeSwapDelegation.sol:L207

Description:

The vote evaluation mechanism is using spot values that can be manipulated by flash-loaning a significant sum, depositing LPs to a particular pool and invoking the changeProviders function.

Impact:

As the variable entries of providerVotes that alludes to a vote system are susceptible to flash-loan attacks, this may have wider implications as to how the delegate system works.

Example:

Copy
165function checkMostVotedProviders(BlazeSwapDelegationStorage.Layout storage l, address[2] memory newProviders)
166    private
167    view
168{
169    if (newProviders[0] == address(0) || newProviders[0] == newProviders[1]) revertInvalidProviders();
170    if (newProviders[1] == address(0) && l.allProviders.length != 1) revertInvalidProviders();
171    (address[] memory _delegateAddresses, , , ) = l.wNat.delegatesOf(l.rewardManager);
172    uint256 oldTotal;
173    for (uint256 i; i < _delegateAddresses.length; i++) {
174        oldTotal += l.providerVotes[_delegateAddresses[i]];
175    }
176    uint256 newTotal;
177    for (uint256 i; i < newProviders.length; i++) {
178        if (newProviders[i] == address(0)) continue;
179        uint256 votes = l.providerVotes[newProviders[i]];
180        if (votes == 0) revertInvalidProviders();
181        newTotal += votes;
182    }
183    if (newTotal <= oldTotal) revertInvalidProviders();
184}

Recommendation:

We advise the system to be evaluated against the flash-loan related attack as currently it is possible to artificially inflate providerVotes values as they are evaluated using a latest-value mechanism.

Alleviation:

The BlazeSwap team evaluated this exhibit and stated that flash-loan attacks for this particular voting system have limited impact and are thus not lucrative for a potential attacker. Additionally, they have imposed a security mechanism whereby the providers cannot be changed in the same transaction origin / block that delegator votes are transferred, thus providing some form of flash-loan protection. We deem this exhibit adequately addressed based on the assumption that BlazeSwap will actively monitor the function against changes in usage as it may still be susceptible to MEV attacks using a different tx.origin and normal loans.