Generally speaking, if your system gives the users different terms under different scenarios, then you need to remember that a user can issue a flash-load attack on it.

For example, if your pool gives the users a better conversion-rate when the pool is deeper (higher reserve balances), then a user can attack it by executing atomically:

• Add liquidity and increase the pool's depth
• Make a conversion from one reserve to another
• Remove liquidity and decrease the pool's depth

This sort of attack can gradually (or even abruptly) drain out your pool.

Generally speaking, if your system gives the users different terms under different scenarios, then you need to remember that a user can issue a flash-load attack on it.

For example, if your pool gives the users a better conversion-rate when the pool is deeper (higher reserve balances), then a user can attack it by executing atomically:

• Add liquidity and increase the pool's depth
• Make a conversion from one reserve to another
• Remove liquidity and decrease the pool's depth

This sort of attack can gradually (or even abruptly) drain out your pool.

UPDATE:

The example above is feasible only if the user is guaranteed to receive in the last step the same liquidity (reserve amounts) invested in the first step, regardless of the state (reserve balances) of the pool.

This restriction is not guaranteed in most pools currently deployed, making the illustrated flash-loan attack useless under these circumstances.