Special accounting for LP contracts

[yabirgb]

Problem description

Currently we don't make a special handling for pools where an asset is deposited and a token representing a participation in the pool is given to the user. What we do is consider them like a swap when the protocol is known like the case of curve pools or yearn vaults.

This generates issues like not having a clear representation of the profit/loss made after a withdrawal from such pools and the users actually having to go and match them.

Solution

We want to improve the accounting of such contracts and have a clearer vision of what is happening on such events. To achieve this we base the improvement on the changes made in #5689 where we introduce the contract field.

Using this contract we can filter the events that happened withing a specific contract and this allows us to track the profits made in a certain pool.

Since for example curve pools allow to deposit one or multiple tokens and withdraw in one or multiple tokens too we would need to track the PnL at least initially using the profit currency and not the underlying tokens.

Specification

1. We will allow users when viewing EVM transactions to mark a certain deposit to a contract, as a pool deposit thus also marking the target evm address as 'pool' (or a better name) meaning that interaction with that exchanging tokens are subject to this new accounting method. Also the curve pool, yearn vaults and others that we already know will be used here.
2. We will introduce a new TxAccountingTreatment that will handle the special case of pool contracts. This new setting will search the related events using the event identifier and if we are depositing it will track the deposits made to the contract and when withdrawing (i.e. returning the wrapping token) it will track the PnL accrued in the pool. As we said this should be calculated using the profit currency

Future improvements

• This will allow to track performance in certain pools and this can be used to create statistics. Right now this change will be tight to the accounting part so is out of the scope for this issue.
• Contracts like curve gauges are special cases since they use virtual balances and don't emit a LP token balance. Performance of those would be scope for another issue.