0x V3 Feature Set

⌨️ Technical Development Core Protocol
1

Internally we are beginning to think about and prioritize the feature set for 0x v3.

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:

  • Grow liquidity
  • Improve developing on 0x
  • Adding flexibility in different asset types and execution strategies

While nothing is finalized, the core team has listened to feedback from projects building on 0x and has proposed a number of ZEIPs.

If you have a particular feature in mind and would like to see it included in v3, please get in contact on the forum or create a ZEIP.

External document here.
ZEIPs for v3 are documented here.

3 Likes
2

I think it was mentioned elsewhere (maybe on a call), but that futures versions would have a way to check for order validity via the smart contracts?

At the moment order validation requires alot of RPC calls, and if some (or all) of these could be moved on chain it will be an improvement when having to check across thousands of orders.

Otherwise I really like the proposed changes that will allow for order validation (allows for different order types) and being able to access price feeds of other on-chain oracles. As this will really enrich 0x-feature set.

3

Re: “Possible Features” list: The “Post Dated Transactions” feature is very close to something I was thinking about submitting as a ZEIP. But if it could be done as a v3 feature, would be even better/easier. An “Escrow Contract” is what I’ve been calling it so far, it would basically be a hybrid of the “Anti-Griefing Deposit Contract” and the “Post-Dated Transaction”; the use-case would be locking tokens until a specified condition is fulfilled. If “Post Dated Transactions” had the ability to be cancelled by a designated party (an address), that would get me 90% of the way to satisfying the use-case I had in mind.

1 Like
4

Totally, this has been a pain for us internally so we’re going to add a number of helpers to check that an order is valid in all aspects.

The latest Exchange Wrapper now simulates an actual transfer of the asset, so that helps in checking any pesky transfer restrictions. Hopefully we can get full validation down to 2 eth_calls and allow batching where possible to speed up the request/response cycle overhead.

A lot of this will likely come in the form of a helper wrapper contract, so might not explicitly be in the Exchange contract.

5

There are some interesting cases opened up with the StaticCall “Asset Proxy”. This allows you to check some state specified in the order. For example the state could be “is blockTime > X yet?”. It can also allow for “Did is Y storage slot set therefor this order is no longer valid”

3 Likes
6

Just wanted to voice my support for post-dated orders. As it would enable trustless TWAP & VWAP like strategies.