Fix/swap exact out

[JanKuczma]

Because of rounding down when converting "rated_amount" to "token_amount", the method rated_swap_from(...) calculates amount_in smaller than needed in rated_swap_to(...) to produce the same amount_out. This behavior makes a rather insignificant loss to the protocol (1 smallest unit of "token_in") but still, these methods should be consistent.

Fix: Instead of adjusting the "rated_amount" by adding 1, adjust the "token_amount".

EDIT:

When the precision of "token_in" is larger than the precision of "token_out", the protocol loss is greater than 1, reaching the
token_in_precision / token_out_precision. E.g. when swapping dai(18 dec) to usdt(6 dec), the loss can reach 0.000001 dai

[deuszx]

When the precision of "token_in" is larger than the precision of "token_out", the protocol loss is greater than 1,

What does that mean? In what sense "protocol is at loss"? Where does this 1 token go (and who's paying it)?

[deuszx]

I can see the logic being changed but none of the tests needed adjustments? I remember some tests where the output differed from the reference Curve implementations.

[JanKuczma]

When the precision of "token_in" is larger than the precision of "token_out", the protocol loss is greater than 1,

What does that mean? In what sense "protocol is at loss"? Where does this 1 token go (and who's paying it)?

1 as the smallest indivisible unit of the token, in this case, the "token_in".

Before the change proposed in this PR:

• When a user swaps USDT -> USDC using exact_out(...) he has to pay 0.000001 of USDT less than when using exact_in(...) for the same amount out of USDC
• When a user swaps DAI -> USDT using exact_out(...) he has to pay up to 0.000001000000000000 of DAI less than when using exact_in(...) for the same amount of USDC

After this PR:

• When a user swaps USDT -> USDC using exact_out(...) he has to pay the same amount of USDT as when using exact_in(...) for the same amount out of USDC
• When a user swaps DAI -> USDT using exact_out(...) he may pay up to 0.000001000000000000 of DAI more than when using exact_in(...) so the protocol is not at loss

[JanKuczma]

I can see the logic being changed but none of the tests needed adjustments? I remember some tests where the output differed from the reference Curve implementations.

Curve and RefFi do not implement any equivalent method to our swap_exact_out(...) so no adjustments are needed.

[deuszx]

When the precision of "token_in" is larger than the precision of "token_out", the protocol loss is greater than 1,

What does that mean? In what sense "protocol is at loss"? Where does this 1 token go (and who's paying it)?

1 as the smallest indivisible unit of the token, in this case, the "token_in".

Before the change proposed in this PR:

• When a user swaps USDT -> USDC using exact_out(...) he has to pay 0.000001 of USDT less than when using exact_in(...) for the same amount out of USDC
• When a user swaps DAI -> USDT using exact_out(...) he has to pay up to 0.000001000000000000 of DAI less than when using exact_in(...) for the same amount of USDC

After this PR:

• When a user swaps USDT -> USDC using exact_out(...) he has to pay the same amount of USDT as when using exact_in(...) for the same amount out of USDC
• When a user swaps DAI -> USDT using exact_out(...) he may pay up to 0.000001000000000000 of DAI more than when using exact_in(...) so the protocol is not at loss

OK, got it. So I think wording of protocol loss is incorrect. Protocol (in this case the tokens in the pool) are not unnecessarily spent. It's the trader to has to pay more.