You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Approvals are a wretched user experience that confuses everyone who is new to the platform and frustrates those who are experienced with the platform. They also encourage the "approve all" workflow which increases risk for users when security vulnerabilities are discovered in the contracts they approve.
Specification
Note: This is a high level overview. If this ZEIP is considered favorable, I (or someone else if they desire) can flesh out the details.
When someone wants to take an order, instead of approving 0x to spend their tokens first and then submitting the order to 0x, they would instead issue a .send on their ERC-777 token destined for the 0x exchange contract and with the data field containing the 0x order details.
The 0x exchange contract would be called by the token via the tokensReceived callback. Upon receiving the token callback, it would then process that order the same as it does ERC20 orders with the exception of not needing to withdraw the tokens from the user (because it has already received them prior to this call).
Rationale (if a suggestion is proposed)
Approvals suck. Users hate them. UX designers hate them. Developers hate them.
The text was updated successfully, but these errors were encountered:
This doesn't have to be in the Exchange contract - there are already plans to support ERC721 and ERC1155 callbacks in the v3-compatible Forwarder contract. It would be pretty trivial to add support for ERC777 callbacks as well using the same pattern (transfer in, fill order(s), transfer out). I can link to it here when it is more fully specced out.
Hey @MicahZoltu we justapplied the new standard tagging to this ZEIP (see here).
The proposal makes sense - 0x Core Team does not have the bandwidth to work on this right now. Is this something you would consider pushing forward, or do you need another team to work on it?
Summary ( 2-5 Sentences )
Support and leverage ERC-777 token functionality.
Motivation
Approvals are a wretched user experience that confuses everyone who is new to the platform and frustrates those who are experienced with the platform. They also encourage the "approve all" workflow which increases risk for users when security vulnerabilities are discovered in the contracts they approve.
Specification
Note: This is a high level overview. If this ZEIP is considered favorable, I (or someone else if they desire) can flesh out the details.
When someone wants to take an order, instead of approving 0x to spend their tokens first and then submitting the order to 0x, they would instead issue a
.send
on their ERC-777 token destined for the 0x exchange contract and with thedata
field containing the 0x order details.The 0x exchange contract would be called by the token via the
tokensReceived
callback. Upon receiving the token callback, it would then process that order the same as it does ERC20 orders with the exception of not needing to withdraw the tokens from the user (because it has already received them prior to this call).Rationale (if a suggestion is proposed)
Approvals suck. Users hate them. UX designers hate them. Developers hate them.
The text was updated successfully, but these errors were encountered: