Function deploy(ERC20 underlying_, uinty48 expiry_)

1. Intended behavior.

   • Allow users to create a new ERC20 token and associate it with underlying and expiry_ values.

2. Negative behavior.

   • Disallow creating a pair of underlying and expiry that would overwrite already existing bondToken.

   • Disallow creating a pair with expiry in the past OR expiry different than 0 (they do have that condition in handlePayout)

   • Also there isn’t any functionality to remove a bondToken

3. Preconditions.

   • That underlying exists (there’s no check, however, that it’s address 0)

   • That no bond for the underlying, expiry pair already exists

   • decimals() are standardized

   • That the expiry_ is at least in the future

4. Postconditions.

   • That a bondToken is successfully created(if one did not previously exist)

   • That clone will be reverted in case of bondToken for these parameters already exists.

   • That the bondToken[underlying_][expiry_] stores the newly created contract address.

5. Inputs.

   • ERC20 underlying_: validation check that the pair of underlying, expiry doesn’t already exist

   • uint48 expiry_: validation check that the pair of underlying, expiry doesn’t already exist; also there is no check that is in the past.

6. Examine all function calls the function makes.

   a. Call to underlying_.decimals()

   • What is controllable? (callee, params, return value): there is no params value.

   • If return value controllable, how is it used and how can it go wrong: No problem.

   • What happens if it reverts or tries to reenter: deploy has nonReentrant modifier.

   b. Call to ERC20BondToken(address(bondTokenImplementation).clone(tokenData))

   • What is controllable? (callee, params, return value): tokenData is partly controllable.

   • If return value controllable, how is it used and how can it go wrong: return the new bondToken address.

   • What happens if it reverts or tries to reenter: should revert in case of token already exists.