Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Preamble
Discussion: #33
Simple Summary
Introduce new signature types for orders and and change validation behavior.
Abstract
Add more robust order and transaction signature validation with the following callback signature types, which accept an entire
Order
orZeroExTransaction
object:Validator
(*replaces existing behavior)EIP1271Wallet
Also, all signature types (including these) will be checked on every fill. This is in contrast to the behavior in
2.0
where we only validate the signature on the first fill.Motivation
In
2.0
, we haveValidator
andWallet
signature types, which can only validate against a hash, which means the order/transaction must be somehow registered with the validator contract prior to execution to determine meaningful context. It would be more useful if the validator contract was provided with the complete order/transaction data so they can implement more nuanced and dynamic filtering criteria.Recent improvements to solidity and
ABIEncoderV2
have made this approach relatively simple to execute.Specification
Restrictions
staticcall()
. If the contract attempts to update state during call, the validation will fail.Validator
signature type must be registered in advance viasetSignatureValidatorApproval()
(unchanged from2.0
). This only has to be done once per validator-signer pair.Signature Encoding
The
Validator
signature type is tightly packed with the ordered fields:The
EIP1271Wallet
signature type is tightly packed with the following ordered fields. Note that the address of the validator contract is implied as the order maker or transaction signer.Implementation
Contracts validating the
Validator
andEIP1271
signature types follow the EIP-1271 pattern and must expose the following callback:EIP-1271
data
EncodingThere are two ways the
data
parameter forEIP1271Wallet
andValidator
signatures can be encoded, depending on what type of data is signed:abi.encodeWithSelector(bytes4(0x3efe50c8), Order order, bytes32 orderHash)
abi.encodeWithSelector(bytes4(0xde047db4), ZeroExTransaction transaction, bytes32 transactionHash)
Example
Here is a complete (if trivial) implementation that validates an Order signature:
Copyright
Copyright and related rights waived via CC0.