Skip to content
This repository has been archived by the owner on Jul 9, 2021. It is now read-only.

Forwarder Market sell specified amount or throw #2521

Merged
merged 7 commits into from
Mar 31, 2020

Conversation

dekz
Copy link
Member

@dekz dekz commented Mar 12, 2020

Description

We wish to sell a specific amount or throw. This is then consistent with marketBuyOrdersWithEth and our usage of FillOrKill functions in asset-swapper.

marketSellOrdersWithEth does not throw and is a surprise to many users and inconsistent when selling DAI versus selling ETH via asset-swapper/0xApi. Generally we view fills as having funds for the takerAssetAmount and an additional source of funds for the protocolFee. Asset-swapper is no longer guaranteeing that the orders are always sorted by adjusted price (due to redundant path), so this opens up a potential issue where we partially fill some "ok" orders.

One thing to note is how ethSellAmount interacts with protocol fees. We wish to sell 50 ETH for example and not 49.9 ETH and 0.1 ETH of protocol fee. In normal conditions these are distinct (WETH and ETH in value, WETH and WETH (allowance)). This function also treats them as seperate pools, (ethSellAmount ETH and protocol fee ETH also in value). To sell 50 ETH using this function the user will need to specify ethSellAmount=50 and send value=50.1 to sell and pay protocol fee.

In the event of a successful marketSell which encountered unfillable orders, the additional protocolFees are returned, rather than sold in following orders.

TODO

  • clean up as there is a bit of duplicate functionality
  • use the struct everywhere for consistency?

@dekz dekz force-pushed the feat/forwarder/market-sell-amount branch from 7de6590 to 5b438bc Compare March 12, 2020 10:49

// The remaining amount of WETH to sell
uint256 remainingTakerAssetFillAmount = wethSellAmount
.safeSub(totalWethSpentAmount);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we also want to safeSub(totalProtocolFeePaid)?

Copy link
Member Author

@dekz dekz Mar 16, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps the naming is off right now or I am missing something, but wethSellAmount in the parameter is exclusive of protocol fees. So we don't want to subtract the protocolFee as it is not included in wethSellAmount. I.e A user calls marketSellAmountWithEth with 2 ETH and provides 2.1 ETH in value. We then proceed to sell 2ETH, not 2.1 ETH. We're not using msg.value.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh, OK. I forgot wethSellAmount is minus protocol fees already.

// The remaining amount of WETH to sell
uint256 remainingTakerAssetFillAmount = wethSellAmount
.safeSub(totalWethSpentAmount);

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if we also did something like this here:

if (remainingTakerAssetFillAmount > singleProtocolFee) {
    // Do not count the protocol fee as part of the fill amount.
    remainingTakerAssetFillAmount = remainingTakerAssetFillAmount.safeSub(singleProtocolFee);
} else {
    // Stop if we don't have at least enough ETH to pay another protocol fee.
    break;
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My hunch is line 206 (.safeSub(_isV2Order(orders[i]) ? 0 : protocolFee);) in _marketSellNoThrow() is probably where I was seeing those rigo + USDC + high gas reverts, so adding something similar to that function could also fix that.

Copy link
Member Author

@dekz dekz Mar 16, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can make this change on the other sell variant. See other comment.

@dekz dekz force-pushed the feat/forwarder/market-sell-amount branch from 5b438bc to 3ba8dc2 Compare March 16, 2020 07:18
@dekz dekz marked this pull request as ready for review March 16, 2020 07:31
@dekz dekz requested review from abandeali1 and hysz as code owners March 16, 2020 07:31
@coveralls
Copy link

coveralls commented Mar 16, 2020

Coverage Status

Coverage increased (+0.05%) to 79.739% when pulling 77bdb90 on feat/forwarder/market-sell-amount into bf00e67 on development.

Copy link
Contributor

@dorothy-zbornak dorothy-zbornak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 👍 👍


// The remaining amount of WETH to sell
uint256 remainingTakerAssetFillAmount = wethSellAmount
.safeSub(totalWethSpentAmount);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh, OK. I forgot wethSellAmount is minus protocol fees already.

if (wethSpentAmount < ethSellAmount) {
LibRichErrors.rrevert(LibForwarderRichErrors.CompleteSellFailedError(
ethSellAmount,
wethSpentAmount
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now I'm wondering if it would be more useful to know how much we actually sold minus the protocol fee. What do you think?

Copy link
Contributor

@moodlezoup moodlezoup left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good to me!

@dekz dekz force-pushed the feat/forwarder/market-sell-amount branch from 9381bca to b2e38cf Compare March 30, 2020 05:18
@dekz dekz merged commit 424cbd4 into development Mar 31, 2020
@dekz dekz deleted the feat/forwarder/market-sell-amount branch March 31, 2020 06:25
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants