Per wallet/exchange Specific Identification (FIFO, LIFO, etc...) Resolution

[macanudo527]

At the moment, RP2 seems to calculate capital gains/losses across exchanges, but this is technically not accurate. I've read in many places that you can only do Specific Identification accounting per exchange/wallet.

Should we implement something that better tracks per exchange/wallet?

[eprbell]

That's interesting: I wasn't aware of that. According to the article it looks like FIFO is OK as it is: "The IRS FAQs don’t specifically address what method is required for FIFO, so a taxpayer can use either approach – pool all their accounts together or prepare separate FIFO calculations for each wallet or account."

However LIFO and HIFO are technically spec id and so they would be affected by this. We could do the following:

• change LIFO and HIFO to implement per-exchange/wallet queues;
• add a new per-exchange/wallet FIFO (while leaving the existing one), which would be a new spec id flavor.

[eprbell]

Here's the relevant text from the IRS FAQ cited in the Coindesk article: "Q40. How do I identify a specific unit of virtual currency? A40. You may identify a specific unit of virtual currency either by documenting the specific unit’s unique digital identifier such as a private key, public key, and address, or by records showing the transaction information for all units of a specific virtual currency, such as Bitcoin, held in a single account, wallet, or address. This information must show (1) the date and time each unit was acquired, (2) your basis and the fair market value of each unit at the time it was acquired, (3) the date and time each unit was sold, exchanged, or otherwise disposed of, and (4) the fair market value of each unit when sold, exchanged, or disposed of, and the amount of money or the value of property received for each unit."

I'm no tax expert but I'm not 100% sure the interpretation the Coindesk article gives is correct. What I read in A40 is that to identify a "unit" of a specific virtual currency a "unique digital identifier" is needed for all units held in a single account. It's not clear to me (from reading A40) that you can’t use Specific Identification with cost basis and sale proceeds for crypto from different wallets or exchanges.

Then again, I'm no CPA.

[macanudo527]

I think it's bit of a shorthand interpretation in order to make calculations easier. I think it is possible to sell across exchanges and wallets, but it is much more complex.

In my case,

I bought BTC on one exchange at $60k. Transfered stable coin to another exchange and bought BTC at $20k. Later sold that BTC that was bought at the lower basis cost of $20k for $30k for profit. Under HIFO this would be a loss because the highest amount would be sold first. But, the BTC I sold was not the $60k BTC, it was the $20k BTC. So, it should actually be a profit under the Specific Identification rule.

Now, of course, if I had transfered over the BTC and sold it on the other exchange, you can argue that it is the same BTC, but that is not the case in the above scenario.

So, you can track try to use specific id across multiple wallets/exchanges but you'd have to keep track of what lots were available on what wallets/exchanges at the time of sale. It is much easier to just do per exchange. Does that make sense?

[eprbell]

Not sure I follow completely. I don't see HIFO being harder with across-exchange (rather than per-exchange) accounting: If your case is:

• buy 1 BTC at 60k on exchange A
• buy 1 BTC at 20k on exchange B
• sell 1 BTC on exchange B

Using across-exchange HIFO, the sold BTC is the BTC that was bought at 60k (this is implemented today in RP2). Using per-exchange HIFO, the sold BTC would be the BTC that was bought at 20k. However, I don't see how A40 is prohibiting the first option and mandating the second one. I may be missing something in your explanation or in A40...

[macanudo527]

This is the use case I was trying to present:

• buy 1 BTC at 60k on exchange A
• transfer USDT (stable coin) to exchange B
• buy 1 BTC with the transfered USDT on exchange B for $20k
• sell 1 BTC on exchange B for $30k

The sold BTC on exchange B is NOT the same BTC bought at $60k. So, the basis cost should be $20k even if HIFO accounting is being used. Now, if you are using per exchange accounting, this is okay, everything will work smoothly, but if you are using the current RP2 accounting the calculation will be incorrect.

However, If you:

• buy 1 BTC at 60k on exchange A
• transfer 1 BTC to exchange B
• buy 1 BTC with USD on exchange B for $20k
• sell 1 BTC on exchange B for $30k

The basis cost under HIFO for the sold BTC would be $60k, and the current cross-exchange accounting would work. The trick is tracking the lot as it transfers between exchanges/wallets that makes the math more complicated. Basically, you have to make sure the specific lot is available on the specific exchange/wallet in order to use it for the basis cost. If it isn't you aren't selling that specific lot, you are selling another lot or lots bought at a different price on that particular exchange.

To put it another way you can only sell lots that are available on a particular exchange, you can't sell lots available on other exchanges, so the programming logic will have to track what lots are available where.

[eprbell]

