callback( uint256 id_, uint256 inputAmount_, uint256 outputAmount_ ) external

1. Intended behavior.

   • Depending on the implementation of the _callback function, callback is supposed to send the payoutTokens back to the teller.

2. Negative behavior.

   • Shouldn’t send the payoutToken to someone else other than the teller.

   • Shouldn’t allow a teller with a different aggregator to call the function

3. Preconditions.

   • Assumes msg.sender is approved.

   • Assumes that a market for that id exists within the aggregators' markets

   • Assumes that the whitelist is the same as the aggregator’s; OTHERWISE, it could theoretically be called by a malicious msg.sender since there are two different whitelists. That msg.sender could then exploit the contract and drain all payoutToken; they should use the Aggregator’s whitelist just as they do with getting the markets

4. Postconditions.

   • quoteToken.balanceOf(address(this)) += inputAmount, payoutToken_.balanceOf(address(this)) -= outputAmount

   • quoteToken.balanceOf(msg.sender) -= inputAmount, payoutToken_.balanceOf(msg.sender) += outputAmount

   • priorBalances mapping should be updated properly (for both tokens)

5. Inputs.

   • uint256 id_ - controlled

   • uint256 inputAmount_ - controlled, but there is a check that the balance was increased by the corresponding value of the quoteToken tokens.

   • uint256 outputAmount* - controlled, there are no checks on the outputAmount*value, that is, any amount ofpayoutTokentokens can be sent to themsg.sender. Therefore, the market owner must be very careful with the whitelist of trusted callers.

6. Examine all function calls the function makes.

   • Call to _callback(id, quoteToken, inputAmount_, payoutToken, outputAmount_): any logic implemented by the owner of the market (it’s implementation agnostic); seems like the responsibility is shifted towards market owner.