How to account for DAI loans in Compound or Maker

[Rikard_Johansson]

I have used services like defisaver.com and instadapp. In both cases some of the trades are in a smart wallet, in some cases in the account and I have imported positions from account to smart wallet account. On top of that I have used the flash loan possibilities to switch between protocols or to leverage a position.

Now - when it comes to tax this is a nightmare. One transaction can be 20 transactions and Koinly does not understand what is what and some transactions are imported, others not.

1. How should a Maker CDP position be accounted for in Koinly? Do i use send to pool for the ETH only? How do I handle the DAI loan? I seem to end up with a position without debt if I send the ETH to pool and juste leave the DAI transactions as is. The value of the position get totally wrong also since there is no debt.

2. How do I account for a flash loan leverage transaction (like Boost in Defisaver.com)? Koinly records a number of transactions - usually not all in the transaction. Should I delete all transactions (could be 5-10 of them) in Koinly and just enter “the proper” transaction? Usually what happens is you borrow DAI, convert that into ETH and add ETH to the CDP. Koinly usually miss this and records ETH that just appear from somewhere. Should I send that ETH to pool or tag it receive from pool or what is correct? The effect is the CDP grows in ETH and in DAI debt.

3. How do I handle loans in AAVE and Compound? Should they be tagged “received from pool” or not?

I also sometimes get an error “no purchase recorded for DAI”. How can I avoid that? It occurs because I sell DIE that I have borrowed and never purchased.

Thanks.

[Don]

Wonder those questions too. Would like to hear about a projected time estimation for the support of it.

My idea was to create a new wallet “CDP Smart Wallet” manually and do everything in there by hand to prevent mixing of the automatic things. Not sure how to proceed, because if they implement it, i need to seperate the double entries and delete them. Or it recognized the nearly perfect same time / same amount transactions.

[Jimbo]

Really hope they come and answer this soon, would gladly pay more money for a higher tier with access to DeFi tracking solutions.

[BBryant]

+1 on the hope that someone from Koinly chimes in soon. Consider the following simple scenario:

• ETH is trading at $500/ETH.

• I deposit $1,000 USD at an exchange, and buy 1,000 DAI (basis in the DAI: $1,000). I transfer the 1,000 DAI to my hardware wallet and lend it out on Compound. No tax impact.

• I borrow 1 ETH from Compound against my DAI collateral. The Koinly system shows this as a “Deposit” to my wallet, though I think this is more of a “withdrawal” in a sense since I’m borrowing against my own collateral – perhaps this is the source of my confusion? Regardless, using Koinly as it functions now, this creates a position of 1 ETH with a cost basis of $500. While my basis in ETH changes, this isn’t a taxable event.

• I swap the borrowed ETH for 500 DAI. For tax purposes, this is effectively a sale of my 1 ETH for $500 (given basis was $500, no tax impact), and then a purchase of 500 DAI for $500, which would increase my DAI position.

• My understanding is that at this point, the way Koinly operates, my tax position is 1,500 DAI with a cost basis of $1,500, and 0 ETH.

• ETH market price moves to $750/ETH and I decide to close out my short position.

• I swap 750 of my 1,500 DAI for 1 ETH. For tax purposes, this is a sale of 750 DAI for $750 (no tax impact given basis remains $1/DAI), followed by a purchase of 1 ETH for $750.

• At this point, for tax purposes, I have 750 DAI with a basis of $750, and 1 ETH with a basis of $750.

• I repay the 1 ETH loan with my 1 ETH. This shows as a “withdrawal” in Koinly. $0 in tax liability because my basis in the 1 ETH matches current market price ($750).

• I now only have 750 DAI, with a basis of $750.

• I withdraw the remaining 750 DAI back to an exchange (we’ll pretend Compound didn’t pay interest for simplicity), sell it for USD, and withdraw to my bank account.

So, in essence, even though I put in $1,000, I only end up with $750. Yet, I don’t capture the $250 loss anywhere for tax purposes, as far as I can tell. My expectation here is that we would capture the overall loss from the trade as a whole, but perhaps there’s something that I’m not understanding.

[Ryan]

The guidance doesn’t make sense. According to the guidance, repaying a crypto loan is marked as sell and is a taxable event.

Let’s look at a hypothetical example. If I borrowed a bitcoin at $5k and repaid the loan when bitcoin is at $50k, I would owe tax on a $45k profit that I didn’t realize. Alternatively, if I borrowed at $50k and repaid at $5k, I could harvest at $45k loss. The latter being a strategy to eliminate tax.

