Tax reports based on fiat account transfers

[TimDaub]

Abstract

For persons dealing with Cryptocurrencies since their emergence, accounting for taxes is difficult. Given an almost certainly incomplete set of data, calculations may never become truly factual. Hence, they may not even make economical sense. In this issue, I want to discuss an alternative form of tax report for rotki.

Motivation

Meet Paul, an early adopter of cryptocurrencies. He mined and bought Bitcoin already in 2013 when Mt. Gox was still a thing. In fact, he lost a bunch of them when the exchange went down. Though he tried rescuing some through bitcoinbuilder, but even that didn't save him. The Bitcoins were gone, and so was his trading data.

Of course, Paul learned his lessons later and hence avoided several other pitfalls. Well, actually, he put some money on Bitfinex and participated in their weird margin money lending game thing. He also put some in a random ponzi he found on the web (the website is down since forever). And of course, Paul tried Monero, Zcash and many other shitcoins, using coin-swap exchanges like changelly and shapeshift.

In 2017, after all the coin trouble all his cryptocurrency dealings were such a mess! And so far there hadn't been any clear regulation in Germany. How to account for these weird perpetual swaps on Bitmex?? Anyways, he ended up liking the field and found a job as an Ethereum dev. From the getgo, Paul started building his own funny smart contracts and occasionally sending Ether or other ERC20s to them. In fact, while working at a company, he got lucky enough to sign a SAFTE contract that allowed him to claim some (back then non-existent) tokens a year later. Ahh, and by the way, through some weird web forum, Paul freelanced for some guy in Indonesia for a while. His bills paid in DOGE.

That's when DeFi started to hit...

Now, what's the point of outlining Paul's story? In my opinion, it highlights the problems of properly accounting gains and losses in crypto. With all these holes and lack of data in Paul's "trade" history, how should Paul ever be able to submit a factually correct report to a finance authority? Surely, he'd be able to submit a report based on his best effort. But he'd know even beforehand that it was 100% incorrect as for some parts of his history, data was simply 100% lost (e.g. Mt. Gox, participating in a DOGECOIN ponzi, etc.).

Specification

Given Paul's circumstances, I feel like just tracking the exchanges' trades and all DeFi data will never be sufficient for creating an actually correct tax report. However, Paul has a way to simplify his cryptocurrency dealings to at least get an overview and allow for a sanity check. For each year, Paul could just check:

• The amount of fiat moving into and out from exchanges he used
• The amount of credit in fiat he has for any exchanges he used

While it may still not allow Paul to submit his tax report a 100% correctly, he'd at least be able to safely tell his "unvirtualized" fiat gains per year, while leaving "the game of cryptocurrencies" and it's myriad of complexities to the side.

Hence the following idea for a rotki feature:

• Allow to query only query for exchange credit or fiat moving in and out of exchanges
• Present the user with this report on a yearly basis

If you have further questions, please let me know.

[LefterisJP]

Hey Tim thanks for taking the time to write this.

Allow to query only query for exchange credit or fiat moving in and out of exchanges

That's super easy to do. We already have the data. It's not displayed anywhere in the UI yet. But it will be there: https://github.com/rotki/rotki/issues/1085

So you mean just get the Deposits/withdrawals to/from an exchange. You can even get it from the csv export. Check the asset_movements csv export. It should contain all deposits/withdrawals. With it you can do your calculation.

But it would be incorrect in most jurisdictions. Each trade is a taxable action in almost every jurisdiction (with notable exceptions being Switzerland and the Netherlands). And crypto to crypto is taxable.

[TimDaub]

You can even get it from the csv export. Check the asset_movements csv export. It should contain all deposits/withdrawals. With it you can do your calculation.

that's awesome!

But it would be incorrect in most jurisdictions. Each trade is a taxable action in almost every jurisdiction (with notable exceptions being Switzerland and the Netherlands). And crypto to crypto is taxable.

That's right, but from talking with an accountant, they told me even though crypto to crypto is taxable, it's unclear how to calculate the profits/losses as:

• there's no one "correct" source of information about the price of the assets at a certain time (e.g. should I use coinmarketcap? Uniswap? What if there's an illiquid asset that e.g. doesn't even have a dedicated fiat/crypto pair yet). How do you argue for a certain source? E.g. Etherscan shows the value of Ether in USD. But how does it do that? Where's the data coming from? And why should I use it for my accounting?
• it's unclear how to pick a price (e.g. should you use a daily average of the course, or exact to the second etc.)
• there's manipulation within the price data. Examples are numerous: Korean washtrading, Mt. Gox willy and Markus Bot, Bitfinex price manipulations, etc.

