Mining and Value Basis

[grays0nsteding]

Issue: Per IRS Notice 2014-21 - “When a taxpayer successfully “mines” virtual currency, the fair market value of the virtual currency as of the date of receipt is included in gross income.”

Helium mining rewards are deposited many times throughout the day. The fair market value of a helium token can be volatile and vary throughout the day (as much as 30% apparently).

Questions:

1. How granular do we need to be with the pricing data and rewards? The notice uses the term "date", but should we consider the varying value throughout the day?
2. If going by date only, do you average for the day? Use the closing price?
3. Mining rewards can be really small. I had one this morning for 0.00033716 HNT. Price was $1.75 per token on Coikgecko or a value of $0.00059003 USD. Consider your IRS tax form that typically rounds to the nearest whole dollar. Do we have a threshold for establishing a single "lot" of Helium tokens?
4. Would data requirements change depending on your method of cost-basis accounting (SpecID, FIFO, etc)? Need to identify the "worst-case" and generate that data, then work back from there for the other cost-basis methods.

[Greg15]

Granularity: There are several tax decisions that are dependent on the date and/or datetime of the transaction. Each can be impacted by the granularity decision.

1. Which year to report the mined HNT as income, and what value to assign it.
2. The determination of long term capital gain vs short term capital gain is dependent on the date of acquisition and the date it is sold.
3. On its surface, the tracking requirement to use SpecID requires date AND time (the airdrop/hardfork rules also mention date AND time). See A39 at this URL for SpecID information: https://www.irs.gov/individuals/international-taxpayers/frequently-asked-questions-on-virtual-currency-transactions

Some inputs to the decision:

1. Notice 2014.21 repeatedly uses just "date".
2. The rules for SpecID say you either need to identify the specific unit's unique digital identifier, OR by records showing the transaction info for ALL units of a specific virtual currency, held in a single account, wallet or address. That info 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.
3. A8 in the Notice says: "the fair market value of the virtual currency is determined by converting the virtual currency into U.S. dollars (or into another real currency which in turn can be converted into U.S. dollars) at the exchange rate, in a reasonable manner that is consistently applied".

Some Analysis: Crypto is 24x7x365. Although the notice says you can determine fair market value in a reasonable manner that is consistently applied, it says nothing about determining the date. Assume you are in California, Given the 24x7 nature of crypto, you could receive mined reward at 11:50pm Dec 31. Perhaps the timestamp on the record is in UTC, The transaction might look like it was in Jan 1, which is a different tax year for those on a calendar tax year, compared to when the miner received it local time. I suggest that this be approached by using a "reasonable manner consistently applied" approach, even though it's not explicitly allowed. Maximum flexibility is given to each person if they can specify their offset to the timestamp of the records to determine "local date", but I recognize that's probably overkill. There seem to be defined cutoffs for 'end of day' time for crypto quotes to support daily/weekly/etc charts and historical quotes in the industry, so I suggest standardizing on end-of-day based on that (probably UTC?). A double check might be to see how date reporting is typically handled for Forex trades, since Forex is basically open 24x5, Their might be existing tax guidance for that situation.

The determination of date for determining long-term vs short-term capital gains is the same conversation. I suggest applying the same "reasonable manner consistently applied."

That leaves SpecID (Specific Identification). The date AND time of acquiring and disposing is required. So it appears both date AND time of acquisition and disposal is required. Also required is the basis and proceeds. Also required is the fair market value at the time of acquiring, and the fair market value when disposed. But the fair market value when acquired and disposed can be determined "in a reasonable manner that is consistently applied".

So, my current interpretation is we need the date AND time of the actual transaction, but we are free to use any reasonable manner consistently applied to determine the fair market value at that time (which will also determine the basis of mined tokens). The reasonable manner to grab the fair market value could be based on closing price. I would propose to use the most readily available data point, especially one that would be available for historical lookup, such as closing price, which is what I believe shows in charts (even though "closing price" is an arbitrary time in a market that never closes).

Threshold/Rounding issue: since the SpecID method requires date AND time of each acquisition and disposal, if we take that literally, then we must keep each transaction separate to meet the requirements to use the specific identification method, and we cannot arbitrarily group them into lots before reporting. It's possible that a miner ends up with a basis of zero for all those micro-transactions when they are disposed (and each disposal potentially must be reported individually). However, I suspect the fractional values probably have to be added together before rounding when reporting mining income for the year regardless of how they're reported for gain/loss upon disposal. Maybe include 2 values - the full fractionalized value, and the rounded value. U.S. individuals normally have the ability to round to the dollar OR penny in their tax forms (must apply consistently). In some forms/worksheets, taxpayers are instructed to use pennies to add up multiple records, and only then round the sum to dollar if using dollar-rounding. Therefore, if providing a rounded value as well as a full fractional value, I would propose rounding to penny in the output, and letting the individual further round to dollar in their tax forms when appropriate. Because individuals can always pull data into a spreadsheet and use a macro to round to the nearest penny, the additional penny-rounded value isn't required, but would be nice.

As an intellectual curiosity extreme edge case, consider the case of someone who only burns their HNT for DC (or only sells their HNT to people that are buying to burn it for small amounts of DC), and only burns/sells in small lots (lets say 100 DC at a time), Rounding each transaction would always show zero gain. potentially millions of sales for less than half a penny, each with no "reportable" gain (after rounding each one). In a fiat world, it is harder to receive a fraction of a penny, but it would be easier to receive a fraction of a penny with a stablecoin. Is there any portion of the existing financial world that anyone can point to where this micro-value issue comes up? Each fractional mining reward's value probably has to be added up to report as income when mined, but generally a US taxpayer needs ability to report each disposal separately for gain/loss reporting. As an intellectual curiosity, this is an extreme edge case, so I don't think it should be given undue weight in any solution.

Much of the above is impacted by the use of many epochs per day, which can resulted in lots of small rewards (the small part is especially for lone-wolves). The easiest way to simplify most of it would be for the mining rewards to only be credited to wallets once a day. The number of transactions would go WAY down, and the work to track them would go WAY down. I'm new to the Helium space. is there a realistic way to get a corresponding change from Helium to implement a change where the amount of mining reward is calculated each epoch (as it does now), but the crediting to the wallets only happens once a day?

Having said all of the above, I could also see that the IRS may very well accept the position from a taxpayer that chose to roll it all up to daily summary, and listed the daily close as the datetime, as an approximation of the datetime needed for SpecID.

Which leads to the other way to simplify this all; find evidence that the IRS will accept a daily rollup from the underlying transaction records that the taxpayer must keep, despite them clearly staring date and time in the SpecID and hardfork/airdrop rules. Since I don't think such evidence will be found, given the explicit reference to date and time in the IRS info about SpecID, then I think a report on the underlying transaction data should have a datetime stamp (using UTC) for every transaction. If any roll up to ease actual reporting on the tax forms is allowed/done, the taxpayer would still have the underlying transactional data required.