I've encountered the following issue that I'm not able to solve myself. I'd appreciate any help from the 0x dev community.

Let's say a user is creating two buy limit orders:

  1. makerAmount: 1 USDC, takerAmount: 1 USDT -> remainingFillableTakerAmount: 1 USDT
  2. makerAmount: 1 USDC, takerAmount: 1 USDT -> remainingFillableTakerAmount: 1 USDT The user approves 2 USDC for the 0x exchange contract. At that point in time, both orders are mutually fillable.

However, if the user now reduces his approval to say 0.5 USDC for some reason, then remainingFillableTakerAmount in both orders gets updated to 0.5 USDT. That is, while each order remains fillable on an individual basis, they are no longer fillable on a combined basis.

The problem is that both orders get returned when using the orderbook api endpoint (e.g., https://ropsten.api.0x.org/orderbook/v1?quoteToken=...&baseToken=...&page=1&perPage=20). I was trying to look at the order data as well as the fillable status using getLimitOrderInfo function, but I couldn't find any identifier I could use to filter out those orders.

I could obviously go through the orderbook orders and check the allowance of each maker using the BalanceChecker contract (which allows to do this for multiple addresses), but I was hoping that there is an easier way to do that.

1 Answer 1


Yes, that is the normal behaviour for the orders, if there is still allowance orders will be returned and could be partially filled, but they will fail if user will try to fill above the allowance. That's why most apps use unlimited allowance to overcome this problem, but in other side, they pose users to unecessary unlimited allowances.

So, in short, the solution is the one you pointed out, you need to check user allowance, and then fill order till the amount allowed. You can as well, raise the allowance before if you detect that the allowance is not enough to fill the amount that user requested.

  • Thanks a lot for your quick response! Even if we turned on unlimited allowance (which we would like to avoid for security reasons), we would still have this problem as long as a user has some way to reduce it somewhere else (e.g. do it manually on etherscan). We will work on implementing the additional allowance check on our side. Is there a particular reasons why this hasn't been implemented in the orderbook api endpoint to serve users with orderbook data that is actually fillable? Jul 4, 2022 at 15:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.