orderType parameter in message format

[abandeali1]

Motivation:
As is, takers have some discretion over how orders are executed by being able to call various functions in the Exchange contract. Makers and relayers, however, have much less control. They can filter orders through other contracts by adjusting the taker field, but otherwise can expect orders to be filled and canceled by the built in protocol rules.

In addition, there have been various proposals for different order types. Some examples include:

• Contract generated orders (issue Off-chain order generation by smart contracts #1 )
• Cross-relayer orders (issue Cross-relayer orders #3 )
• Bonded orders
• Orders that use a deposit contract
• Orders that may not be canceled
• Orders that can't be partially filled
• Orders that use different forms of cryptography

Currently, any of these different order types would have to either be a) implemented across all orders or b) implemented across different contracts (and order types could be differentiated by the exchangeContractAddress). Scenario a is not always desirable, since each order type typically has its own pros and cons. Scenario b increases complexity and makes it harder/more expensive to trade across different order types (batchFillOrders would only be able to handle a single order type, for example).

Proposed Solution:
We can add an orderType parameter to the standard 0x message format. The type would be included in the hash of the order to be signed, and will therefore give makers and relayers more granular control over how their orders are executed.

Ideally, this parameter would be a dynamic byte array that could encompass multiple order types and extra arguments that must be provided. Order types would stack (for example, a non-cancelable bonded order).

Note: As Solidity does not yet support nested arrays for external function parameters, adding a dynamic byte array to the order parameters would break many of the current wrapper functions. In the short term, 32 bytes will be sufficient. Each byte would represent an opcode that will trigger a certain type of execution, until a STOP (0x00) is reached.

fillOrder and cancelOrder would check orderType for the supplied order and then execute the necessary logic. Wrapper functions such as batchFillOrders would remain unchanged, other than taking an extra orderTypes parameter.

Implementation:
TODO

[abandeali1]

In order to simplify this ZEIP and minimize the size of an order message, we can add a single validationContract address to the order message format. If it is not a null address, fillOrder and cancelOrder would call validationContract.isValidCall(...) and pass in all relevant information including: function signature of the Exchange method being called, fillTakerTokenAmount or cancelTakerTokenAmount, the caller of the Exchange contract method, and all order parameters. The validation function would then throw on an invalid fill/cancel and return true in all other cases, allowing both relayers and makers to define their own arbitrary rules on how orders are handled at the time of signing.

This would allow relayers/makers to define things like:

• A whitelist of addresses that can fill orders, even if the taker field is set to null.
• Fill/cancel size increments or min/max amounts (a relayer could turn off cancels by doing this).

This approach does not support as much functionality as the previous proposal, but would be very simple to implement and probably cheaper to execute.