Confirm and fix Uniswap v2 clone fee structure

[miohtama]

• Check that we use correct LP fees (and exchange) fees in your backtesting and live calculations
• This probably needs to be added to the routing data information
• Currently we have 0.05% error in PancakeSwap fees if you look the live execution analysis here: https://tradingstrategy.ai/docs/programming/strategy-examples/examine-live-strategy.html
• This information is not directly available from the smart contracts, so we need to manually assembly this information based on execute trades and documentation of DEXes

Both entry and exit estimates are off by 0.05%. Because this is constant across all trades, it is unlikely to be natural slippage.

[AlexTheLion123]

@miohtama So I would change this method to accept exchange_slug or equivalent instead oflp_fees parameter, and then get the fee from the routing_data for the relevant exchange?

https://github.com/tradingstrategy-ai/trade-executor/blob/ec628553aa97e5842803fee4d296501ff2f733b4/tradeexecutor/state/state.py#L153-L173

[miohtama]

• No, it is better always to pass parameters explicitly. The state does not need to know about exchage-slug it needs to know about fees.
• The fee is not actually set anywhere, but it is part of buy/sell price estimation, as this differs from the midprice
• The fee is actually baked very deep into web3-ethereum-defi package when it estimates the amount of token it receives from buy/see. This is called here https://github.com/tradingstrategy-ai/trade-executor/blob/a85bedde1284bc0e553b70824bb655d8b733ddff/tradeexecutor/ethereum/uniswap_v2_live_pricing.py#L108
• Thus, when UniswapV2LivePricing is created, it should receive a parameter that it thinks is fee % in __init__
• However, UniswapV2LivePricing is created too early - without know of the universe or routing create_trade_execution_model - https://github.com/tradingstrategy-ai/trade-executor/blob/master/tradeexecutor/cli/init.py#L74

This is the factory

def uniswap_v2_live_pricing_factory(
        execution_model: ExecutionModel,
        universe: TradingStrategyUniverse,
        routing_model: UniswapV2SimpleRoutingModel) -> UniswapV2LivePricing:

    assert isinstance(universe, TradingStrategyUniverse)
    assert isinstance(execution_model, (UniswapV2ExecutionModelVersion0, UniswapV2ExecutionModel)), f"Execution model not compatible with this execution model. Received {execution_model}"
    assert isinstance(routing_model, UniswapV2SimpleRoutingModel), f"This pricing method only works with Uniswap routing model, we received {routing_model}"

    web3 = execution_model.web3
    return UniswapV2LivePricing(
        web3,
        universe.universe.pairs,
        routing_model)

To fix this properly

• We need to make the parameter first part of UniswapV2SimpleRoutingModel as it is created in routing_data.py where we can hardcode it per supporter router
• Then the fee is read from this model in uniswap_v2_live_pricing_factory and passed to UniswapV2LivePricing

How does this sound like?

[AlexTheLion123]

@miohtama See PR #136. One question, if routing_model is passed as a parameter to UniswapV2LivePricing, do we need to pass the fee as a parameter as well? Because we can get the fee from the routing_model