Additionally, there are doubts about cryptos being a "commodity" (original in German: "Wirtschaftsgut"). Because say you had the option to buy a company that "owned 10 Bitcoin". How would you determine its value? Would you pay 100 000€ for it, in the hope that somehow magically someone would give you the private keys? When held in a non-custodial wallet, it's unclear how a transfer of the company (including its Bitcoins) is supposed to be handled legally and safely. After all, even after signing a contract that you now "own" the company, the previous owner could simply refuse to send the Bitcoins or state that the company lost their keys.

Anyways, that's just further motivation that the tax situation in Germany may progress into more positive directions in the future. And a bit of a warning that any calculation, at least from my perspective, may simply be incorrect in the future as the law is catching up with the crypto space. And I'd prefer purely giving them factual data (e.g. the amount of fiat that has moved in and out of a fiat bank account etc.)

I'll checkout the asset_movement csv for now and report back. Thanks!

[LefterisJP]

That's right, but from talking with an accountant, they told me even though crypto to crypto is taxable, it's unclear how to calculate the profits/losses as:

In the end you will do what you yourself want. Rotki is a tool. I am not an accountant so anything I say should not be taken as financial advice.

But I am also working with multiple accountants and got friends both in Germany and abroad who have done their taxes for crypto. The crypto to crypto being taxable and the 1 year rule of no taxes is considered pretty standard by now. Every accountant we have approached concurs on that and there is a lot written about it: https://www.winheller.com/en/banking-finance-and-insurance-law/bitcoin-trading/bitcoin-and-tax.html

there's no one "correct" source of information about the price of the assets at a certain time (e.g. should I use coinmarketcap? Uniswap? What if there's an illiquid asset that e.g. doesn't even have a dedicated fiat/crypto pair yet). How do you argue for a certain source? E.g. Etherscan shows the value of Ether in USD. But how does it do that? Where's the data coming from? And why should I use it for my accounting?

We use coingecko/cryptocompare. It's supposed to be "fair value" at the time. There is no central authority that sets the price for one day so this is the best one can do.

it's unclear how to pick a price (e.g. should you use a daily average of the course, or exact to the second etc.)

Just like with stocks, closest available price to the time of trade. With HFT can't pick average daily price.

there's manipulation within the price data. Examples are numerous: Korean washtrading, Mt. Gox willy and Markus Bot, Bitfinex price manipulations, etc.

That's speculation and irrelevant to the tax authority. They are just interested in taxing your gains as accurately as possible.

[TimDaub]

In the end you will do what you yourself want. Rotki is a tool. I am not an accountant so anything I say should not be taken as financial advice.

Absolutely. And that's why I think rotki is superior to comparable solutions.

But I am also working with multiple accountants and got friends both in Germany and abroad who have done their taxes for crypto. The crypto to crypto being taxable and the 1 year rule of no taxes is considered pretty standard by now. Every accountant we have approached concurs on that and there is a lot written about it: https://www.winheller.com/en/banking-finance-and-insurance-law/bitcoin-trading/bitcoin-and-tax.html

For Germany, I can recommend this article. Not sure if you're in touch with Bundesblock already, from what I know they even have a working group on this. They have an "Aktionspapier"

We use coingecko/cryptocompare.

Now that we wrote about it, I think we might want to state this in the docs under the "Creating a tax report" section too?

That's speculation and irrelevant to the tax authority.

At this point you're right. But it's being pursued.

• https://cointelegraph.com/news/bitfinex-market-manipulation-lawsuit-refiled-in-new-york-and-joined-by-second-case

[LefterisJP]

For Germany, I can recommend this article. Not sure if you're in touch with Bundesblock already, from what I know they even have a working group on this. They have an "Aktionspapier"

Yes I know most of the members. The registered office is where we used to work with the Ethereum foundation when we developed Ethereum. When something changes I will be the first to know, but for Germany right now this is how it is.

But the power of Rotki comes from configurability! It's up to the user to know/choose their settings and we should do the rest.

Now that we wrote about it, I think we might want to state this in the docs under the "Creating a tax report" section too?

Yeah that's a good idea. Note though. that it's not just for that. It's also for all current prices. We should have it somewhere prominent in the guide. Wonder where that would be?

[isidorosp]

Yeah that's a good idea. Note though. that it's not just for that. It's also for all current prices. We should have it somewhere prominent in the guide. Wonder where that would be?

Ideally we could also allow the user during the creation of the tax report (or in their settings) to determine where they would prefer that prices are sourcedfrom from, i.e.:

• 1 source (cryptocompare / coingecko / etc), or
• mixed (from any possible source based on a certain priority as not all sources have all assets) or
• also allow for an "average across sources".