OK, I understand your point now, however I'm still unsure how A40 matches the behavior you describe (perhaps that information is somewhere else in the IRS FAQ?). In your first scenario, couldn't I be selling the BTC that is still sitting in exchange A without moving it? A40 only says: "You may identify a specific unit of virtual currency either by documenting the specific unit’s unique digital identifier [...] or by records showing the transaction information for all units of a specific virtual currency [...] held in a single account, wallet, or address". It doesn't say that I need to pick the cost basis lot from the same exchange when selling. Just playing devil's advocate and trying to understand.

[macanudo527]

How can you sell a specific lot of BTC on exchange B when it is sitting on exchange A?

Are you saying you could falsify the sale as happening on exchange A? The specific id of the sold BTC on exchange B is of the BTC bought on exchange B. You have to be able to prove it is the same lot. How could you do that without transferring it?

You have to substantiate the basis cost by uniquely identifying the lot being sold. Q39 covers that.

[ydkdy]

first - HIFO is new to me so I appreciate discovering that here. thank you for that!

My opinion:

Given the situation: I want to choose specific units of crypto as a basis for a given transaction.
I have crypto in wallet A. I sell the same kind of crypto on exchange B without transferring the crypto in wallet A to exchange B first. Can I use the crypto in wallet A as the basis for the crypto I sold on exchange B? despite the fact that I still actually have the crypto in wallet A after the sale.

Q39 provides pretty good guidance on this. The answer is no because A39 uses the language "if you can specifically identify which unit or units of virtual currency are involved in the transaction". To me that means whatever unit of crypto is used as the basis is actually disposed of in the sale. And this is different than LIFO or FIFO where what is used for the basis may not (is likely not) the unit of crypto that was actually disposed of.

I think I'm agreeing with @macanudo527 's position.

[eprbell]

Thanks all for the replies: A39 helped me get on the same page. So, to summarize, the article says that FIFO can use universal pooling but spec id cannot: I guess this means RP2's FIFO implementation is OK as is, whereas LIFO and HIFO (which are spec id) have to be modified. Should we disable LIFO and HIFO until their implementation gets fixed?

[ydkdy]

I would not have thought LIFO was spec id.

[ydkdy]

Not sure how pertinent this is to our use case: https://www.irs.gov/pub/foia/lifo_records.pdf

But it does mention what records are necessary for LIFO.

[eprbell]

Perhaps I should rephrase: I meant that the article posted by @macanudo527 lists two cases:

• FIFO;
• spec id (not FIFO).

The current RP2 implementation of FIFO reflects what is described in the article. But the current implementations of LIFO and HIFO do not. So I was wondering if we should disable LIFO and HIFO, until their implementation is brough in line with the semantics described in the article.

[ydkdy]

Yes, I think disabling LIFO and HIFO makes sense.

And FWIW my last two comments where made without an understanding of q41/a41. Sorry about that.

[macanudo527]

I agree LIFO and HIFO will need to get reworked before they can be used.

[eprbell]

I just disabled LIFO and HIFO temporarily, until we have time to fix them as discussed in this thread.

[cactus71480]

However LIFO and HIFO are technically spec id and so they would be affected by this. We could do the following:

Hi @eprbell, do you have a source that clarifies what type of inventory valuation method LIFO is? I can't seem to find anything online that supports LIFO as a specific id valuation method. It seems to me that FIFO, LIFO, and Specific ID are considered separate valuation methods.

I checked with my CPA as well, and they believe LIFO is an acceptable valuation method.

[eprbell]

The source is the article at the top of this thread, which says: "The IRS takes a similar approach to cryptocurrency cost basis as traditional equities and allows two methods for calculating cost basis when disposing of virtual currency: First-in, First-Out (FIFO), Specific Identification". My interpretation of this is that anything that is not FIFO falls under spec id (including LIFO and HIFO). I think your CPA is right: LIFO and HIFO are definitely acceptable methods (but, according to the article, they fall under spec id). Anyway, this is just my interpretation and I'm not a tax professional so take it for what it's worth.

[eprbell]

I have one more question on this topic. Let's consider this scenario:

• buy 1 BTC at 20k on exchange A
• buy 1 BTC at 40k on exchange A
• transfer 1 BTC to exchange B
• sell 1 BTC at 60k on exchange B Proceeds are 60k, but what is the cost basis? In other words, how to choose which BTC gets transferred from A to B? Does the accounting method (LIFO, HIFO) also decide which lot gets transferred?

[Charles-Kaminski]

