I think there is a bug in the checkSendLimit function. The line 237 of the Hub.sol, should be return max.sub(destBalance);.
The consequence is that the returned value is a bit higher than theoretically expected.
however I think it doesn't create any inconvenience for us because. it only allows to have a bit of buffer in the actual transfers, right? Because then in the line 340 of Hub.sol, you use that returned value to compare with the wad of the path given. And, if the path given is calculated with a more restrictive calculation (like actually calculating the max allowed receiving by substracting the destBalance instead of desBalanceScaled), then the path will be correct.
However, if we use the same code of the checkSendLimit of the Hub.sol, to calculate the remaining receive allowance... then we might get the next step of the path invalid because it doesn't pass the restriction in line 232: if (max < destBalance) return 0;
I think there is a bug in the
checkSendLimit
function. The line 237 of the Hub.sol, should bereturn max.sub(destBalance);
.The consequence is that the returned value is a bit higher than theoretically expected.
however I think it doesn't create any inconvenience for us because. it only allows to have a bit of buffer in the actual transfers, right? Because then in the line 340 of Hub.sol, you use that returned value to compare with the wad of the path given. And, if the path given is calculated with a more restrictive calculation (like actually calculating the max allowed receiving by substracting the destBalance instead of desBalanceScaled), then the path will be correct.
However, if we use the same code of the checkSendLimit of the Hub.sol, to calculate the remaining receive allowance... then we might get the next step of the path invalid because it doesn't pass the restriction in line 232:
if (max < destBalance) return 0;