Zaros Part 1

Summary

Off-chain order keepers do not have a way to supply native currency to fill successfully off-chain orders.

Vulnerability Details

Let’s follow the internal calls when an off-chain orders keeper calls fillOffchainOrders().

fillOffchainOrders() -> verifyOffchainPrice() -> verifyDataStreamsReport() -> getEthVericationFee() -> verifyReport()

The code calls Chainlink’s getFeeAndReward() function to know what fee we should give to Chainlink for the verification (the fee could be in the form of tokens or native currency).

verifyReport() in our case calls the Chainlink verifier by providing the fee amount in the form of native currency.

Reference to code: link

The issue is that keepers do not have a way to supply native currency in order for the verifyReport() internal call to be successful. Current implementation contracts do not have a receive function and the only payable function present is the createTradingAccountAndMulticall().

This means that in order for keepers to be able to do their job, they will have to periodically call createTradingAccountAndMulticall() in order to supply native currency to the contract and they will keep creating new trading accounts that they will never use. After supplying native currency they will be able to call fillOffchainOrders() successfully.

It seems that part of the logic that handles native currency transfers is incomplete.

Impact

Keepers cannot function normally without calling separately unrelated to them functions in order to successfully call fillOffchainOrders().

Tools Used

Manual Review

Recommended Mitigation

This is a design decision that the team should take for themselves since there is no info regarding who has to pay the chainlink verification fee.

If keepers are the one that have to pay the verification fee then fillOffchainOrders() should be made payable and the excess funds that are not used by Chainlink to be returned to the keeper. If the funds that are left after the verification fee are not returned to the user then either the team has to decide that they will be left in the contract to accumulate and be used at some stage by another keeper or the team could decide to have a withdraw function to collect the remaining dust.

In case users are the ones who have to supply this native currency, logic that determines how much must be sent and verify if it is indeed sent has to be implemented.