Mock partial swapping

[valiafetisov]

Goal

A user is able to use swapping to partially take collateral auctions.

Context

Currently, we only allow partial bidding on collateral auctions when participating with your own DAI. But it's also possible to do so with swap-like transaction using callee. The only technical problem (and the advantage for the user) is that every time the bid amount is changed, the market unit prices will also change (and we might also need to refetch them in order to display correct numbers).

Note: this feature was first time proposed in #229

Tasks

• Conceptualise UI
  • Figure out what can be changed (amount DAI vs amount of the collateral vs proportion)
  • Figure out how it can be changed (slider vs input vs something else)
  • Figure out how input/output errors are displayed
  • Figure out how we suggest optimal swapping size (or if we even do so)
  • Figure out how it plays together with multi-callee
• Create a summary

[valiafetisov]

I've initially tried adding yet another expandable list into the table (and to remove all extra rows)

Failed mock

Since we want to find the best net profit and the liquidity is different between exchange protocols (and even routes), the prices will also be different per market for each amount. But the there is a complicated question of the connection between market and bidding amount as they basically influence each other: setting one will lead to the "suggested change" in the other otherwise the user might not have a tool to inspect all possible combinations. Therefore, the suggestion is to "probe" few fixed points of the amount to see if they make sense. And then, ideally, we would try to present it as 2D map of net profits. So it might look like this:

Notes:

• We can technically use binary search algorithm (or similar) to find the best possible amount. This might take a lot of requests especially if we want to do it every 30 seconds. This can a separate next feature (discovering the best bidding amount) for now I think it's enough to make a few probes
• When user sets a new value via the input field, we can also probe all markets and add results into the table for comparison. But maybe we don't allow user input at all in the first iteration (not sure about this one since)

Next step: find a good place to incorporate the table into the UI. I imagine it can become visible both:

• when user wants to adjust Market unit price
• when user wants to adjust Amount to bid

[LukSteib]

Early remarks:

• high level consideration that we might need to discuss: From my understanding for the protocol in most of the cases it is not advantageous for the protocol if an auction is only partially executed (since part of the bad debt remains). This holds true for the original vault owners as well. Hence it might be worth to reconsider if at all or in which occasions we want to propose a partial execution per default. The situation where partial swap is indeed advantageous for the protocol is when otherwise the auction wouldn't be taken at all in the first place (question: How to identify this situation?)
• besides the complexity of interdependency between market and amount to bid I also think the "failed mock" would make it very difficult for a (rather inexperienced) user to understand what is going on. So definitely prefer this table based approach
• What do the values displayed in the table cells refer to? Net profit?
• What does Unknown mean? Not enough liquidity in the pool(s) to execute the amount?

We can technically use binary search algorithm (or similar) to find the best possible amount. This might take a lot of requests especially if we want to do it every 30 seconds. This can a separate next feature (discovering the best bidding amount) for now I think it's enough to make a few probes

Agree to put this out of scope for now. Given my initial comment we might think about to stick to 100% bidding amount as the default and just provide option for user to change via table (without suggesting anything).

When user sets a new value via the input field, we can also probe all markets and add results into the table for comparison. But maybe we don't allow user input at all in the first iteration (not sure about this one since)

To me it makes sense to reduce complexity and go with the predefined chunks only (as seen in table) in the first place.

[valiafetisov]

high level consideration that we might need to discuss: From my understanding for the protocol in most of the cases it is not advantageous for the protocol if an auction is only partially executed (since part of the bad debt remains).

I don't think that we should consider what's best for the protocol, because:

• The design of the protocol already enforces that: that more you take the bigger profit you make. Partial liquidation can be more profitable than a complete swap only if the debt is very big, so there is not enough liquidity on the market. In this case it's also good for the protocol to swap it in parts without overwhelming the market
• We can only aim to make the best tool for the user, not protocol

What do the values displayed in the table cells refer to? Net profit?

Yes, the idea is to display net profit, since that's what matters, but also add this popup to show more data

What does Unknown mean? Not enough liquidity in the pool(s) to execute the amount?

It means we can't get the price for whatever reason. Maybe there is not enough liquidity, maybe there is no pool at all, maybe the service is down (in case of 1inch). I suggest to include the exact error message in the popup.

To me it makes sense to reduce complexity and go with the predefined chunks only (as seen in table) in the first place.

The problem with that is we can't know for sure what percentage will be even tradable. Also, the user might find it very limiting since we provide this information for the other "Bid with DAI" flow. But if it adds too much complexity, I fine with splitting it into two issues.

