Function create(ERC20 underlying_, uint48 expiry_, uint256 amount_)

NO UNIT-TEST or at least not direct test

1. Intended behavior.

   • This function allows any user to get the amount value of the Bond tokens in exchange for underlying_ ERC1155 tokens.

2. Negative behavior.

   • Shouldn’t mint amount of tokens if a smaller quantity of underlying_ tokens was deposited.

   • Shouldn’t mint the tokenId tokens if tokenMetadata[tokenId] doesn't exist because otherwise, it would be possible to deposit dummy tokens and then create metadata with a real token and withdraw it. Also, it means that no one should be able to edit already created items of tokenMetadata[tokenId].

   • Should be rejected if the caller doesn't have enough underlying_ tokens.

   • Should be rejected if the caller doesn't get the expected value of Bond tokens. there is no such check here, but since the fee percentage is unlimited and can be changed at any time, the caller may not agree with the withdrawn fee value. we could add a slippage check here, just as in the other BondFixedExpiryTeller.

   • Shouldn’t emit expired bondTokens since that means that they’ve vested already.

3. Preconditions.

   • tokenMetadata[tokenId] should be already created for current underlying_ and expiry_ values.

   • the caller should have enough underlying_ tokens to pay for a deposit.

   • the correct tokenId should be minted (calculated based on the pair between the payoutToken, expiry.

   • should make sure that expiry is not in the past? as in, the bondToken pair had already vested?

4. Postconditions.

   • underlying_.balanceOf(BondFixedTermTeller) >= oldBalance+amount

   • BondFixedTermTeller.balanceOf(msg.sender) ≤ balanceBefore+payout

5. Inputs.

   • ERC20 underlying_ : controlled (!), it can be any address of ERC20 token, there is should exist tokenMetadata for this token address and expiry value, but it is possible to do over deploy function.

   • uint48 expiry : controlled (!)

   • uint256 amount_ : controlled (!)

6. Examine all function calls the function makes.

   a. Call to uint256 tokenId = getTokenId(underlying_, expiry_);

   • What is controllable? (callee, params, return value): underlying_, expiry_ are controllable

   • If return value controllable, how is it used and how can it go wrong? tokenId should be unique for corresponding underlying_, expiry_ values

   • What happens if it reverts or tries to reenter? No problem

   b. Call to _mintToken(msg.sender, tokenId, amount_) see _handlePayout._mintToken description