Deterministic exact output functionality is lost

[matthewlilley]

There are two types of Trade which guarentee determisim in their own respects, exact input or exact output.

In my opinion a genius design decision in earlier versions of AMMs, however Trident only supports a deterministic input which is problematic for a number of reasons and common use cases of an AMM.

ExactIn - You have a specific input, the input is determistic, you will never use more input than you expect to recieve some margin (slippage) of output.

This is better understood in my mind as a seller looking to sell a specific amount of tokens, with margin on the output.

ExactOut - You have a specific output, the output is determistic, you will never get more output than you expect in return for some margin (slippage) of input.

This is better understood in my mind as a buyer looking to buy a specific amount of tokens, with margin on the input.

These are two distinct, or rather inverse functions, which have their own use cases. I believe the decision was originally made to include them in earlier versions of AMMs for a good reason, and belive we need to support or else we we lose the ability to cater for the latter case, ExactOut.

Examples:

• I want 1 PUNK BASIC
• I want 0.1 SAK3 to qualify for airdrop

You could list a substantial number of common cases like this which require exact out to be both determistic and reliable.

Solutions:

• Re-architecture of the single router into a generic, if it's desirable to use one router only.
• Multiple routers

And functionality added to support exactOut for each pool type.

Hacky solutions:

• Remove ability to select an output amount and only allow input amount. I don't think this is desirable and will frustrate users.
• Hacks to give appearance of exact out. This will be prone to two, probably common, unexpected results:
  1. Revert
  2. Spending more than you need, and getting more output than you want.

In both cases above this will require a substantially rethink and evaluation of the UI from top to bottom, supporting libraries, and other areas of the application outside of trident too. Timescale for this would be an unknown and substantial, and I believe results would not be great in terms of UX and predictability.

[wjmelements]

This is especially important for complex exchanges such as the concentrated liquidity pool, where it would be hard for another smart contract to calculate the output for a given input ahead of time.

[wjmelements]

The way that UniswapV3 supported exact output without adding methods or parameters was by making the amount parameter signed, such that negative amounts referred to an exact output while positive amounts referred to an exact input.

[matthewlilley]

This is especially important for complex exchanges such as the concentrated liquidity pool, where it would be hard for another smart contract to calculate the output for a given input ahead of time.

Agreed!

[matthewlilley]

The way that UniswapV3 supported exact output without adding methods or parameters was by making the amount parameter signed, such that negative amounts referred to an exact output while positive amounts referred to an exact input.

Interesting. @gasperbr