-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow taker
to be different from sender
with optional taker
signature
#18
Comments
The above approach is a naive solution to this issue. Realistically, the taker needs to be able to choose which method is being called in order to have the full range of functionality that a taker calling the Exchange contract directly would have. This is slightly tricky because all of the Exchange functions take different arguments (this could be solved with #16). A slightly different approach (and replacement for #16) involves creating a new message type: a 0x transaction message. This would be represented as two (probably tightly packed) byte arrays. The first would contain the methodId and function arguments of the desired function to call, and the second would contain a signature of the hash of the data (from the taker in this case). It could look something like the following:
|
We discussed the potential for a Relayer (or anyone if the sender is not set) to mount a replay attack with this proposed improvement. In this scenario, a Taker would sign Any listener (or malicious Relayer if sender is set) could re-submit this transaction N times up until the order is filled. A simple replay attack prevention scheme would be to store |
Here is a simpler to implement version of my last comment using
|
Hey @abandeali1 this is a great ZEIP! Have you made any decisions if/when this could be implemented? |
This has already been implemented and will be included in the next upgrade (scheduled for September). |
Summary
In the current implementation of the
Exchange
contract, thetaker
of an order is alwaysmsg.sender
. By optionally allowing the signature of the taker to be passed intofillOrder
, we can decouple these two addresses and allow for much greater flexibility.Motivation
This change would allow for much easier implementations of
Exchange
wrapper contracts. Wrapper contracts are currently impractical because they are required to hold the taker's tokens that will be exchanged. Some basic use cases for wrapper contracts include:batchFillOrders
orfillOrdersUpTo
)In addition, this change greatly simplifies logic for relayers using the matching strategy. There is now a clear distinction between the
maker
andtaker
of an order in this model, simplifying logic for calculating fees. Tokens will also be swapped directly from themaker
totaker
, which results in fewer intermediate state changes and lower gas costs.Implementation
For the purposes of this proposal it makes sense to rename the
taker
parameter in the message format tosender
, since the two are no longer necessarily the same (note: a case can be made for including bothtaker
andsender
parameters in the order message format).Psuedocode for
fillOrder
:The text was updated successfully, but these errors were encountered: