# A Basic Agent-Based Model for Impact of Fees on AMM Performance

In a basic Automated Market Maker, the pool has only one input variable: the percentage fee charged per trade. The performance of the protocol rests on trading volume, which is influenced by slippage, which is decreased by liquidity in the pool.

## A Basic Model

If we knew how to predict the impact of fees on things like Liquidity Provision, we would already have the model. Instead, we can model the system as a game with many players and repeated turns.

To simplify things, we will assume two tokens: X and Y. Each has a price in USD, which changes according to a random walk.

Here are the types of players (agents):

- External Market. Determines changes in price for assets, which drives trades to and from AMMs.
- AMM Pools. Each pool will have different liquidity amounts and fees.
- Liquidity Providers, who give liquidity to pools.
- Traders, who trade with pools and with the external market.

Each turn (time step) consists of the following:
- the External Market updates the prices of Token X and Token Y
- based on current metrics, new Traders or Liquidity Providers may decide to enter the game
- based on current metrics, the Liquidity Providers decide whether to add liquidity or withdraw liquidity from a pool.
- based on current metrics, traders decide whether to trade with the market. If they decide to trade, they choose one of the existing pools based on how much of their trade will be lost due to slippage and fees.

A simulation consists of running a certain number of time steps, then tracking the variables of each agent. From these individual agent variables, we can track the relationships between single calculations and derive higher level metrics. Tracking this data over various runs with different parameter choices is the basis of our analysis.

The challenge is creating the decision functions/strategies for different kinds of agents. We could do this in an Agent-Based/Object-Oriented approach by inheriting from the classes. For instance, we might create a base ```Trader``` class that has the following variables:

- amt_Token_X
- amt_Token_Y
- amt_USD
- slippage_tolerance

and two actions

- decide_to_trade
- trade

At each round, the trader will look at the relevant options and execute ```decide_to_trade``` based on the situation of the market. The result of this will be the asset, amount, and pool for the trade.

However, there is no one universal trading strategy, we could create new classes with specific strategies. Not all of these would be needed for each analysis; this list is just to show some ideas.

- RandomTrader: simply chooses from a random distribution
- ArbitrageTrader: always makes arbitrage trades to profit based on USD
- TokenXTrader: tries to maximize their amount of Token X (is unconcerned with USD price)
- PriceProtectTrader: buys whenever the token is at a specific floor price, wants to protect
- PriceDestructiveTrader: tries to dump large quantities

We could allocate liquidity to each type of trader, allow them to interact according to their strategies, and track the relevant variables at each time step. Through repeated trials, we develop data that helps predict how fees would influence the system.