Add 'BatchFillNativeOrdersFeature' contract for 0xV4 EP on Sepolia
Please deploy the 'BatchFillNativeOrdersFeature' contract for the 'exchangeProxy' on the Sepolia testnet so that the 'batchFillLimitOrders' method on the 'exchangeProxy' can be used just like on Goerli.
Add Native USDC as option for intermediate token in multihop swap transaction on Polygon
We recently launched a new token FLTK on Polygon and also created liquidity pool for it on Quickswap Exchange. We used Native USDC as the second token in the LP pair. This is the link to created LP on Quickswap. https://quickswap.exchange/#/analytics/v2/pair/0x7d33de209e031ed97f857bf2412d7e2a7f4544e1 https://polygonscan.com/address/0x7d33de209e031ed97f857bf2412d7e2a7f4544e1 And for the interaction with the LP we wanted to use your Swap API service, which is working well for the swap between Native USDC and FLTK, but is unable to find a swap route for any other tokens to be swapped with FLTK. But if I try to do the same swap via Quickswap UI it is able to find a valid route and swap can be done. For example: Swap from MATIC to FLTK, Quickswap UI found a route WMATIC -> USDT -> USDC -> FLTK or for USDT to FLTK it found USDT -> USDC -> FLTK Now what I would appreciate if you guys check on your end is if you support Native USDC as an option for an intermediate token in the swap route. I looked at the source code of your API in Github, which I know is deprecated but still I would assume at least part of it is still being used. https://github.com/0xProject/0x-api In that source code you have defined in the constants a list of tokens that can be used as an intermediate token in a swap route, constant POLYGON_TOKENS . https://github.com/0xProject/0x-api/blob/master/src/asset-swapper/utils/market_operation_utils/constants.ts Here I noticed you do have specified USDC token as an option but that is the Bridged USDC, not the Native USDC that Circle released a couple of months ago. And this native one is also the one we are using. Bridged USDC https://polygonscan.com/token/0x2791bca1f2de4661ed88a30c99a7a9449aa84174 Native USDC https://polygonscan.com/token/0x3c499c542cEF5E3811e1192ce70d8cC03d5c3359 My request would be if you guys can also add the Native USDC to that list, so it can also be used as an intermediate token in swap routes. This would help us enable more swap pairs with our token FLTK, without the need to add extra liquidity for all other tokens on your list of intermediate tokens.
Make BUYs able to specify exact return value
Currently all BUY requests are transformed into SELL requests behind-the-scenes. That means any cost slippage the user requests gets added to the amount of token to be sold, and there's a high likelihood that the swap ends up giving more of the output token than the BUY request was for. For situations where only an exact amount of output token is desired (swapping for just enough of a token to make a purchase with it, and the user doesn't want any "dust" left over), provide the means for the user to specify "if there is positive slippage, CHARGE ME LESS input token, rather than GIVE ME MORE output token" This would likely take the form of the user giving the swap infrastructure a greater Allowance of the input ERC20 (estimated value needed, plus slippage tolerance), and the swap action only using just enough of the input token to match the desired output amount, leaving some remaining Allowance of the input ERC20.
Add recipient address for limit orders
Currently, the maker of a limit order is the always the recipient of the tokens received from the taker. It would be great if it was possible to set a recipient address to override this default behavior. This way, you can get the tokens where you need them to be a block faster and without paying additional gas for the transfer.
sortBy parameter for the limit order API
Currently the orderbook API seems to be sorted by orderHash, it would be really helpful to have a parameter to get the order sorted by createdAt, or remainingFillableTakerAmount to take an example. It would look like : https://api.0x.org/orderbook/v1/orders?perPage=1000&page=1&sortBy=createdAt where the value might be most of the field of an order
Add Support for Linea Mainnet
The Linea core team has identified multiple avenues for successful integration with 0x. First, the imminent deployment of MetaMask Swaps on Linea presents a significant opportunity for 0x to serve as a key liquidity aggregator and capture substantial network swaps activity. Second, we are launching a DeFi campaign by the end of October to further grow the Linea ecosystem, where 0x can play a pivotal role both directly and indirectly. Third, our ability to help further integrate 0x into the network through its potential integration with Protocols and Dapps. These, coupled with Linea's unique value proposition, will provide a mutually beneficial relationship for 0x and the network
Multiple account creation on 0x Dashboard
"Hello, when will you support organisation config in the 0x dashboard? I want to onboard more members of my team, but am unable to do so with current config." (This feature request was submitted by 0x Dev Support as a result of a support ticket.)
Add support for Solidly V3
Add Solidly V3 as a DEX liquidity source, it's a fork of UniV3 with up to 50% gas savings in swaps and up to 60% in LP management, helping every day users avoid the high gas costs on Ethereum. Additional features are full JIT attack protection and forms of IL mitigation.