Function _handlePayout(address recipient, uint256 payout_, ERC20 underlying_, uint48) internal
Intended behavior.
The function is supposed to handle the payout of
payouttokens to the user. Not covered directly because it’s an internal function.
Negative behavior.
It shouldn’t transfer tokens to user if the vesting has not expired.
It shouldn’t allow any
_underlyingto be transferred.It shouldn’t allow transfer on behalf of other users.
It shouldn’t allow transfer of untrusted tokens.
It shouldn’t call mint function of untrusted
bondToken.
Preconditions.
That there exist enough
underlying_tokens from the market creator/owner.bondTokenfor correspondingunderlying_token andexpirytime should exist.
Postconditions.
user
bondTokens[underyling][expiry]balance >= payout_+ oldBalance;OR
user
underlying balance ++andBondFixedExpiryTellerunderlying balance--
Inputs.
address recipient_: controlled - the destination of minted bondToken or transferred underlying.
uint256 payout_: controlled - the amount of
underlyingor minted bondTokensERC20 underlying_ : uncontrolled
uint48 vesting_: uncontrolled - period in time until which the bond mature
Examine all function calls the function makes.
a. Call to
underyling.safeTransfer:What is controllable? (callee, params, return value): everything is controllable. However, it’s an internal function, so all checks take place outside of this function
If the return value is controllable, how is it used, and how can it go wrong: There is no return value.
What happens if it reverts or tries to reenter: will be reverted if the contract doesn't have enough
underlyingtokens
b. Call to
bondToken.mint:What is controllable? (callee, params, return value): recipient* is controllable, payout* is controllable.
If return value controllable, how is it used and how can it go wrong: there is no return value.
What happens if it reverts or tries to reenter: only in case
totalSupplywill reach the uint256 max value.