HI. I’m a newbie. I’ve been messing around with Pooling tokens and then staking them. So coin A pooled with coin B which gives me token C. When these transactions are auto imported I get three different transactions, a Sent A, sent B, and received C. With C being an unknown coin. What’s the best way to handle these transactions? My first thought was to create two manual trade transactions, one for Coin A to 50% of the C token, and then Coin B for the other 50% of the C token. However this does not work because I can only enter a manual transaction for supported coins, and since there are a ton of pool pairs I’m not sure how that would work.
That’s a very good question. Tax calculations for providing/removing liquidity present some challenges for various reasons:
Multiple tokens are part of the same transaction/trade (eg: token A + token B sold for token C)
There are thousands of different LP tokens with the same symbol/ticker that must be identified and considered separately when disposing of those tokens later (when removing liquidity).
Some pools don’t have linear collateral, meaning you might deposit 20% USDC and 80% ETH instead of 50-50 which is the most common
The short answer to your questions is that we don’t yet have full support for handling LP tokens for all the different platforms and protocols, but our developers are currently working on a big upgrade to this that we expect will be completed sometime next month.
Instead of importing Sent A + Sent B + Received C as you said, we will import two trade transactions this way assuming the collateral is 50-50:
Token A → Token C (50%)
Token B → Token C (50%)
Token C will be automatically identified from the contract address so that all LP tokens are tracked individually. When you later remove liquidity, you will see two trade transactions again
Token C (50%) → Token A
Token C (50%) → Token B
… where we will calculate the realized gain/loss for token C disposed of based on the current market rate for Token A + Token B.
In other words, this process should be 100% automatic and there is nothing for you to change/edit manually as long as the LP token is recognized from the contract address. We will need to add all contract addresses to our database for this to be identified automatically.
In case you see a Send + Send + Receive (like now) it means we have not yet added the contract address. If you see this, just send us a message and we will add the address to our database of LP tokens. Instead of deleting + reimporting all transactions, you will be able to merge the Send + Send + Receive into two Trade transactions with a few clicks.
We will publish several blog and help articles that explains this in much more detail as soon as the update is completed and goes live. Just wanted to give you a small “teaser” of what you can expect in the near future.
Don’t hesitate to reply back if you have any questions or suggestions related to this.
Just wanted to give you an update about the DeFi upgrade. All development is more or less completed now and the platform will be updated later this week after doing some internal testing first. We still have some work to do to add support for all the different protocols like Uniswap v2, Uniswap v3, SushiSwap, etc. We will prioritize the most popular protocols first and my best guess is that this will be completed by end of next week. All pools on Uniswap and SushiSwap will be supported from day 1, but I will double-check the pools you mentioned also.
Will post a new update when everything has been updated.
We rolled out this update a few weeks ago, and it is working fine for many protocols/liquidity pairs but not all at the moment. Uniswap v2 should be supported fairly well, but we need some more time to make it work 100% with all pairs on Uniswap v3 for example. SushiSwap should be completely supported.
Both protocols on Sushiswap you mentioned earlier were added a few weeks ago. You will need to reimport the transactions so that liquidity transactions can be identified automatically.
We will need to update the API integrations for ETH/BSC (and other EVM chains) in several iterations to make sure that we interpret and import all the data correctly. We have been working on this for several weeks already and we will release many new changes next week.
If you see that liquidity transactions are either not identified, OR imported wrong, just let us know here so we can look at it. It will be very helpful if you can include a screenshot and explain what is wrong/missing + the transaction hash.
Thanks, and let us know how it goes! We appreciate any feedback or comments
ok Thanks for the. How do I go back into my previous transactions and get these set up correctly? Or how do I add a manual LP transaction? Deleted and re-importing is not really an option, I have too many transactions and it would take too long to go back though and edit them correctly.
It’s easy to do manual transactions for LPs if you use the custom CSV method.
But like CryptoJames said, this may not be feasible if you have thousands of transactions. It depends on your excel skills then, I think.
In any case, you can reach out to us via live chat. I can look into the transaction blocks of any LP transactions and we should be able to add small updates that change the way they are imported.
Unfortunately, DeFi transactions are currently recorded in all kinds of different ways, without much logic to them. We import transactions in the most logical way we can, but since they don’t always contain contextual information, it’s not always possible to get it right.
If you can reach out to me with some screenshots, etc. I can work on writing instructions to the developers on how to import these. It’s a lot of nitpicking, but we do 2-3 of these updates every week, for every chain.