There does seem to be quite a bit of conflicting information. And it's hard to ignore that an exchange wants you to be stuck with them - so they have a vested interest in making the ambiguity the IRS has left in this space with an assertion that you need to keep your stuff on their exchange. One item that the exchange in question mentions is that across a wallet is fine. I have a piece of software that manages multiple private keys into a "wallet", so is that enough? Well, I also have software that manages across multiple groups of keys and multiple exchanges. To me that's a wallet. That's no different technically and so should it not suffice? I bet the exchange would disagree because it cuts into exchange's justifications for being stuck with them.

Has anyone found any documents from the IRS that everyone seems to be referencing? I think identifying all the relevant IRS regs is probably the next step.

I'd also be curious to know if the IRS has anything written on commodities, which the SEC has indicated that Bitcoin is a commodity.

[eprbell]

Links to IRS documents are in the discussion above: see the IRS FAQ, in particular Q39 and Q40.

[ydkdy]

On the question posted April 2, my opinion is one may choose either the 20k cost or the 40k cost as the basis if doing spec id. It's clear that the 1 BTC transferred was previously in the wallet at exchange A. Once the basis is traced that far, I think any transaction in that account is fair, as long as the documentation requirements are met. That's how I would interpret Q40 in this context.

Is software that one uses personally that "manages across multiple groups of keys and multiple exchanges" a single wallet for the purposes of determining basis? I think that by itself is not enough. My opinion is there needs to be some verifiable record (i.e. on a blockchain or records from a third party exchange) that documents the movement of the currency as described in Q40 in order to do spec id across those things.

[jayr0d]

I came to the conclusion that HIFO and LIFO should be re-enabled after reading the material cited above. I found an article that supports my claim. IMO the best tax strategy is one that minimizes gains and maximizes losses, therefore deferring tax burden. With an asset like Bitcoin, where it is typically up and to the right, something like HIFO is much better than FIFO or LIFO. Yes, a more specific algorithm could be applied, but let's not over complicate things, and once you pick a method you really need to stick to it. I came to this project specifically looking for HIFO support. I think if you don't re-enable it, people will look elsewhere if they cannot figure out how to re-enable it themselves. In my particular case, the capital gains under FIFO are twice that of HIFO.

https://www.forbes.com/sites/shehanchandrasekera/2020/09/17/what-crypto-taxpayers-need-to-know-about-fifo-lifo-hifo-specific-id/?sh=18eebf8c36aa

Cost Basis Tracking: Universal Application Vs. Per Wallet Application

A question that arises when applying tax lot ID methods is how exactly they should be applied to crypto assets. The Universal application means that there is one queue for each coin across every wallet and exchange you have and the tax lot ID method is applied universally. Per wallet application means that you apply your desired tax lot ID method for each wallet.

The answer to how tax lot ID method should be applied can be inferred by logic. If you can specifically identify the units you are deemed to be selling by meeting all the four criteria mentioned above, you could apply any tax lot ID method of your choice universally or per wallet basis. In essence, once the Specific ID method is achieved, boundaries set by wallets, exchanges or coins do not matter; you can pick your coin from anywhere.

And the four criteria are:

(1) the date and time each unit was acquired (2) your basis and the fair market value of each unit at the time it was acquired (3) the date and time each unit was sold, exchanged, or otherwise disposed of (4) the fair market value of each unit when sold, exchanged, or disposed of, and the amount of money or the value of property received for each unit.

This is exactly what RP2 does, just for universal application only. If anything, you could add a warning or a note to the output files that Universal Application is used, not Per Wallet Application.

[eprbell]

@jayr0d, thanks a lot for the article: I think it makes a pretty compelling case. I like it for the following reasons:

• it gives a name to the problem (universal application vs per-wallet application) and offers a clear interpretation;
• it's written by the head of tax strategy at Cointracker, who hopefully meets one of the requests in this thread: that the solution would be given by a CPA or tax expert.

In light of Shehan's interpretation I'm leaning toward re-enabling HIFO and LIFO (with universal application). @macanudo527 and others on this thread: any concerns?

[macanudo527]

I don't see any issues. This looks like a green light to me.

[jayr0d]

CoinTracker, that reminds me...they support both methods, but Per Wallet is preferred and the default. This is to future-proof potential changes where Per Wallet is potentially mandated.

Sources: https://support.cointracker.io/hc/en-us/articles/12407462337937-Cost-Basis-Tracking https://www.cointracker.io/blog/irs-proposes-new-crypto-tax-rules

So while Universal Application might be OK now, it might not be in the future. It might be best to at least warn the user that HIFO and LIFO use Universal Application and not Per Wallet.

[eprbell]

LIFO and HIFO have been reintroduced (see 1add78d). I clarified in the documentation and in the code that this implementation is using Universal Application. Doing Per-wallet Application is doable too, but non-trivial.

[eprbell]

Closing the issue. Please reopen if you have more concerns or questions.