1

The documentation for the 0x API "quote" endpoint indicates that adding a feeRecipientTradeSurplus parameter to the query should generate a transaction where any "trade surplus fees" get sent to that specified address, rather than the transaction-sender. The FAQ page further describes "trade surplus" (under the "Can I collect trade surplus (a.k.a. positive slippage)?" question) by saying "Trade surplus occurs when the user ends up receiving more tokens than their quoted amount".

I believe this means that when using the "quote" endpoint and whatever buyAmount is specified, if the price has slipped favorably for the trader and they end up with slightly more of that token than literally the buyAmount value, that is considered the "trade surplus".

However, in practice, when adding the feeRecipientTradeSurplus parameter to a call to the "quote" endpoint, no change is seen in the returned data calldata compared to not including that parameter, and when simulating the generated transaction, none of the extra buyAmount is sent to the feeRecipientTradeSurplus address. Example call:

https://api.0x.org/swap/v1/quote?
  buyToken=0x98968f0747E0A261532cAcC0BE296375F5c08398&
  sellToken=WETH&
  buyAmount=1030000000000000000&
  feeRecipientTradeSurplus=0xdf2E60Af57C411F848B1eA12B10a404d194bce27

The token this is being attempted against only has liquidity on Sushi; is there a limitation to that specific liquidity provider that isn't working for this parameter? Or am I using this parameter incorrectly?

Improve this question

1 Answer 1

Reset to default
1

Your understanding of the feeRecipientTradeSurplus parameter and trade surplus are correct.

The reason you aren't seeing any calldata changes is because we only send positive slippage to feeRecipientTradeSurplus for SELLs. For BUYs, the feeRecipientTradeSurplus is essentially a no-op. That’s why you saw no difference in calldata even after you specified the feeRecipientTradeSurplus field.

Improve this answer
4
  • Simulating the transaction calldata blob that 0x returns using the Tenderly transaction simulation service, I see the transaction sender end up with 1.040041441... tokens, not the 1.03000... requested in the API call. That seem to demonstrate that if there is any surplus (0.010041441... tokens in this case) that isn't extracted as MEV, it doesn't go to the other designated address. So I'm thinking that's more strongly indicative this is a bug?
    – MidnightLightning
    Commented Sep 11, 2023 at 20:47
  • @MidnightLightning - I revised my answer to add more clarity between how we handle sells vs buys. Will update the docs accordingly.
    – 0x_jess
    Commented Sep 11, 2023 at 20:58
  • Ah, if that's the desired effect, I'd recommend the documentation page be updated so instead of saying "any trade surplus fees" go to the feeRecipientTradeSurplus address, to something only indicating selling. As a side request, I wonder if it would be possible to enable it for BUY actions too. In this instance, the token has specific things it can be used for (swapping for a token in an NFT pool) and end-users would have no use for extra small fractions of the token (it's dust that then is effectively lost since it's not worth the gas to move).
    – MidnightLightning
    Commented Sep 12, 2023 at 0:33
  • BUYs are essentially coded as SELLs, so the user would basically almost always get positive slippage. This is unfair to the user who wanted exactly buyAmount of makerToken but due to the market conditions, they end up having to pay more takerToken for their swap. It would be even more unfair to the user if we stripped away that positive slippage from them. 👉 Regarding the specific case you mentioned, we actually just rolled out the 0x Feedback Portal, if you'd like to submit it there: 0x.canny.io/request-features
    – 0x_jess
    Commented Sep 13, 2023 at 22:40

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.