[LukSteib]

Partial liquidation can be more profitable than a complete swap only if the debt is very big, so there is not enough liquidity on the market. In this case it's also good for the protocol to swap it in parts without overwhelming the market

Yes this is what I was wrapping my head around. But agree, then by design of the protocol in most of the cases the complete swap will at the same time also be the most profitable one for the auction participant.

Yes, the idea is to display net profit, since that's what matters, but also add this popup to show more data

Understood, I like it. We just need to ensure to make it clear to the user (e.g. via table heading or by including the number in the popup again with the other details).

I suggest to include the exact error message in the popup.

Makes sense, agree.

The problem with that is we can't know for sure what percentage will be even tradable

What prevents us from that?
An additional related thought: Can we determine in advance whether the leftover debt satisfies requirement imposed by chost (ie. minimum leftover auction debt amount)? Would you consider that as another error case for the popup?

Also, the user might find it very limiting since we provide this information for the other "Bid with DAI" flow.

It might be a little constructed argumentation: But one could argue that the fact of bringing own funds to the table (aka bidding with DAI) comes with the upside of higher flexibility in terms of the bid amount. While the swapping without cap requirement justifies restriction on bid amount specification...

[valiafetisov]

The problem with that is we can't know for sure what percentage will be even tradable

What prevents us from that?

This depends on the amount of liquidity in the specific pool. In case we use automatic routing (or other non-standard tokens), it becomes increasingly hard to calculate since there are multiply pools involved in one transaction.

An additional related thought: Can we determine in advance whether the leftover debt satisfies requirement imposed by chost (ie. minimum leftover auction debt amount)? Would you consider that as another error case for the popup?

Yes, if we decide to go with the input, the error case will be handled just like in the Bid with DAI flow: via error shown in the tooltip above input field.

---

Here is the version of the UI with 2D price tables.

• First option is with predefined proportions only
• Second option is with free input (the new proportion is then added to the table for comparison)

General idea of this proposal is to show the same table (and component) two times in case user wants to change bidding amount or the callee but with other values (or maybe even show them both, so the table is exactly the same). In both cases as suggested before, we will "probe" a few proportions per market: 10%, 25%, 50%, 75%(or max minus chost), 100%.

[LukSteib]

This depends on the amount of liquidity in the specific pool. In case we use automatic routing (or other non-standard tokens), it becomes increasingly hard to calculate since there are multiply pools involved in one transaction.

Ok got it. So we might end up in a situation where we are able to determine the price given a certain amount but the execution itself might fail due to missing liquidity? Or in other words: When determining the price we won't get an error yet in case of not enough liquidity?

Yes, if we decide to go with the input, the error case will be handled just like in the Bid with DAI flow: via error shown in the tooltip above input field.

I was rather trying to understand the how we would handle this chost related logic if we don't go with the input based based approach but predefined chunks only (would we then e.g. just show Unknown for the 25% chunk and provide the respective error in the tooltip on hover)

Here is the version of the UI with 2D price tables.

• Nit: I'd suggest to rename "amount to bid" to "amount to swap". Just to not confuse the user and make clear that there are no capital requirements
• as discussed at above I'd suggest to go with the table only for now and add input as a next step

[valiafetisov]

Or in other words: When determining the price we won't get an error yet in case of not enough liquidity?

We certainly will get the error (or empty price) in case there is no liquidity. My proposal is that instead of trying to determine the liquidity of a pool (or in any other way try to determine "best" or "maximum" swap amount), we instead probe predefined proportions to simplify our task, but still give user enough input on the those questions.

(would we then e.g. just show Unknown for the 25% chunk and provide the respective error in the tooltip on hover)

In case of the "probes" approach we don't care about why the exchange fail: network error, not enough liquidity or not tradable pairs, all should result in Unknown + tooltip with error message.

So it is up to us if we want to include max - chost as a special [additional] value. For example, we can add a probe that checks this value (which can be above or below 75% depending on the auction size)

as discussed at above I'd suggest to go with the table only for now and add input as a next step

👍

[LukSteib]

we instead probe predefined proportions to simplify our task, but still give user enough input on the those questions
In case of the "probes" approach we don't care about why the exchange fail: network error, not enough liquidity or not tradable pairs, all should result in Unknown + tooltip with error message.

Ok agree. Think we were a little talking past each other. Sounds good...

Ready to push to the next stage