Various date and time formats apply across many countries and regions. For many exchanges and blockchains a standard ISO 8601 standard format is used to facilitate easy interpretation. While many exchange APIs use such standard, dates found in CSV file imports do not always supply standard date and time formats. Exchanges may alter the date and time format to conform with either the region of the exchange or the region of the user’s browser that was used to download the exchange data file.

To solve this problem, CHAINOMETRY provides an option to alter the time zone for the import file process (thereby altering the region) as well as another option to provide extra processing to determine the date format. In these cases, it is up to the user to determine the correct time zone for their exchange file. Failure to do so will result in incorrect date and time data recorded for transactions that were downloaded on the exchange file. This will in turn result in incorrect validations when determining the cost basis of the asset and may result in Unfound Balances on the ledger.

Exchange date and time zones may differ depending on the format of data obtained from the exchange. For most exchanges and blockchains, universal time UTC is supplied for all date stamps relating to trades, swaps, deposits, withdrawals, and other types of transactions. This also is often the case with exchange API imports, however, for file imports, exchanges may alter the date/ time zone to conform with either the region of the exchange or the region of the user’s browser that was used to download the exchange data file.

CHAINOMETRY does it’s best to accommodate these time zone differences by: firstly, accommodating exchanges that apply time zones other than UTC; and secondly by allowing the user to select the correct time zone when uploading data from an exchange file to CHAINOMETRY. In these cases, it is up to the user to determine the correct time zone for their exchange file. Failure to do so will result in incorrect date/time data recorded for transactions that were downloaded on the exchange file. This will in turn result in incorrect validations when determining the cost basis of the asset and may result in Unfound Balances on the ledger.

CHAINOMETRY makes use of third-party services to download and store market data valuations for many trading pairs. Market data is used to value assets when determining the cost basis for the asset. This is especially the case where one cryptocurrency is traded for another cryptocurrency but originally purchased with a different cryptocurrency. For popular trading pairs, CHAINOMETRY has access to price data in minute intervals (minute-to-minute price data). This ensures the most accurate valuation of assets.

For less popular trading pairs and asset, minute interval price data may not be available; in these cases, valuations may be determined at a time or date that is further away from the transaction date. The maximum period away from the transaction date is currently 30 days, however this may change in the future. If the price cannot be determined in minimum time frame an Unfound Balance entry will be added and the user will be able to view the details of the exception. The user can then edit the problem transaction and specify alternative equivalent currency details to correct the problem. An easy way to do this would be to obtain the unit value of the asset in USD and modify unit price and currency to USD.

Each user account on the CHAINOMETRY system is linked to a Tax Region which is configured by the user. This region allows for certain specific tax requirements to be applied to the account such as the inventory valuation system and determining the secondary currency used for realisations (see below).

Trading Accounts are created by users on the CHAINOMETRY system and are linked to either an exchange or a crypto wallet. An exchange is a public platform for facilitating transactions across many different cryptocurrency assets. Users often have accounts with various exchanges and sometimes multiple accounts with the same exchange (sub accounts). Trading Accounts, as defined by CHAINOMETRY, is a discrete account or sub account with an exchange. There is a one-to-one relationship between an exchange account (or sub account) and a Trading Account.

Trading Accounts linked to a crypto wallet is based on the blockchain of that wallet. The blockchain may support only one cryptocurrency as in the case of Bitcoin or may support multiple cryptocurrencies (also known as tokens) as in the case of Ethereum. There is a one-to-one relationship between a blockchain and a Trading Account.

A Trading Account cannot be linked to both an exchange and a blockchain.

All tax based calculations on the CHAINOMETRY system are separated and contained within each Trading Account. For example, a purchase from one trading account cannot be used to determine the cost basis for the sale of the asset in another Trading Account in the CHAINOMETRY system. This coincides with the normal limitations of exchange accounts and blockchain wallets. Universally, all trading on exchange accounts occurs within the same account and data exports, whether they be via file downloads or API connections, apply only to a single account.

