# Thoughts about int price

Ok so to get a quote on USDC, WETH:

get_amount_out(1000 USDC) -> 1 WETH 

=> WETH/USDC = 1000 USDC / get_amount_out(1000) 
=> 1000 WETH/USDC ( WETH in terms of USDC!)


1 WETH -> get_amount_out() -> 1000 USDC 
=> WETH/USDC = 1 WETH / get_amount(1) 
=> 0.0001 USDC/WETH (USDC in terms of WETH!)

Ok so we get basicall this formula from this:

price(A, B) = amount_B / get_amount_out(amount_B)

We don't know anything about get_amount_out expect that it will return a positive or zero integer.

Especially it could be that `get_amount_out(amount_B) > amount_B`.

Let's look into this by using get_amount_in.

get_amount_in(1 WETH) -> 1000 USDC

=> WETH/USDC = get_amount_in(1 WETH, USDC) / 1 WETH

## Approaching problem in reverse...

Given a price: 0,333333, with a precision of 6 decimals
How can i easiest represent this price using integers?

The most naive solution is to do the following

nomin = 0,333333 * 1e6 = 333,333
denom = 1e6

So the price is represented by a two integers now. It should be sensible to keep denom constant over the lifetime of an application. In that case this becomes the only sensible way.

### Note
You might think that the price above is also representable by 1/3 but it is not if you only can work with integers. Which is the case here. In the end we want a single integer that represents the price.

Now this is not really our actual problem. Our problem is a bit more difficult
we have to find two numbers such that we can create such a price as above.

The constraints are the following:

1. denom should be fixed
2. nomin should be >= 1**precision
3. nomin > denom

Now as the denominator is fixed we want to ideally approach the problem such that we can set the denominator and find the nominator for us.

We already found this approach above. Let's look at the same example as above first. We want to find the WETH/USDC and USDC/WETH price of a pool. At the same fime we want to have as little price impact as possible. We will honour our fixed position prices though:

denom = 1e6
=> min USDC amount = 1.000000 USDC
# Note: get_amount_in here simulates a swap from USDC -> WETH
WETH/USDC = get_amount_in(1e6 WEI, token_in=USDC) / 1e6 WEI
=> 0 / 1e6 = 0

Ok too naive this did not work 1e6 WEI in USDC is not representable. So let's try for the inverse pair:

# Note: get_amount_in here simulates a swap from WETH -> USDC

USDC/WETH = get_amount_in(1e6 USDC, token_in=WETH) / 1e6 USDC
=> something

This likely works because I can represent the minimum USDC amount in WEI (ETH precision is much higher than USDCs)

Ok what about the other pair? Can we somehow query how much WEI I need to get 1e6 USDC without assuming symmetry over the prices? Not sure with two pairs we only have these 4 function invokations:

| Invokation | Direction |
| -------------------------------------- | ---------- |
| get_amount_in(USDC, token_in=WETH) | WETH->USDC |
| get_amount_in(WETH, token_in=USDC) | USDC->WETH |
| get_amount_out(WETH, token_out=USDC) | WETH->USDC |
| get_amount_out(USDC, token_out=WETH) | USDC-> WETH |

**No we can't! We have to use get_amount_in only in the nominator and amount_out only in the denominator. Else we assume symmetry over prices**

Ok coming back to the problematic issue from above:

We want to mantain a simulation from USDC -> WETH here to not assume symmetrical prices. So we have only one remaining option: `get_amount_out(x USDC, token_out=WETH)`

WETH/USDC = 1e6 USDC / get_amount_out(1e6, WETH)
=> 0 , because 1e6 USDC < get_amount_out(1e6, WETH)

So this doesn't work either? We will have to zero pad the nominator to have the same amount of decimals as WETH...

WETH/USDC = 1e6 USDC * 1e12 / get_amount_out(1e6, WETH)
=> something

Ok that should work. In that case can't we use the same trick for the initial problem? The problem here is we can't guarantee any precision anymore because the precision now depends on that the actual price is and what the decimals of the other token are.

### Note:
This trick here works because we multiply the nominator, and the multiplication does not happen to an function argument (In the unsuccessful case above we would need to increase the amount we pass to get_amount_in)

### Conclusion
Mantaining a fixed precision is not possible for two reasons:

- Pure mathematically it is not possible for tokens with different decimals and while not assuming symmetry of prices. There will always be a token that is not representable.
- The minimum amount for a fixed precision will vary highly in USD value e.g. 1e6 in WBTC are a few hundred dollars depending on market price and might have a significant price impact on the pool.

# What if we don't fix denom?

If we don't fix denom it means we also don't have a single precision. So
we are multiplying prices with different precisions. Maybe having a good enough precision is ok. But it opens up a few new questions:

- Should we be made aware of the precision we are operatin under?
- How to work with prices of different precisions?
- If we simply ignore what are the implications?

If we don't have a fixed denom the conditions reduce to:

1. nomin > denom
2. denom > 1**(min precision) (optional)

# What if we simply use a fixed USD value for defining prices?