[MIGRATED] Protocol V3 External
[MIGRATED] Protocol V3 External
Menu bar
Quick Actions
Ribbon
Insert:
Error: Internet connection appears to be offline (0)
Spreadsheet
Sheet1
Category
Feature
ZEIP
Description
E
F
G
​
While the shift from V1 to V2 was a complete overhaul of our architecture, the V3 upgrade is more focused. The guiding principles of V3 are making 0x more liquid, language agnostic, and flexible to different asset types and execution strategies.
Asset Proxies
Static Call Proxy
When combined with the MultiAssetProxy, this allows a maker to attach custom (read-only) validation logic to their order that executes during a transfer, resembling a fingerprint or static validation. Examples include validating the state of a 721 asset, with order settlement failing if the underlying state is modified, or checking the price of an asset via an oracle.
Developer Tools
Make read functions public
Expose a number of helper and verification functions on-chain, like getOrderHash and isValidWalletSignature, to reduce the barrier to entry for new development environments.
Rich revert reasons
Improve revert reasons to include more information, like the specific offending values that caused the revert (e.g. orderHash, takerAssetAmount, etc).
Expose assetData encode/decode
Expose asset encoding/decoding helpers on-chain to enable better interaction from contracts and shared code between client SDKs, allowing for nuanced filters and callbacks as well as dynamically generated orders.
Better return data
FillResults does not currently contain information about what percentage of the order was filled.
Exchange Core
Generalized order matching
MatchOrders should allow for the taker to receive a profit in the leftMakerAsset (pure arbitrage), as well as allowing the taker to split her profit between the leftMakerAsset and rightMakerAsset, enabling more flexibility with fees.
No-throw versions of cancelOrder and batchCancelOrders
There should be a way to cancel a batch of orders without a risk of the entire transaction failing if a single cancellation fails.
Allow fees to be charged in any arbitrary asset
Currently trading fees must be paid in ZRX. This would allow fees to be charged in any arbitrary asset that is supported within the protocol.
Liquidity
New ZRX incentives
Transactions
Return values in executeTransaction
When sender contracts interact with 0x using the executeTransaction functionality they will now receive the return data for the function they executed. This allows the caller to calculate information such as the amount of tokens filled.
batchExecuteTransaction
Contracts can now execute a number of transactions in a single call. This is a gas optimisation and developer experience optimisation.
Make executeTransaction take struct as input
Change the function interface to support more properties in a 0x transaction (such as expiry).
Add ability to cancel or expire 0x transactions
Support the ability for cancellations and expirations of 0x transactions so they behave similarly to 0x orders.
Log events in executeTransaction
Log an event during executeTransaction to enable off-chain consumers to easily present this information to their users.
Validation
SignatureType that takes an entire order
Allow the signature validator to receive more information about the order, such as the tokens and their amounts. This enables late cancellation by checking on-chain oracles for price information. https://github.com/0xProject/ZEIPs/issues/33
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
​
Sheet1