Repaying a crypto loan should not be a taxable event.

[j_G1]

Can anyone from Koinly chime in here? This is the exact issue i’m dealing with.

[Jangle]

Having similar issue. Also, I can add a manual transaction to account for lending income, but I payback my loan any additional debt I have accumulated I am getting a “Missing purchase history” error for. The p purchase history is not there because for the debt tokens being payed back because they were generated in a dApp. Any way to add the interest expense the same way you would interest income?

[forest]

I also have a Maker leverage position I will need to look at soon. Plus interest payments from the Maker DSR. Some of the scenarios described here are enough to make any accountant (and HMRC) break out into a cold sweat. I suppose we need things either to “just work” for such complex cases, or have very good control over setting these scenarios up manually, at least with a close approximation as a best endeavour. This needs good documentation and clarity on what Koinly can and can not do currently. The silly thing is for me, the tax tail is starting to wag the crypto dog; i.e. I am reluctant to do any crypto activities that I can’t then report properly. Would be nice to hear from Koinly, we all need to work through these things together.

[LDJ]

This is still what I primarily have problems with. I simply don’t know how to handle these kind of loans or if Koinly is even capable of handling it.

[Safi]

This is a significant issue for me too, and my main reservation against purchasing a tax plan through Koinly, even after spending many hours sunk into fixing up imported transactions and doing all I can to give Koinly the best chance of getting it right.

Dai and other debts, whether they’re in the form of new Dai minted on Maker from a CDP, loans from Compound/AAVE or a result of margin trades on exchanges all show the “No purchase recorded” error and mess up the cost basis calculation for everything that follows.

[ender]

Any news about this issue? it will be nice to know if koinly have any plans to introduce it some time this year

[obediahc]

In case you haven’t found it yet. This article provides guidance.
https://help.koinly.io/en/articles/4928658-loans-repayments-collateral-cdp

[Don]

I have found a solution on reddit (ethfinance). This approach does work on borrowed DAI or coins that are bought with it. No idea however what happens when you borrow directly BTC, better dont touch it - but likely its the same if you are already in the mess.

The trick is to think of a CDP just as annother wallet. Now this is from the relative perspective of this new wallet CDP123. So you need to use the manual Excel sheet importer, the generic one. Use one sheet for each CDP. I recommand to alwayse use the transaction TX# in the TX column as it will help Koinly with the matching. Its a lot of work as you need to compile all the data manually from sites like DefiExplore. And remeber Koinly used UTC timezone (just use Etherscan which uses it too). If you do it like this the regular wallet and the CDP will match (send=>receive and the other way). One of the very best features of Koinly and nuanced - most fuck it up complety with their heuristic.

• Now the add collateral / remove collateral is a deposit / transfer to the main wallet. Just put it in the right column as received / send. Dont put any fees in it as it will auto-match from the (fully supported) main wallet side.

• A loan is also just a deposit. Put the amount of DAI in the column received. This is not taxable but its a buy operation. In case DAI value would become unstable it would matter, otherwise it won’t, unless your local currency is not Dollar. Then i am not sure, because currency trading is regulary not taxed (afaik) but coins are always taxed. The currency swinging it will be anyway really small.

• A loan repay is a send. Put the amount of DAI in the column send. Koinly will calculate the gain which should be close to zero as DAI shouldnt swing much. Dollar to other currencies however could (10% for example).

• For a leveraged buy combine the steps deposit dai (out of thin air) + buy eth as regular deposit. For a leveraged sell the other way round. For the buy/sell I saw that for x DAI you get y tokens and used that. The input (receive) and output (send) from this CDP wallet will be auto-matched.

• Hence leveraged means its two steps: generate DAI then buy, or the other case: first sell then send DAI away. Its super confusing in Excel. Jut put two lines for each operation.

The largest amount of works is collecting the data. The Excel is then quite fast after the first few lines once you understand the principles. But also that is least some hours of work. The quick and dirty way is to just hack all sell operations directly manually in your wallet. Its good enough but a mess, this way is quite clean and understandable as its contained in a wallet.

Now if Koinly starts to supports it in the future maybe, well it will be fun because they might use different decimals, fees or a slightly different approach so the reports will be off and the imported data will be double. Please shoot me. (Already had this nightmare mess when suddenly out of nowhere everything was off because they supported LP tokens and didnt before - without warning of new transaction detections)

Hope this helps you guys!