Similarly, blockchain wallets (or addresses) apply to a single blockchain as well as transactions relating to exchanges or swaps. It is possible, however, for users to own several addresses on the same blockchain and users are encouraged to add all their addresses for a blockchain to their Trading Account. A Trading Account can accommodate an unlimited number of user addresses for a blockchain as well as addresses linked to other assets on the same blockchain.

Realisations are calculated separately for each Trading Account independently of any other Trading Account. Depending on the tax report, each Trading Account’s realisations are added together to derive the total profit or loss for each organisational unit on the CHAINOMETRY tax reporting system.

A secondary currency is assigned to each trading account and allows for the conversion of the primary currency to the local currency of the tax region selected by the user. An exchanges’ primary currency may be USDT (Tether) however the users tax region may be in Canada. For this user their secondary currency will be in Canadian Dollars.

Realisations Calculated in the Secondary Currency

Secondary currency conversions are calculated by converting the acquired unit price (previously converted to the primary currency) to the local currency at the time of acquisition and converting the sale or release unit price to the local currency at the time of sale or release.

The asset balance must be present in the ledger before the asset can be released otherwise an Unfound Balance exception with be recorded. For this reason, the uniformity of date time zones must be coordinated across all exchange platform data.

An Unfound Balance will result when there is no balance available for the asset which will result in a missing realisation for the asset when it is released (either by sale, withdrawal or it’s use as a currency to buy another asset). This will impact the profit and lost statements for the trading account and lead to incorrect final profit or loss balances. All unfound balance transactions must be resolved before an accurate profit or loss total balance can be determined.

Asset Balances as Deposits

A deposit of an asset will be used as the asset balance when that asset is later released (see below). Where the type of asset is a cryptocurrency asset, the cost basis for the deposited asset must be determined. There are two ways a cost basis for a deposited asset is determined:

Asset Balances as a Result of a Purchase

Purchasing an asset or trading one asset for another will result in an increase in the balance for the purchased asset or the destination asset (the destination asset can be referred to as the currency). This balance can then be used for later sales or trades.

Asset Balances as a Result of a Sale

Since a sell type transaction on an exchange can be from one digital currency to another, this will increase the balance of the digital asset used as the currency for the transaction.

Releasing an Asset

Cost basis for Cryptocurrency Fees

When an asset is released, a fee may be paid for the transaction relating to the release of the asset. This fee may be taken out of the asset being purchased or the fee may be based on an entirely different asset or currency. The cost basis for the fee, in all cases where the fee is a cryptocurrency, is calculated at the date of the transaction.

Cost Basis Inventory Valuation Method

CHAINOMETRY supports the following inventory valuation methods which are applicable to various tax jurisdictions worldwide:

• First in First Out (FIFO)
• Last in First Out (LIFO)
• Highest In First Out (HIFO)
• Lowest In First Out (LOFO)
• Average cost
• Shared Pool

Users can select the appropriate inventory valuation method depending on their preference and regulations for their tax jurisdiction. A default method is automatically selected for a user’s account based on their selected tax region during registration however this should be verified by the user or accountant so that it is appropriate for the tax laws in their region.

FIFO, LIFO, HIFO and LOFO calculations are based on the execution date and time of the trade, swap, deposit or withdrawal. CHAINOMETRY supports timestamps to very accurate clock precision up to 100 nanoseconds. The level of detail will depend on data received from the exchange or blockchain. Where transactions for an asset are executed at the same time these transactions will be randomly assigned a position in the sort order for determining its position in the allocation of the asset balance when applying the inventory valuation method.

Average Cost is calculated by the total of the units purchased for an asset divided by the total cost. To determine the total cost, all purchases are valued in the primary currency of the exchange. Only asset balances for the financial period of the tax report are included in this calculation as well as any remaining balances from previous financial periods. Asset balances are reduced on the ledger based on the first-in-first-out (FIFO) method.

Shared Pool is the UK provision of Average Cost which includes two further rules for determining cost basis:

1. If you buy and sell tokens within a 30-day period, the cost basis is determined using the average cost method restricted to transactions 30 days from the trade date.
2. If buying and selling tokens on the same day, the cost basis is determined using the average cost method restricted to transactions in the same day.