Hotfix rm#230
Conversation
|
|
||
| if (isSupported) { | ||
| supportedTokens[supportedCount] = currentToken; | ||
| // Only count newly claimable balance, not existing contract balance |
There was a problem hiding this comment.
Hey, I was thinking that we don't need to do this since we are happy to report the entire actual balance as the rewards. This is because we are only concerned the impact on the LAT. So in using the entire balance, we prevent the transfer loss issue, reduce computation of checking "balance before" and in any edge case of additional tokens above the merkle claim, we are able to use it in the LAT.
This pattern also becomes of actual use in the case of rebasing token being unsupported. So in case we do swapAndTransferRewards we can maintain the pattern of full token balance
Note on this was added to the struct definition in the interface
/// @dev These values tell us the actual tokens realized by the LAT after a process claim procedure
/// @dev The values may differ from the corresponding EL event due to rounding/transfer loss or unexepected token transfers to this contract
/// @dev We are only concerned with actual value accured to LAT, exact EL data can be found via corresponding EL events
Any thoughts?
There was a problem hiding this comment.
Note that this pattern differs from "balance before/after" in LTM/LT contracts because, here we are not concerned with specifying any token amount to transfer, by default the goal is for full token balance to be transferred
| for (uint256 i = 0; i < assets.length; i++) { | ||
| if (unsupportedAssetBalances[address(assets[i])] == 0 && amounts[i] > 0) { | ||
| unsupportedAssets.push(address(assets[i])); | ||
| address assetAddr = address(assets[i]); |
There was a problem hiding this comment.
If the comment above is accepted, do we still need to make this additive? We might as well reset it every time anyway?
2 participants
No description provided.