Additionally when preparing the tax report in the export options it might not be a bad idea to also export the full data concerning asset prices (including fiat:fiat exchange rates) that we have pulled and include that in the download since sometimes tax authorities might ask for proof of where asset prices were taken from, e.g.

|  asset   |     price in USD  |     timestamp       |        price          |     source   |
---------------------------------------------------------------------------------------------

[TimDaub]

Additionally when preparing the tax report in the export options it might not be a bad idea to also export the full data concerning asset prices (including fiat:fiat exchange rates) that we have pulled and include that in the download since sometimes tax authorities might ask for proof of where asset prices were taken from, e.g.

Great point. IMO the csv file should allow an independent and simple verification of whatever rotki does internally. As such, the user can easily convince their tax accountant that rotki is indeed the software they should be using when declearing crypto taxes.

Yeah that's a good idea. Note though. that it's not just for that. It's also for all current prices. We should have it somewhere prominent in the guide. Wonder where that would be?

I'm currently reading Pieter Hintjens "Social Architecture". Just a shower thought, but how about creating a "specification" for rotki's tax accounting algorithm and then have implementations for it? Not only would this document all of an algorithm's intricate details, but it would also allow competition around making the fastest, most correct, simplest algorithm?

Additionally, it may also allow participation from potential contributors currently not represented in the tax accounting strategies of rotki (e.g. users from a special jurisdiction or a person like Paul etc.) by allowing them to create their own specs.

Edit: Sorry for turning this issue into a conversation. Feel free to move it elsewhere...

[LefterisJP]

@isidorosp can you move your suggestions into separate actionable issues with sufficient description?

As for when they would be prioritized we will see. We are very very pressed on resources right now and paid users focus on other requests.

Edit: Sorry for turning this issue into a conversation. Feel free to move it elsewhere...

@TimDaub no worries. But for conversations like this just join our discord. It's gonna be much easier and faster :smile: Github issues should be actionable feature requests/bugs or else

Just a shower thought, but how about creating a "specification" for rotki's tax accounting algorithm and then have implementations for it?

What do you mean? Different strategies? The idea is it's completely customizable and each strategy can be chosen by the accounting settings. e.g. FiFo/LiFo/average cost accounting etc. (currently only FiFo supported).

If by spec you mean documentation as you also know we got the docs and it's open source so pull requests are welcome :bowing_man:

Is it okay with you if I close this issue as it's mostly a conversation and not something actionable?

[TimDaub]

What do you mean? Different strategies? The idea is it's completely customizable and each strategy can be chosen by the accounting settings. e.g. FiFo/LiFo/average cost accounting etc. (currently only FiFo supported).

What I mean is similar to the EIP repository where you first have to outline in text what your program is doing and have it reviewed and agreed upon by the community before it gets merged as a community standard.

For current FiFo, an incomplete document would

• Outline the motivation for using FiFo (it's easily arguable in many jurisdictions as an accounting strategy)
• Describe the assumptions of the algorithm, e.g. that some states have a tax-free period
• Describe the algorithm, e.g. that FiFo means taking the first quantity of an asset bought and accounting that with the first quantity of an asset sold (but only under certain assumptions like a tax-free period)

A few points to motivate this tactic:

• Crypto may be a new asset class and hence new accounting strategies might be reasonable to use (e.g. identified-coin fifo). One could even imagine accounting strategies that are completely new, as Crypto may be vastly different from other asset classes
• Accounting algorithms tend to become complex and intransparent. Even worse when they're untested. Having a spec and potential competing algorithms may allow a set of winning algorithms to emerge
  • contributors may sell consulting or their algorithm as software to or through "the rotki platform"
  • algorithms become encapsulated software repositories that are more easily testable, verifiable and swappable
• Specifications become living documentation of algorithms
• Discussion about an algorithm's assumptions (e.g. which price oracle to use) can be done explicitly and openly
• etc.

Is it okay with you if I close this issue as it's mostly a conversation and not something actionable?

Fine with me

[LefterisJP]

What I mean is similar to the EIP repository where you first have to outline in text what your program is doing and have it reviewed and agreed upon by the community before it gets merged as a community standard.

Oh I see. Well that's interesting. I like the idea .. but we are too small at the moment for anything like that to be effective. Perhaps when our userbase and community grows to the point where this could be handled mostly by the community it would be the point to start this.

Could you move this suggestion into a separate issue so that we don't forget it? It would stay in the backlog for a while but it's not a bad idea.

Fine with me

Cool. Discord is here: https://discord.gg/aGCxHG7