Uplift.

When transferring standard ERC20 deflationary tokens, the input amount may not be equal to the received amount due to the charged transaction fee. As a result, an inconsistency in the amount will occur and the transaction may fail due to the validation checks. For example, if a user sends 100 deflationary tokens (with a 10% transaction fee) to the target contract, only 90 tokens actually arrived in the contract.

There are 2 functions for the users to retrieve their tokens: - `OneChainDatesRefundVesting.withdraw()` : Will send the IDO tokens back to the user; In order to compute how many tokens will be sent, the function will call `withdrawableOf()`, which will call: ```solidity IBaseRefundRequester.ReturnRefundInfo memory info = IBaseRefundRequester(refund).infoOf( token_, identifier_, account_ ); totalClaimed += info.accountInfoOf.refundRequestedInToken; totalClaimed -= info.accountInfoOf.claimedRefundRequestedInToken; ``` - `BaseRefundClaimer.claimRefund()`: Will refund the user with the token that was used during the IDO (Buying token). In order to compute how many tokens will be sent, the function will call `_calculateRefundAmountInBuyToken()`, which will call `_getRefundAmountInIDOToken()`, which will ultimately call: ```solidity IBaseRefundRequester.ReturnRefundInfo memory info = IBaseRefundRequester(refundRequester).infoOf( token_, identifier_, account_ ); amount = info.accountInfoOf.refundRequestedWithMultiplierInToken; ``` Since those 2 functions call the same contract (`IBaseRefundRequester`), but not the same arguments to compute the refund, there is a risk that a user can call both of those functions to get a refund with the two methods.

In function `initialize()`, the variable `bpPrecision_` should not be less than the variable `tgePercentage_`. Otherwise, the result will be extremely large due to underflow.

The library `BP` is never used within the project and thus can be removed.