United States v. Payward Ventures, Inc.

Full title: UNITED STATES OF AMERICA, Plaintiff, v. PAYWARD VENTURES, INC., Defendant.

Court: United States District Court, Northern District of California

Date published: Jun 30, 2023

23-mc-80029-JCS (N.D. Cal. Jun. 30, 2023)

Opinion

23-mc-80029-JCS

06-30-2023

UNITED STATES OF AMERICA, Plaintiff, v. PAYWARD VENTURES, INC., Defendant.

JOSEPH C. SPERO, UNITED STATES MAGISTRATE JUDGE

ORDER GRANTING IN PART AND DENYING IN PART PETITION TO ENFORCE IRS SUMMONS

RE: DKT. NOS. 1, 17, 19, 24, 26

JOSEPH C. SPERO, UNITED STATES MAGISTRATE JUDGE

I. INTRODUCTION

This case involves a summons issued by the Internal Revenue Service (“IRS”) as to Payward Ventures, Inc. and subsidiaries (collectively, “Kraken”), an online cryptocurrency exchange platform, that the Court preliminarily approved in a prior proceeding, In the Matter of the Tax Liabilities of John Does, Case No. 21-cv-02201-JCS (N.D. Cal.) (“Kraken I”). After Kraken failed to comply with the summons, the United States of America (“the Government” or “the United States”) initiated the instant action by filing a petition to enforce the summons pursuant to 26 U.S.C. §§ 7402(b) and 7604(a) (“Petition”). The Court issued an order to show cause why the Petition should not be enforced and the parties have provided briefing in response. A hearing on the Petition was held on June 9, 2023. For the reasons set forth below, the Court GRANTS in part and DENIES in part the Petition.¹

1 The parties have consented to the jurisdiction of a United States magistrate judge pursuant to 28 U.S.C. § 636(c).

II. BACKGROUND ²

2 The Government has supplied a series of declarations in support of the summons in Kraken I and the Petition in this action by Supervisory Internal Revenue Agent Karen Cincotta (“Agent Cincotta”). These declarations are referred to as follows: Kraken I, dkt. no. 1-2 (Declaration of Karen Cincotta in Support of Ex Parte Petition for Leave to Serve “John Doe” Summons) (“Kraken I, First Cincotta Decl.”); Kraken I, dkt. no. 8-1 (Second Declaration of Karen Cincotta in Support of Ex Parte Petition for Leave to Serve “John Doe” Summons (“Kraken I, Second Cincotta Decl.”); United States v. Payward Ventures, Inc., Case No. 23-mc-80029-JCS (N.D. Cal.) (“Kraken II”), dkt. no. 1-1 (Declaration of Karen Cincotta in Support of Petition to Enforce Internal Revenue Summons (“Kraken II, Cincotta Petition Decl.”)); Kraken II, dkt. no. 26-2 (Second Declaration of Karen Cincotta in Support of United States' Petition to Enforce Internal Revenue Service Summons, (“Kraken II, Cincotta Reply Decl.”).

A. Kraken

Kraken “operate[s] a digital currency exchange under the trade name Kraken through the website www.kraken.com [https://perma.cc/3A4V-8TWG].” Kraken I, First Cincotta Decl. ¶ 55. “A digital currency exchange functions much like a traditional currency exchange, except it deals with the conversion of cryptocurrency for traditional currency or vice versa, as well as the exchange of one cryptocurrency for another cryptocurrency.” Id. ¶ 18. Kraken offers its services to both U.S. and international users in more than 190 countries. Kraken II, dkt. no. 19-4 (Declaration of Todd Siemers in Support of Payward Ventures, Inc.'s Opposition to Petition to Enforce Internal Revenue Service Summons) (“Siemers Decl.”) ¶ 4.

Kraken offers a variety of account levels and types of services, and the type of information users must provide to register for an account depends on the type of account they are registering for. Siemers Decl. ¶¶ 7-9; Kraken II, Cincotta Petition Decl. ¶¶ 70-76. Kraken data engineer Todd Siemers describes the requirements for registering accounts at Kraken's different levels of service as follows:

5. To use Kraken's exchange services, a user must first open an account. Kraken currently offers several different levels of accounts: Starter, Express, Intermediate, and Pro. In general, Starter and Express accounts offer more limited services and thus require lower levels of verification by the user. Intermediate and Pro accounts, on the other hand, permit a wider variety of funding methods and transaction types and have higher withdrawal and transaction limits. Consequently, Intermediate and Pro account users are required to provide additional verification. During the 2016 to 2020 timeframe, all account levels required the user to input certain identity information, including first and last name, date of birth, address, email address, and phone number.

6. To register for either an Intermediate or Pro account, the user is required to confirm their identity and physical address by uploading an identification document (such as a passport or driver's license) and proof of residence. Pro account holders are additionally required to complete a Know-Your-Customer Questionnaire, which, among other things, asks questions about the account holder's occupation, source of income, and intended use of the account.

7. Starter, Express, and Intermediate accounts are available only to individuals, while the Pro account can be held by either an individual or a business.

Siemers Decl. ¶¶ 7-9.

According to Agent Cincotta, under Kraken's terms of use, verification requirements for all three levels available prior to 2021 - Starter, Intermediate and Pro³- include two-factor authentication for login; email address; full name; date of birth; phone number; and physical address. Kraken II, Cincotta Petition Decl. ¶ 74. “In addition, valid ID, proof of residence, occupation, and a taxpayer ID number (for U.S. clients) are required for intermediate-level and pro-level accounts” and “[a]n identification confirmation photo may also be required as part of either intermediate-level or pro-level account verification.” Id. ¶ 75. She states that “[n]o taxpayer ID number is required for starter-level accounts.” Id. Agent Cincotta notes, however, that “[t]he oldest information the IRS has relating to Kraken's account verification requirements is from August 2019.” Id. ¶ 84.⁴

3 It is not clear when the Express account discussed by Mr. Siemers in his declaration was created. Agent Cincotta does not discuss that level of account in her declarations. At the hearing, Kraken stipulated that the Express account is a type of starter-level account.

4 At the hearing, Kraken stipulated that it does not require users to provide a taxpayer ID for Starter and Express accounts and that it only started collecting that information as to the Intermediate and Pro accounts in 2019.

Agent Cincotta describes the types of transactions that can be conducted at the different account levels as follows:

None of the account levels place[s] any restrictions on trading volume or value. This means that an individual with a starter account can trade cryptocurrency in unlimited amounts (and generate significant amounts of taxable gain) without needing to provide a taxpayer ID number. All three account levels permit the user to trade on margin, although limits are placed based on account level, and all three account levels permit the user to earn additional cryptocurrency by participating in the running and maintenance of blockchain. The intermediate and pro levels also allow users access to additional trading options such as futures trading and over-the-counter trading.

Id. ¶ 77; see also Kraken I, Second Cincotta Decl., ¶ 23 (“All three account levels permit the user to trade on margin, although limits are placed based on account level, and all three account levels permit the user to earn additional cryptocurrency by participating in staking.”); Kraken I, dkt. no. 8 (United States' Response to Order to Show Cause Why Petition Should Not be Denied (“Kraken I, Response”) at 7 n. 3 (“‘Staking,' more specifically ‘on-chain staking' is a process through which a user holding certain types of cryptocurrency can participate indirectly in the validation and confirmation of cryptocurrency transactions to the blockchain by ‘staking' their units. While staked, the user cannot sell or withdraw the units but can earn rewards (payouts) in return for staking.”).

B. The IRS Investigation

Agent Cincotta describes two government reports identifying tax compliance issues related to cryptocurrency - one by the Government Accountability Office (“GAO”) completed in 2013 and another by the Treasury Inspector General for Tax Administration (“TIGTA”) completed in 2016. Kraken I, First Cincotta Decl. ¶¶ 5-6; Kraken II, Cincotta Petition Decl. ¶¶ 26-27. In the 2013 study, the GAO “identified several tax compliance risks associated with virtual currencies, ranging from lack of knowledge of tax requirements and uncertainty over how to report virtual currency transactions to deliberate underreporting of income and tax evasion.” Kraken II, Cincotta Petition Decl. ¶ 27. The 2016 TIGTA study found that “taxpayers' use of virtual currencies, including cryptocurrencies, had expanded significantly in recent years” and that “while there are legitimate reasons to use virtual currency . . . some virtual currencies are . . . popular because the identities of the parties involved are generally anonymous, leading to a greater possibility of their use in illegal transactions.” Id. ¶ 27.

Agent Cincotta also offers more general evidence of possible tax noncompliance by cryptocurrency users. First, she points to the results of a 2019 study using data from 2011-2013 indicating that “the overall rate of underreporting of income that was not subject to third-party information reporting was 55 percent, compared to 5 percent for amounts subject to substantial information reporting but no withholding, and 1 percent for amounts subject to substantial information reporting and withholding.” Id. ¶ 33. Second, she cites to the IRS's determination that only 800 to 900 taxpayers per year filed tax returns with a property description related to bitcoin or virtual currency in the period between 2013 and 2015, even though Coinbase, another cryptocurrency exchange (discussed further below), had “serviced more than 5.9 million customers and handled more than $6 billion in transactions” in the same period. Id. ¶ 36. According to Agent Cincotta, the IRS has found that although the number of taxpayers reporting cryptocurrency has increased since that time (4,164 taxpayers in 2016, 88,040 for 2017, 93,848 in 2018, 102,278 in 2019, 253,265 in 2020, and 842,888 in 2021), “these numbers still fall far short of what would be expected given the number of users, transactions, and value that the virtual currency exchanges publicize occur on an annual basis.” Id. ¶ 37.

According to Agent Cincotta, in response to concerns about cryptocurrency tax noncompliance, the IRS expanded its Electronic Payment Systems Initiative (“EPSI”), which was begun in 2005 to identify U.S. taxpayers who use electronic funds transfer and payment systems for tax avoidance purposes, “to address U.S. taxpayers who use virtual currencies for tax avoidance purposes, recognizing that some U.S. taxpayers use such currencies to expatriate and repatriate funds to and from offshore accounts.” Kraken I, First Cincotta Decl. ¶ 7; Kraken II, Cincotta Petition Decl. ¶¶ 28-29. As part of this initiative, Agent Cincotta states, the IRS established a Virtual Currency Issue Team (“VCIT”). Kraken I, First Cincotta Decl. ¶ 8; Kraken II, Cincotta Petition Decl. ¶ 29. “The VCIT was established to study the issue and then consider the compliance impact related to virtual currencies.” Id. According to Agent Cincotta, the summons at issue in this case is “one of the tools being used in the investigation.” Kraken II, Cincotta Petition Decl. ¶ 29; see also id. ¶ 30 (“[T]he IRS is pursuing this John Doe summons to Kraken in order to obtain customer and transactional information belonging to members of the John Doe class that can be used to conduct examinations of persons that may not have complied with the internal revenue laws.”).

Agent Cincotta explains in her declarations that “digital currency exchanges . . . provide valuable information about an individual customer's cryptocurrency transactions that can be used in conjunction with other publicly available blockchain information to adequately examine whether an individual has complied with internal revenue laws.” Kraken I, First Cincotta Decl. ¶ 29; see also Kraken II, Cincotta Petition Decl. ¶ 25. She describes various ways cryptocurrency use can relate to tax compliance:

• Wages, salary, or other income paid to an employee with virtual currency is reportable by the employee as ordinary income and subject to employment taxes paid by the employer.

• Virtual currency received by a self-employed individual in exchange for goods or services is reportable as ordinary income and is subject to self-employment tax. This would include a person who “mines” virtual currency as a trade or business.

• Virtual currency received in exchange for goods or services by a business is reportable as ordinary income.

• Gain on the exchange of virtual currency for other property is generally reportable as a capital gain if the virtual currency was held as a capital asset and as ordinary income if it is property held for sale to customers in a trade or business.

• Gain on the sale of property held as a capital asset in exchange for virtual currency is reportable as a capital gain.

• Payments made in virtual currency are subject to information reporting requirements to the same extent as payments made in fiat currency or instruments denominated in fiat currency.

Kraken I, First Cincotta Decl., ¶ 31. She also provides five specific examples of taxpayers who, based on information available to the IRS, are Kraken users and have violated the tax code. Id. ¶¶ 70-74. Finally, she points to public records reflecting that some Kraken users have routed the proceeds of criminal activity through Kraken. Id. ¶¶ 75-78.

C. Coinbase

The summons in this case is similar to the summons the Government sought to enforce in United States v. Coinbase, Inc., No. 17-cv-01431-JSC, 2017 WL 5890052, at *6-7 (N.D. Cal. Nov. 28, 2017) (“Coinbase”)). Kraken points to the Coinbase court's approval of a much narrower summons than the Government originally requested in that case while the Government questions the approach that was taken by the Coinbase court and asserts that it hampered the IRS's investigation.

In Coinbase, the IRS served a summons on Coinbase, Inc., a virtual currency exchange, “seeking records regarding nearly all of Coinbase's customers for a several-year period.” 2017 WL 5890052, at *2. In the initial summons, the Government “requested nine categories of documents including: complete user profiles, know-your-customer due diligence, documents regarding third-party access, transaction logs, records of payments processed, correspondence between Coinbase and Coinbase users, account or invoice statements, records of payments, and exception records produced by Coinbase's AML system.” Id. at *1. After Coinbase refused to comply and the Government brought a petition to enforce - but before the court had ruled on the petition - the IRS issued a narrower summons that did “not include users: (a) who only bought and held bitcoin during the 2013-15 period; or (b) for which Coinbase filed Forms 1099-K during the 2013-15 period.” Id. at *2. The information requested in the narrowed summons was largely the same as the original summons except that the Government dropped the request for exception records produced by Coinbase's AML system. Id. The narrowed summons was challenged by Coinbase and four Doe intervenors. Id.

Applying the standard for enforcing an IRS summons set forth in United States v. Powell, 379 U.S. 48 (1964), discussed further below, the court in Coinbase found that only two of the Powell factors were in dispute: whether the Government's summons served a legitimate purpose; and whether the information requested in the summons was relevant to that purpose. Id. at *4. As to the first factor, the court found that the summons had a legitimate investigative purpose of “investigating the reporting gap between the number of virtual currency users Coinbase claims to have had during the summons period and U.S. bitcoin users reporting gains or losses to the IRS during the summoned years.” Id. (internal quotations and citations omitted). The court pointed to evidence offered by the Government that “Coinbase is the largest U.S. exchange of bitcoin into dollars with at least 5.9 customers served and 6 billion in transactions while only 800 to 900 taxpayers a year have electronically filed returns with a property description related to bitcoin from 2013 through 2015.” Id. It found that “[t]his discrepancy creates an inference that more Coinbase users are trading bitcoin than reporting gains on their tax returns.” Id. It noted further, “[t]hat only 800 to 900 taxpayers reported gains related to bitcoin in each of the relevant years and that more than 14,000 Coinbase users have either bought, sold, sent or received at least $20,000 worth of bitcoin in a given year suggests that many Coinbase users may not be reporting their bitcoin gains.” Id.

Turning to the relevance factor, the court in Coinbase recognized that “the Coinbase account holder's identity and transaction records will permit the Government to investigate whether the holder had taxable gains that were not properly declared.” Id. at *6. The court found, however, that the information requested under the Government's summons was broader than that:

[T]he Government . . . also seeks account opening records, copies of passports or driver's licenses, all wallet addresses, all public keys for all accounts/wallets/vaults, records of Know-Your-Customer diligence, agreements or instructions granting a third-party access, control, or transaction approval authority, and correspondence between Coinbase and the account holder. The Government claims to need these records to verify an account holder's identity and determine if the holder used others to make transactions on the account holder's behalf. However, at this stage, where the Government is seeking records on over 10,000 account holders, these requests seek information than is “broader than necessary.” See Bisceglia, 420 U.S. at 151. The first question for the IRS is whether an account holder had a taxable gain. If the account holder did not, then correspondence between Coinbase and a user is not even potentially relevant. Similarly, while the Government needs an account holder's name, date of birth, taxpayer identification and address to determine if a taxable gain was reported, it only needs additional identity information such as copies of passports and drivers' licenses or “Know Your Customer” due diligence if there is potentially a taxable gain and if there is some doubt as to the taxpayer's identity. If there is not, these additional records will not shed any light on a legitimate investigation.

2017 WL 5890052, at *6. The court rejected the Government's argument that its summons properly “included such broad swaths of records . . . so that it [would] not need to return to court to ask for them if and when needed[,]” citing its duty to ensure that the Government was not collecting “thousands and thousands of personal records unnecessarily.” Id. It further observed that “[i]f the Government later determines that it needs more detailed records on a taxpayer, it can issue the summons directly to the taxpayer or to Coinbase with notice to a named user-a process preferable to a John Doe summons.” Id.

In Kraken I and in this action, the Government rejects what it describes as Coinbase's “novel summons process by which the IRS had to pursue its investigation in phases,” arguing that such an approach is not called for under 26 U.S.C. § 7609(f), governing Doe summonses, and would, as a practical matter, require the IRS to issue multiple John Doe summonses to the same third-party, which it asserts would be “extremely burdensome and time consuming.” Kraken I, Response at 2. According to the Government, this approach is not practical in light of the statute of limitations that applies to information obtained from a Doe summons, which under 26 U.S.C. § 6501(a) and 26 U.S.C. § 7609(e)(2) is only tolled while responsive information is being produced under the summons. Id. at 6 n. 1.

Moreover, the Government contends, the basic information provided under the Coinbase summons is insufficient due to the complexity of the tax code violations it is investigating:

Cryptocurrency is treated as property for federal tax purposes. See Notice 2014-21, 2014-16 I.R.B. 938, 2014 WL 1224474 (Mar. 26, 2014). When reporting gains and losses from the sale of cryptocurrency, a taxpayer may use different methods for calculating that gain or loss. For example, a taxpayer may use the specific identification method to pair the sale of a specific unit of cryptocurrency against a specific acquisition. See IRS Virtual Currency FAQs, FAQ#39 & 40, available at: Frequently Asked Questions on Virtual Currency Transactions |Internal Revenue Service (irs.gov). Alternatively, where a taxpayer has not used the specific identification method or lacks records to fully support the use of that method, the taxpayer must rely on the so-called “first-in-firstout” accounting method that simply pairs the sale of a unit of cryptocurrency against the oldest-acquired unit chronologically. Id. at FAQ#41. These approaches allow a taxpayer flexibility in how they calculate gains or losses on the sale of cryptocurrency units held as capital assets. As a result, the IRS cannot make a “taxable gain” determination by looking at an account holder's transaction information in isolation. The IRS must (1) identify the account holder, (2) determine whether that individual filed a tax return for the relevant tax year, (3) determine whether that individual reported cryptocurrency transactions on that return, and (4), if so, whether what was reported, or the approach taken in reporting the information, indicates compliance with the internal revenue laws.

This analysis can become even more complicated because many taxpayers operating in the cryptocurrency space have accounts at more than one cryptocurrency exchange and also make use of personal user wallets. For example, the IRS has conducted examinations where the taxpayer involved had cryptocurrency transactions at three or more distinct exchanges and, at times, upwards of ten exchanges. [Kraken I,] Second [Cincotta] Declaration at ¶ 6. Current tax reporting requirements do not require a taxpayer to identify on their tax return on which cryptocurrency exchange taxable transactions occurred. Id. This makes rooting out tax non-compliance much more complex than simply reviewing the account transaction information for one account holder on one exchange in isolation. . . .[H]aving additional specific information about the nature of an account holder's non-transactional activity is necessary when the IRS is making its initial determination about who the correct taxpayer is, and in what other activity that individual may be engaging. This information is required for the IRS to reach a reasonably-accurate conclusion about tax compliance. The IRS's investigation is not solely focused on identifying tax non-compliance for account holders at a single exchange like Kraken, but rather to identify tax noncompliance for individuals transacting in cryptocurrency with accounts at that exchange who may have additional accounts at other exchanges.

Kraken I, Response at 3-4.

According to Agent Cincotta, because the court in Coinbase limited the identifying information Coinbase was required to produce to “basic information such as name, date of birth, taxpayer ID number, and physical address[,]” there are still 750 taxpayers - out of approximately 13,000 Coinbase customers who received notice of the required disclosures - that it has not been able to identify, accounting for “more than $100 million in gross proceeds from the sale of cryptocurrency during the years covered by the Coinbase John Does summons.” Kraken II, Cincotta Petition Decl. ¶¶ 49-50.⁵She further states that because of the “partial enforcement of the summons in Coinbase” the IRS was “prevented . . . from having discussions with Coinbase about what other additional identifying information it had in its records that could be used to help the IRS positively identify the unidentifiable users, like telephone numbers or email addresses.” Id. ¶ 50. As to the Coinbase users the IRS was unable to identify, Agent Cincotta attributes these failures largely to the lack of a taxpayer ID numbers. Id. ¶ 47. Agent Cincotta states, “[w]here there was no taxpayer ID number and other information was also missing, it was nearly impossible for the IRS to positively identify the relevant taxpayer.” Id.

5 Agent Cincotta provides a detailed explanation of the difficulties the IRS had identifying some Coinbase account holders, stating as follows:

43. In reviewing the information provided in response to the John Doe summons issued to Coinbase, the IRS ran into several problems when trying to positively identify the account holders. 44. The information provided by Coinbase lacked taxpayer ID numbers for approximately 10% of the users (over 1,300 taxpayers). There were also over 150 instances where the account data did not include a name and approximately 170 instances where the name was a pseudonym rather than an actual name. There were over 500 instances where no date of birth information was provided and roughly 1,000 instances where no physical address information was provided. 45. The IRS worked with Coinbase to attempt to obtain the missing information. Coinbase was able to provide some of the missing information, reducing the unknown names to only a few. Missing address information was reduced to approximately 650 instances and missing date of birth information was reduced to slightly below 500. Coinbase was not able to provide any of the missing taxpayer ID numbers. 46. During discussions with Coinbase, it explained that some of the account information may be missing because it had not necessarily been collected for some of the oldest accounts. As discussed in paragraph 44 above, basic identity information such as name, taxpayer ID number, date of birth, and physical address was insufficient in these situations to positively identify the actual taxpayer account holder.

Kraken II, Cincotta Petition Decl. ¶¶ 43-46.

D. Procedural Background

On March 30, 2021, the United States filed an ex parte petition seeking the Court's permission to serve an administrative summons (“original summons”) upon Kraken to obtain information about “John Does[,]” defined as “United States persons who, directly or indirectly had authority over any combination of accounts held with Payward Ventures, Inc., d/b/a Kraken or Kraken.com, or its predecessors, subsidiaries, divisions, or affiliates (collectively, ‘Kraken') with at least the equivalent of $20,000 in value of transactions (regardless of type) in cryptocurrency in any one year, for the period January 1, 2016 through December 31, 2020.” Kraken I, dkt. no. 1 (March 30, 2021 ex parte petition) & 1-3 (original summons).⁶

6 The original summons requested the following information:

User Identity Information 1. Account registration records for each account owned or controlled by the User including, but not limited to, complete user profile, account application, records permitting third-party access, history of changes to user profile from account inception, complete user preferences, complete user history (including confirmed devices, internet protocol addresses, and account activity), complete user payment methods, and any other information related to the funding sources for the account, regardless of date. This request does not include passwords, pins, private keys, security settings, and account recovery information. 2. Any other records of Know-Your-Customer due diligence performed with respect to the User not included in paragraph 1, above, regardless of date. 3. All correspondence between Kraken and the User or any third party with access to the account pertaining to the account, including but not limited to e-mails, chat support logs, telephone logs or recordings, letters, or other memoranda of communication. 4. All exception reports produced by your anti-money laundering (“AML”) system, and all records of investigation of such exceptions. This request does not include any suspicious activity reports (“SAR”) that were ultimately generated as a consequence of an AML alert or any other information that would reveal the existence of a SAR. Transaction Activity 5. All records of activity in the User's account including, but not limited to: a. Records identifying the date and time, amount, and U.S. dollar value of any purchase or sale of cryptocurrency for U.S dollar or foreign legal tender (fiat currencies) or other cryptocurrency; b. Records identifying the date and time, value (or expense) of any lending, borrowing, or margin position entered into in the account; c. Records identifying the date and time, amount, U.S. dollar value, transaction hash (ID), and blockchain addresses for cryptocurrency units transferred into or out of the User's account from another Kraken user or from outside of Kraken. d. Records identifying the date and time, amount, and U.S. dollar value of any units of cryptocurrency received by the User in the account as a result of a chainsplitting event such as a hard fork or promotional event. 6. All records of account funding (deposits, withdrawals, or transfers) in U.S dollar or foreign legal tender, including transactions conducted through ACH transfers, wire or other electronic transfer, or any other form, and any and all invoices, billing statements, receipts, or other documents memorializing and describing such transactions.

Kraken I, dkt. no. 1-3 at ECF pp. 13-14.

In response to the Government's ex parte petition in Kraken I, the Court issued an order to show cause why the petition should not be denied on the basis that the summons was overbroad. Id., dkt. no. 6. In the order to show cause, the Court observed that “[i]n addition to basic registration, identification, and transaction information, the proposed summons [sought] broad categories of information such as ‘complete user preferences,' ‘[a]ny other records of Know-Your-Customer due diligence,' and ‘[a]ll correspondence between Kraken and the User or any third party with access to the account pertaining to the account,' among other similarly expansive requests.” Id. (quoting original summons, dkt. no. 1-3 at ECF p. 13). The Court further found that Agent Cincotta's explanations for some of these categories of information “rest[ed] on conclusory assertions that such information ‘may be relevant in determining, and verifying, the identity of the account user' or ‘revealing other accounts controlled by the same user.'” Id. (citation omitted).

The Court noted in the order to show cause that “the Honorable Jacqueline Scott Corley rejected the IRS's position that similarly broad categories of information were relevant, and held that the IRS should first review basic user information and transaction histories before determining whether further subpoenas - either to the cryptocurrency exchange or to individual users - were necessary.” Id. (citing Coinbase, 2017 WL 5890052, at *6-7). The Court ordered the Government to specifically address in its response “why each category of information sought is narrowly tailored to the IRS's investigative needs, including whether requests for more invasive and all-encompassing categories of information could be deferred until after the IRS has reviewed basic account registration information and transaction histories.” Id.

Although the Government argued in its Response that this Court should not take the “phased” approach taken in Coinbase, it narrowed its proposed summons “to assuage potential concerns.” Kraken I, Response at 3. The most significant amendment was the removal of Request 3 from the summons, which sought “[a]ll correspondence between Kraken and the User or any third party with access to the account pertaining to the account, including but not limited to emails, chat support logs, telephone logs or recordings, letters, or other memoranda of communication.” Kraken I, dkt. no. 1-3 at ECF pp. 13. Otherwise, the narrowed summons seeks largely the same information as the original summons.⁷This Court approved the proposed summons, as narrowed, noting that “[a]ny further disputes as to the scope of the summons would benefit from adversarial briefing.” Kraken I, dkt. no. 9. The summons was served on Kraken on May 11, 2021. Kraken II, Cincotta Petition Decl. ¶ 5. “Despite discussions between the parties, however, Kraken refused to comply with the summons and has not produced the books, records, papers, and other data demanded in the summons.” Id. at ¶ 148. Consequently, the Government brought the instant action to enforce the summons.

7 The narrowed summons, which is the one the Government seeks to enforce in this action, requests “information regarding unknown U.S. taxpayers who directly or indirectly held or had control over any combination of user accounts at Payward Ventures, Inc. and Subsidiaries with at least the equivalent of $20,000 in value of transactions (regardless of type) in cryptocurrency in any one year during January 1, 2016, through December 31, 2020.” Dkt. no. 1-2 at ECF p. 3. The requests in the summons are as follows:

User Identity Information 1. Account user registration records for each account owned or controlled by the User including: a. User profile, User preferences, or account application information, regardless of how it is labelled or maintained, as follows: i. Name (including full name, any pseudonym, or any user ID); ii. Date of Birth; iii. Taxpayer Identification Number iv. Physical Address; v. Telephone Number; vi. Email Address; b. History of all changes to the personal information identified above since the inception of the account; c. Complete User history for internet protocol addresses used to access the account; and d. Complete User payment methods (e.g., linked bank or credit card accounts) regardless of date. This request does not include passwords, pins, private keys, security settings, and account recovery information. 2. With respect to any Know-Your-Customer due diligence questionnaires completed by a User, information relating to the User's employment, net worth, and source of wealth for individual Users, and for business Users, to the extent not provided in response to Request 1, above, legal name, business address, country, website, contact information, industry, goods and services, government issued business registration or tax-identification number, and source of funds[.] 3. All exception reports produced by your anti-money laundering (‘AML') system, and all records of investigation of such exceptions. This request does not include any suspicious activity reports (‘SAR') that were ultimately generated as a consequence of an AML alert or any other information that would reveal the existence of a SAR. Transaction Activity 4. All records of activity in the User's account including, but not limited to: e. Records identifying the date and time, amount, and U.S. dollar value of any purchase or sale of cryptocurrency for U.S dollar or foreign legal tender (fiat currencies) or other cryptocurrency; f. Records identifying the date and time, value (or expense) of any lending, borrowing, or margin position entered into in the account; g. Records identifying the date and time, amount, U.S. dollar value, transaction hash (ID), and blockchain addresses for cryptocurrency unit transferred into or out of the User's account from another Kraken user or from outside of Kraken. h. Records identifying the date and time, amount, and U.S. dollar value of any units of cryptocurrency received by the User in the account as a result of a chainsplitting event such as a hard fork or promotional event. 5. All records of account funding (deposits, withdrawals, or transfers) in U.S dollar or foreign legal tender, including transactions conducted through ACH transfers, wire or other electronic transfer, or any other form, and any and all invoices, billing statements, receipts, or other documents memorializing and describing such transactions.

Dkt. No. 1-2 (summons) at ECF pp. 7-8.

As discussed further below, Kraken opposes enforcement of the summons, arguing that the Petition should be denied in its entirety because of its overbreadth and the heavy burden that compliance would impose on Kraken. It relies heavily on the fact that the summons in this case is broader than the one that was approved in Coinbase. The Government, in turn, argues that it has demonstrated there is a reasonable basis for enforcement of the summons, which it contends is narrowly tailored. It further contends that the limitations imposed by the court in Coinbase as to the scope of the summons were excessive and that the limitations the Government agreed to, without the involvement of the court, when negotiating with Coinbase have no bearing on whether the summons in this case is proper.

III. ANALYSIS

A. The Motions to Seal

Certain information about Kraken's “internal technological capabilities surrounding the organization, query and analysis of information on its systems” is the subject of motions to seal brought by Kraken (dkt. no. 19) and the Government (dkt. no. 26). Both motions are based on Kraken's assertion that this information is “confidential and proprietary business information.” Dkt. no. 19 at 2. However, the only support Kraken has offered for this assertion is a declaration of counsel that it is his “understanding” that disclosure of this information will create an “increased security risk.” Fondo Decl. (dkt. no. 19-1) ¶ 5. Fondo states, “This increased risk could jeopardize users' digital assets, as well as Kraken's goodwill and competitive standing with its clients in light of that threat. Revelation of this information could also put it at a significant competitive disadvantage if Kraken's competitors were to understand the precise capabilities of its systems-not to mention affect the trade secret nature of those systems.” Id.

These conclusory statements do not satisfy the heavy burden that must be met to justify sealing material in dispositive motion papers and attachments, which requires that the proponent of sealing such material articulate compelling reasons supported by specific factual findings. See Kamakana v. City & Cnty. of Honolulu, 447 F.3d 1172, 1178 (9th Cir. 2006). Moreover, although the Court invited Kraken to supply a supplemental declaration addressing its sealing requests, Kraken declined to do so. Accordingly, both sealing motions (dkt. nos. 19 and 26) are DENIED. The Court also denies as moot dkt. nos. 17 and 24, both of which were superseded by amended motions.

B. Legal Standards Governing Enforcement of IRS Summonses

Under 26 U.S.C. § 7602(a), the IRS may issue a summons for “ascertaining the correctness of any return, making a return where none has been made, determining the liability of any person for any internal revenue tax or . . . collecting any such liability....” 26 U.S.C. § 7602(a). Where the summons is issued to a third party, notice must be given to the person named in the summons to allow them to intervene and bring a motion to quash if they oppose the summons. 26 U.S.C. § 7609(a) & (b).

To obtain a court order enforcing an IRS summons, the IRS must establish “good faith” by showing that the summons: (1) is issued for a legitimate purpose; (2) seeks information relevant to that purpose; (3) seeks information that is not already in the IRS's possession; and (4) satisfies all of the administrative steps set forth in the Internal Revenue Code.” United States v. Powell, 379 U.S. 48, 57-58 (1964)). “[T]his showing need only be minimal . . . because the statute must be read broadly in order to ensure that the enforcement powers of the IRS are not unduly restricted.” Liberty Fin. Servs. v. United States, 778 F.2d 1390, 1392 (9th Cir. 1985) (citing United States v. Balanced Financial Management, Inc., 769 F.2d 1440, 1443 (10th Cir.1985)).

Once the IRS makes a prima facie case that the Powell factors are met, the taxpayer bears a “heavy” burden to show an abuse of process or lack of good faith on the part of the IRS. United States v. LaSalle Nat'l Bank, 437 U.S. 298, 316 (1978). “‘The taxpayer must allege specific facts and evidence to support [their] allegations of bad faith or improper purpose.'” Id. (quoting United States v. Jose, 131 F.3d 1325, 1328 (9th Cir. 1997)). Where such evidence is presented, the court must then “scrutinize[]” the summons “to determine whether it seeks information relevant to a legitimate investigative purpose, and the court may choose either to refuse enforcement or narrow the scope of the summons.” United States v. Goldman, 637 F.2d 664, 668 (9th Cir. 1980) (citing United States v. Bisceglia, 420 U.S. 141, 146 (1975)).

Where an IRS summons is issued to a third party as a “John Doe” summons, that is, “does not identify the person with respect to whose liability the summons is issued[,]” such a summons 17 “may be served only after a court proceeding in which the Secretary establishes that

(1) the summons relates to the investigation of a particular person or ascertainable group or class of persons,

(2) there is a reasonable basis for believing that such person or group or class of persons may fail or may have failed to comply with any provision of any internal revenue law, and

(3) the information sought to be obtained from the examination of the records or testimony (and the identity of the person or persons with respect to whose liability the summons is issued) is not readily available from other sources.

26 U.S.C. § 7609(f); see also 26 U.S.C. § 7609(h)(2) (providing that “[t]he determinations required to be made under subsections (f) and (g) shall be made ex parte and shall be made solely on the petition and supporting affidavits.”). Section 7609(f) further provides that the IRS may not issue a John Doe summons “unless the information sought to be obtained is narrowly tailored to information that pertains to the failure (or potential failure) of the person or group or class of persons referred to in paragraph (2) to comply with one or more provisions of the internal revenue law which have been identified for purposes of such paragraph.” Id.

“Section 7609(f)'s criteria . . . constitute a procedural safeguard which Congress created to provide extra protection to unknown target taxpayers to whom the IRS cannot give notice.” United States v. Samuels, Kramer & Co., 712 F.2d 1342, 1346 (9th Cir. 1983). However, “Section 7609(f) neither enlarges nor contracts the substantive rights against enforcement granted to all taxpayers under Powell.” Id. (citing In re Tax Liabilities of John Does, 688 F.2d 144,149 (2d Cir. 1982); United States v. Pittsburgh Trade Exchange, Inc., 644 F.2d 302, 305 (3d Cir.1981)). Thus, “[n]otwithstanding the added protection sections 7609(f) and (h) provide against improper issuance of John Doe summonses . . . the sections do not expand beyond the Powell criteria the substantive grounds on which a record-keeping taxpayer can resist enforcement of a summons once it has been served.” Id.

C. The Significance of Coinbase

As a preliminary matter, the Court notes that both sides have made statements that border on mischaracterizing the holding and legal significance of Coinbase. To the extent that Kraken implies that Coinbase establishes some set numerical limit on the number of cryptocurrency accounts that can be the subject of an IRS Doe summons, or more broadly, certain set parameters as to the types of information that can be the subject of an IRS summons issued to a cryptocurrency company, that is clearly not the case. As the Government points out, “John Doe summons class definitions take many different forms, depending on the legitimate needs of the investigation.” Kraken II, dkt. no. 26-3 (United States' Response to Payward Ventures Inc.'s Opposition to Petition to Enforce Internal Revenue Service Summons) (“Kraken II, Reply”) at 2 (citing Kraken II, Cincotta Reply Decl. ¶¶ 5-59). Thus, the Court recognizes that the limitations placed on the summons in Coinbase, while instructive, are not binding in this case.

On the flip side, the Court rejects the Government's assertion that “the phased, limitedinformation-review approach imposed in Coinbase is [not] what Powell or the statute requires.” Kraken II, Reply at 3. Rather, the Court finds that the limitations on the summons approved in Coinbase are consistent with Powell and the statutory provisions that govern Doe summonses, requiring that such summonses be narrowly tailored. The fact that the Government might need to issue a second summons in order to make that showing as to some users and information does not mean that Coinbase established a “two-step investigative approach” that is inconsistent with Powell. It is simply a reflection of the reality that the more speculative the relevance of particular types of information, the more likely it will be that a summons that requires the production of such information will not be narrowly tailored. Indeed, the Government acknowledges that as it conducts investigations, “each summons differ[s] in class definition and requests depending on the needs of the investigation and to reflect what the IRS ha[s] learned from each previous summons and production of information.” Kraken II, Reply at 2 (emphasis added).

And while the Government goes to great lengths to persuade the Court that the limitations in Coinbase hampered its investigation, it ultimately determined the identities of all but 750 Does, out of approximately 13,000 accounts. See Kraken II, Cincotta Petition Decl. ¶¶ 43-50. While those remaining Does account for a significant dollar amount in gross proceeds from the sale of cryptocurrency during the years covered ($100 million), the Government offers no explanation for its failure to seek approval of a targeted summons directed at that much smaller group using the information obtained in the course of its investigation to meet the “narrowly tailored” requirement. At the hearing, the Government was unable to explain why it did not seek approval of a narrowly tailored follow-up summons in Coinbase. And notably, it did not contend that it was barred from seeking such a summons because of any statute of limitations. Because the Government did not issue a summons aimed at the remaining 750 Coinbase Does using the information obtained from the earlier summons to meet the narrowly tailored requirement, even though it could have done so, the Court finds its professions of the harm it has suffered from the Coinbase court's ruling to be unconvincing.

In sum, the Court finds the reasoning of Coinbase to be persuasive but must make its own determination as to whether the Doe summons in this case is narrowly tailored based on the record before it.

D. Powell Factors

As in Coinbase, there is no dispute in this case that the third and fourth Powell factors are satisfied. The Court therefore addresses whether the summons (1) serves a legitimate purpose and (3) seeks relevant information.

1. Legitimate Purpose

The Government has a legitimate purpose for seeking the materials described in the summon. As discussed above, the summons was issued in connection with an investigation by the IRS to determine the identity and correct federal income tax liability of U.S. persons who conducted transactions in cryptocurrency during the period 2016-2020. Kraken II, Cincotta Petition Decl. ¶ 2. Further, an IRS investigator involved in the investigation, Agent Cincotta, attests that “[t]he information sought in the summons may be relevant to the IRS's investigation into the identities and federal tax liabilities of cryptocurrency users who have failed or may be failing to comply with their federal tax obligations.” Id. ¶¶ 87-88.

This conclusion finds support in the fact that the number of taxpayers filing tax returns with a property description related to bitcoin between 2016 and 2020 (4,164 taxpayers in 2016, 88,040 for 2017, 93,848 in 2018, 102,278 in 2019, and 253,265 in 2020), while above preCoinbase levels, is still dwarfed by the amount of trading activity that occurs on Kraken. Id. ¶ 37. According to Agent Cincotta, Kraken has over 4 million clients, has conducted over $140 billion in trading activity since 2011 and was registering up to 50,000 new users a day as of the end of 2017. Id. ¶ 58. Agent Cincotta has also pointed to evidence that under-reporting of income is substantially higher where there is no third-party information reporting, as is the case with Kraken. Id. ¶ 33. Finally, Agent Cincotta has pointed to five concrete examples of Kraken users who have committed various types of tax code violations involving cryptocurrency. Kraken I, First Cincotta Decl. ¶¶ 70-74.

The Court therefore finds that the Government has demonstrated that its summons to Kraken is for a legitimate purpose under Section 7602(a).

2. Relevance

a. Legal Standard

The Supreme Court has made clear that under Section 7602, “an IRS summons is not to be judged by the relevance standards used in deciding whether to admit evidence in federal court.” United States v. Arthur Young & Co., 465 U.S. 805, 814 (1984) (citing Fed.R.Evid. 401). This is apparent from the language of Section 7602, authorizing the IRS to issue a summons “[t]o examine any books, papers, records, or other data which may be relevant or material to such inquiry.” 26 U.S.C. § 7602(a)(1) (emphasis added). Thus, the IRS is authorized under this section “to obtain items of even potential relevance to an ongoing investigation, without reference to its admissibility.” United States v. Arthur Young & Co., 465 U.S. at 814 (emphasis in original).

Likewise, “[t]he required standard that the IRS must meet is clearly less than probable cause.” United States v. Goldman, 637 F.2d 664, 667 (9th Cir. 1980). Instead, the relevance standard is defined as “whether the inspection sought might [throw] light on the correctness of the taxpayer's return.” Id. (citing Foster v. United States, 265 F.2d 183 (2d Cir. 1959), cert. denied, 360 U.S. 912 (1960); United States v. Ryan, 455 F.2d 728, 733 (9th Cir. 1972)). In explaining this standard, the court in Goldman cited with approval the following passage:

The question, and it is not always one that lends itself easily to solution, is whether from what the Government already knows there exists the requisite nexus between taxpayer and records of another's affairs to make the investigation reasonable -- in short, whether the “might” in the articulated standard “might throw light upon the

correctness of the return,” is in the particular circumstances an indication of a realistic expectation rather than an idle hope that something may be discovered.

Id. (quoting United States v. Harrington, 388 F.2d 520, 524 (2d Cir. 1969)). The court continued, “The Government's burden, while not great, is also not non-existent.” Id. Further, “the summons should be ‘no broader than necessary to achieve its purpose.'” Coinbase, 2017 WL 5890052, at *6 (quoting United States v. Bisceglia, 420 U.S. 141, 151 (1975)).

b. Is definition of “User” too broad

i. Background

Kraken's Contentions

Kraken objects to the definition of “User” in the summons on the basis that it is overbroad, making the following arguments. First, it points out that the definition here sets a lower threshold than was approved in Coinbase by covering account holders with an aggregate of at least $20,000 in cryptocurrency transactions “regardless of type” for any one year between 2016 and 2020. Kraken II, dkt. no. 19-3 (Respondent Payward Ventures, Inc.'s Opposition to Petition to Enforce Internal Revenue Service Summons (“Kraken II, Opposition”)) at 8. In contrast, in Coinbase, the summons applied only to accounts with at least the equivalent of $20,000 in any one transaction type (buy, sell, send, or receive) in any one year. 2017 WL 5890052, at *2. According to Kraken, this broader definition would cover 59,331 unique Kraken accounts. Siemers Decl. ¶ 10. By way of comparison, Kraken estimates that if the narrower Coinbase threshold were used, the summons would cover 42,017 Kraken accounts. Kraken II, Opposition at 8 (citing Siemers Decl. ¶ 12). Kraken contends the definition of “user” in Coinbase already pushed the limit and that this broader definition “far exceeds the breaking point[,]” threatening to sweep in many users who transact only in small amounts and have no taxable gain. Id.

Kraken also points out that in Coinbase, the Government narrowed the scope of the summons to exclude users who only bought and held bitcoin during the period covered by the summons, arguing that the summons here should be similarly limited. Id. at 8-9. According to Kraken, where users only make deposits or purchases (“buy-hold crypto”) or withdrawals during the period covered by the summons, there is no taxable event and “Coinbase makes clear that the documents the IRS may obtain are only ones that might help discern a potentially unreported taxable gain[.]” Id. at 9. It is not enough, Kraken contends, that the information the Government seeks might help to establish the purchase price of a user's cryptocurrency, which might then be used to calculate a taxable gain. Id. (citing Kraken II, Cincotta Petition Decl. ¶ 138).

Similarly, Kraken asserts, “[a] deposit alone shows nothing and would encompass all the people who buy and simply hold cryptocurrency.” Id. According to Kraken, “[t]he IRS vaguely asserts that deposits and withdrawals are a ‘clear indicator that the user is holding cryptocurrency in other places,' and thus ‘needs' this information ‘so it can gather as much information as possible' to determine a user's tax compliance[,] .... [b]ut that is no different than the type of fishing expeditions that are not allowed under § 7609(f).” Id. (quoting Kraken II, Cincotta Petition Decl. ¶ 142) (and citing In re Tax Liabilities of John Does, 688 F.2d 144, 149 (2d Cir. 1982) for the principal that “Sections 7609(f) and (h) provide a prior restraint on the IRS's power to serve John Doe summonses, mainly ‘to preclude the IRS from using such summonses to engage in possible “fishing expeditions.”'”). Moreover, Kraken contends, Agent Cincotta's statements that deposits or withdrawals “may be taxable transactions themselves” are insufficient. Id. (citing Kraken II, Cincotta Petition Decl. ¶ 143). According to Kraken, Agent Cincotta “speculates that a deposit could reflect compensation or a similar taxable income payment, such as for goods and services, and that a withdrawal could represent a ‘taxable disposition' if sent to a third party . . . [b]ut this is yet another example of a ‘conclusory' assertion that cannot justify enforcement of this more expansive Summons[.]” Id.

Next, Kraken argues that the broad definition of “user” “leads to the potential collection of data for users with no nexus to the U.S. - whom the IRS has no interest in auditing - and creates a significant concern about Kraken's ability to comply with foreign privacy laws.” Id. at 9-10. Kraken asserts that “it is possible that certain non-U.S. citizens who at some point during the five year timeframe either lived in the U.S., had a U.S. phone number, or simply used a computer in the U.S. would get swept up in the search[,]” and that therefore, the summons is not narrowly tailored. Id. at 10. In addition, as to EU users, Kraken contends its compliance with the summons is likely prohibited under the EU General Data Protection Regulation (“GDPR”), which “generally prohibits the disclosure of personal data to non-EU countries unless formally recognized by the European Commission as having adequate levels of data protection, which the U.S. currently is not.” Id. (citing Regulation (EU) 2016/679, Article 3 at 45-49).

Finally, Kraken argues that the summons is overly burdensome, given that it covers the accounts of 59,331 users, and improperly invades the privacy of Kraken users. Kraken asserts that “[t]ransferring troves of sensitive personal and financial data (the vast majority of which will be irrelevant) to the IRS increases the risk of loss or theft” and points to a Treasury Inspector General Report finding that “the IRS did not meet all of the security requirements for its cloud-based systems and failed to timely implement mitigation and corrective actions to mitigate security risks.” Id. at 11 (citing The Enterprise Case Management System Did Not Consistently Meet Cloud Security Requirements TREASURY INSPECTOR GEN. FOR TAX ADMIN. (Mar. 27, 2023), https://www.oversight.gov/sites/default/files/oig-reports/TIGTA/202320018fr.pdf (attached as Ex. B to Kraken II, dkt. no. 16-1 (Declaration of Grant P. Fondo in Support of Payward Ventures, Inc.'s Opposition to Petition to Enforce Internal Revenue Service Summons) (“Kraken II, Fondo Decl.”)).

The Government's Response

The Government rejects Kraken's argument that the definition of “user” is overbroad. First, the Government challenges Kraken's assertion that the Doe definition in this case must be narrowed to match the one in Coinbase. Kraken II, Reply at 5. As to the threshold transaction amount required to be a “user” under the summons, the Government explains that in Coinbase it narrowed its John Doe class definition to users with $20,000 in transactions in any one category (buy, send, sell, receive) in any one year during the 2013-2015 period after learning from Coinbase that most of its users engaged in low volume, low dollar transactions. Id. (citing Coinbase, dkt. no. 65-3 (Declaration of David Utzke) ¶¶ 13-14). According to the Government, it broadened the definition in its summons to Kraken after “consider[ing] the needs of its investigation, what it learned from the summons response in Coinbase, the change in the cryptocurrency market over time, and how Kraken differs from Coinbase even though both are cryptocurrency exchanges.” Id. (citing Kraken II, Cincotta Reply Decl. ¶¶ 72-94). The Government argues that “[a]side from these practical reasons [for defining ‘user' more broadly in the summons to Kraken] . . ., there is no legal reason why the IRS should be made to use the same John Doe class definition for every cryptocurrency John Doe summons it issues.” Id. at 5-6. In addition, the Government rejects Kraken's argument that the lower threshold would sweep in account holders who engage only in low amount transactions involving no taxable gains, noting that “there is no de minimis exception in the law when reporting gains or losses from cryptocurrency transactions.” Id. at 6 n. 9.

The Government also rejects Kraken's argument that the definition of “user” in the Doe summons is overbroad because it encompasses users whose accounts reflect no “taxable event.” The Government argues that “the payment of wages in cryptocurrency, a hard-fork, and a chainsplit” are all taxable events and “would appear like a ‘buy and hold' in a user's account[.]” Reply at 6 (citing Kraken II, Cincotta Petition Decl. ¶¶ 88-91). It further asserts that as to gains and losses, “to determine basis, the IRS needs ‘buy' information even if cryptocurrency isn't sold within the same year.” Id. (citing Kraken II, Cincotta Reply Decl. ¶¶ 92-94; Kraken II, Cincotta Petition Decl. ¶ 23).

In her Reply declaration, Agent Cincotta explains why the IRS agreed to carve out buy hold information in Coinbase but is seeking that information here:

88. In Coinbase, the IRS agreed to a carve out from the user class for users that had “bought and held.” What this reflected was the IRS's understanding at the time that users that bought cryptocurrency during the period and held it wouldn't experience a taxable event.

89. The IRS has learned, however, that because of the way certain cryptocurrency events are reflected in a user's transaction history, its carve out for those that “bought and held” was flawed.

90. Receipt of cryptocurrency, without a corresponding sale, can be taxable. For example, a taxpayer's receipt of new cryptocurrency in connection with a “hard fork” is taxable. See generally Rev. Rul. 2019-24. A hard fork occurs when the distributed ledger technology used by a cryptocurrency undergoes a protocol change that results in a permanent diversion from the existing distributed ledger. A hard fork may create a new cryptocurrency, which is then recorded on a new distributed ledger, while transactions involving the legacy cryptocurrency remain recorded on the legacy distributed ledger. This type of hard fork is known as a “chain-split.” Sometimes, a hard fork coincides with a distribution of the new cryptocurrency, known as an “air drop,” to holders of the legacy cryptocurrency. Receipt of the new

cryptocurrency via an air drop following a hard fork results in taxable income to the recipient.

91. Cryptocurrency can be used in lending transactions that generate taxable interest income. Users can deposit their cryptocurrency into a pool of assets, known as a lending pool. Borrowers take loans from the pool by posting cryptocurrency collateral, drawing cryptocurrency from the lending pool, and paying taxable interest to the lenders. A carve out for users that “bought and held” would fail to capture these users.

92. Also, a taxpayer's gain or loss upon the disposition of virtual currency will generally be the difference between adjusted basis in the virtual currency and the amount received in exchange for the virtual currency, which should be reported on the tax return. See 26 U.S.C. § 1001; IRS Frequently Asked Questions on Virtual Currency Transactions, supra, Q7. Basis, for virtual currency purposes, is generally determined by the cost or amount spent to acquire cryptocurrency, adjusted for fees, commissions, and other acquisitions costs. See 26 U.S.C. § 1012; IRS Frequently Asked Questions on Virtual Currency Transactions, supra, Q8. When reporting gains and losses from the sale of virtual currency, a taxpayer may use different methods for calculating that gain or loss. A taxpayer may use the specific identification method (which pairs the sale of a specific unit of virtual currency against a specific acquisition) or the so-called “first-in-first-out” (FIFO) accounting method (which simply pairs the sale of a unit of virtual currency against the oldest-acquired unit chronologically). IRS Frequently Asked Questions on Virtual Currency Transactions, supra, Q39 - Q41. Although these approaches provide taxpayers with flexibility in how they calculate gains or losses on the sale of virtual currency units, they do not allow the IRS to make a “taxable gain” determination by simply reviewing an account holder's transaction information in isolation. Instead, the IRS must first positively identify an account holder and then determine whether that individual filed a tax return for the relevant tax year, whether that return reported virtual currency transactions, and, if so, whether what was reported, or the approach taken in reporting the information, complies with the internal revenue laws.

93. To determine whether a taxpayer's reporting of virtual currency complies with internal revenue laws, the IRS must know the correct adjusted basis for the units of virtual currency. This requires historical account information. If a taxpayer uses the FIFO accounting method, to determine which units of virtual currency were sold in a given year, the IRS must review a record of when prior units by a taxpayer were sold and match that information against records of when all units owned by the taxpayer were acquired. Likewise, if a taxpayer uses the specific identification method, the IRS must review historical records to determine whether the taxpayer has identified a specific virtual currency unit as sold to avoid the double counting of basis.

94. What this means is that if a taxpayer bought $20,000 of cryptocurrency in 2016 and held it until 2017 (when the cryptocurrency market experienced a downturn), at which point it was sold or exchanged, the IRS needs the transaction information from 2016 in addition to the transaction information for 2017 to determine

whether the taxpayer has properly determined any potential gain or more likely loss. If the taxpayer sold that cryptocurrency in 2017 for less than $20,000, he would have experienced a loss. Under the Coinbase class definition the IRS would not receive this user's information because in 2016 he bought and held and in 2017 he transacted below the dollar threshold. Yet, a complete understanding of this taxpayer's transaction reveals that he experienced a taxable event, and his information should be captured in the summons response.

Kraken II, Cincotta Reply Decl. ¶¶ 87-94.

In addition, the Government rejects Kraken's assertion that the IRS's stated “need” to “gather as much information as possible about taxpayer compliance” amounts to a “fishing expedition” under § 7609 and In re Tax Liabilities of John Does, 688 F.2d 144, 149 (2d Cir. 1982). Kraken II, Reply at 6. According to the Government, In re Tax Liabilities of John Does merely held that a summoned party cannot challenge the factual determinations that a district court must make under section 7609(f) before the court issues its ex parte authorization of a John Doe summons - a conclusion the Ninth Circuit has also reached. Id. (citing 688 F.2d at 145-46; United States v. Samuels, Kramer and Co., 712 F.2d 1342, 1346 (9th Cir. 1983)). Further, the Government contends, the “fishing expedition” language in In re Tax Liabilities of John Does highlighted by Kraken referred to the court's ex parte determination. Id. According to the Government, “[n]ot only can that determination not be challenged here, but in granting leave to serve the summons to Kraken in the first place, this Court has already prevented a fishing expedition.” Id. at 6-7.

Finally, the Government rejects Kraken's assertion that the summons is overbroad because it may infringe the privacy of non-U.S. account holders. Id. at 7. It again argues that “whether the request is narrowly tailored cannot be challenged on enforcement.” Id. Further, it asserts, “the IRS defined the user class and requested the information it did precisely so it could best determine whether users are U.S. persons for tax purposes.” Id. According to the Government, Kraken has no way to determine which users are U.S. persons because it does not ask, so the Government has identified information that will allow it to make that determination. Id. In particular, it asserts,

while it may be true that a U.S. based address may not be perfectly indicative of a U.S. person for tax purposes, it is one indication and a starting point. The same can be said for telephone numbers and

banking information. Although not exclusive, some email internet domains may refer to a foreign country. In those cases, it could alert the IRS that they may need to investigate further whether that user is a U.S. person for tax purposes. The same can be said for IP address.

Id.

In a footnote, the Government also rejects Kraken's assertion that the summons violates the privacy rights of Kraken users generally, pointing to the privacy notice it contends is posted on

Kraken's website, stating: “We may need to use your personal information to comply with any applicable laws and regulations, subpoenas, court orders or other judicial processes, or requirements of any applicable regulatory authority. We do this not only to comply with our legal obligations but because it may also be in our legitimate interest to do so.” Id. n. 10. The Government does not respond to Kraken's assertion that disclosure of information about foreign persons may violate some countries' privacy laws or the EU General Data Protection Regulation.

ii. Discussion

Whether “Narrowly Tailored” Requirement Can be Challenged on Enforcement

The Government asserts that by granting leave to serve the summons on Kraken in the first place, the Court already made the determination that the Powell factors were met and that that determination cannot be challenged in this enforcement action. Kraken II, Reply at 6-7. The Government is incorrect. The Ninth Circuit rejected a similar argument in United States v. Goldman, 637 F.2d 664, 668 (9th Cir. 1980). There, the government argued it had met its burden as to the relevance of the information it sought based on an affidavit from an IRS agent and therefore, that the burden had shifted to the summoned party to disprove relevance. 637 F.2d at 668. The court disagreed, explaining:

The Government appears to argue that, in issuing a show cause order, the district court implicitly found that the Government had met its Powell burden, thereby shifting to Goldman the burden of showing defects in the summons. This is a misperception of the function of the show cause order. In this context, the district court properly accepted Agent Rouleau's allegations of relevance as a prima facie showing adequate to call for the hearing demanded in the show cause order. Goldman's challenge marked the first point at which the Government was put to its true burden of establishing relevance Until there is such a challenge, the district court has no reason to place such a burden on the Government. It follows that the mere issuance of an order to show cause does not constitute a finding that Powell criteria have been satisfied.

637 F.2d at 668.

Here, the Government appears to go even further, arguing that once the show cause order has been issued, whether the request is narrowly tailored cannot be challenged. See Kraken II, Reply at 7. As the Government itself highlights, under Ninth Circuit case law a summoned party cannot challenge the factual determinations that a district court must make under section 7609(f) before the court issues its ex parte authorization of a John Doe summons. United States v. Samuels, Kramer and Co., 712 F.2d 1342, 1346 (9th Cir. 1983)). Thus, were the Court to adopt the approach espoused by the Government, a summoned party would never have the opportunity to challenge the relevance of the information covered by a summons. Nothing in the case authority or legislative history suggests, however, that Congress intended to deprive a party that is the subject of a Doe summons of this opportunity.

Furthermore, in this case, the Court made it particularly clear when it approved the summons in Kraken I that it did so “without prejudice to any argument that Kraken or its users might raise in a motion to quash” and that “[a]ny further disputes as to the scope of the summons would benefit from adversarial briefing.” Kraken I, dkt. no. 9. Therefore, the Court rejects the Government's argument that the question of whether its summons is narrowly tailored has already been decided and cannot be challenged in this proceeding.

Implications of Coinbase

As discussed above, Kraken argues that Coinbase illustrates the overbreadth of the definition of “user” both as to the threshold amount of transactions required to fall within the definition and the failure to carve out accounts where the holders only made deposits or purchases and did not sell cryptocurrency. The Court concludes that the Government has made a sufficient showing to justify the broader definition in the Kraken summons.

As to the threshold amount of transactions, the Government has offered evidence that its decision to voluntarily limit the definition of user in Coinbase was based on specific facts that it learned in its negotiations with Coinbase; there is nothing in the court's decision that required that the same threshold be applied as to other summonses involving cryptocurrency. Moreover, as the Government points out, the tax code does not contain a de minimis exception for reporting taxable gains and losses and thus, Kraken's concern that account holders who transact in low amounts will be improperly swept into the definition of “user” is misplaced. Further, as to the Government's inclusion of buy-hold only accounts in the definition of “user” in the Kraken summons, the Court finds the detailed explanation of the types of taxable events that may involve even the buy-hold accounts is sufficient to justify including them in the definition of “user” in the Kraken summons.

Foreign Privacy Rights

Although Kraken asserts that some non-U.S. users' information may be disclosed under the proposed summons, it does not point to any authority suggesting the summons should be limited on this basis; nor does it explain, as a practical matter, how any summons issued to it could avoid this result as it apparently does not collect this information. Moreover, Kraken does not appear to dispute that the privacy notice on its website informs users that it “may need to use [the user's] personal information to comply with any applicable laws and regulations, subpoenas, court orders or other judicial processes, or requirements of any applicable regulatory authority.” Kraken II, Reply at 7 n. 10 (quoting Privacy Notice (kraken.com) [https://perma.cc/WL8E-H8WU]). The Court also finds that Kraken's vague suggestion that disclosure might violate the EU's GDPR is not sufficient to establish that the summons needs to be narrowed on this basis as it did not offer any meaningful briefing in support of this argument.

Finally, while Kraken has questioned the Government's ability to protect the private information it obtains from Kraken based on a report about problems with the Enterprise Case Management System, Agent Cincotta states in her Reply Declaration that the IRS does not use that system for storage of John Doe summons information. Kraken II, Cincotta Reply Decl. ¶ 71. Therefore, the Court concludes that the concerns Kraken raises about the privacy interests of nonU.S. users do not warrant limiting or quashing the proposed summons.

Burden

Kraken challenges the definition of “user” in the summons on the basis that “full compliance could take months or even years” given the large number of accounts at issue and the extensive information requested. Kraken II, Opposition at 10 (citing Siemers Decl. ¶ 10). Because the burden of disclosure varies depending on the specific type of information sought by the Government, the Court addresses this issue in its discussions of the specific requests in the summons.

c. Requests One through Three (User Identity Information)

i. Background

Kraken's Contentions

Kraken argues that the information sought in the Government's first three requests is overbroad, going far beyond the “basic user information” that the court in Coinbase ordered produced. Kraken II, Opposition at 11-16. It also contends that because of the way much of the requested identity information is stored in its internal systems, responding to these requests will be extremely burdensome. Id.

As to Request One, Kraken notes that the summons in Coinbase was similarly broad, asking for “[a]ccount/wallet/vault registration records for each account/ wallet/vault owned or controlled by the user . . . limited to name, address, tax identification number, date of birth, account opening records, copies of passport or driver's license, all wallet addresses, and all public keys for all accounts/wallets/vaults.” Id. at 11-12 (quoting Coinbase, 2017 WL 5890052, at *2). According to Kraken, the court in Coinbase rejected the IRS's “argument that it ‘need[ed] these records to verify an account holder's identity' and to determine if the holder had others make transactions on their behalf[,]” instead finding that the Government could only obtain personal information “necessary to determine if a taxable gain was reported: ‘name, date of birth, taxpayer identification and address.'” Id. at 12 (quoting Coinbase, 2017 WL 5890052, at *2).

Similarly, Kraken contends, the user pseudonyms or IDs, historical personal information changes, IP addresses, and user payment methods sought by the Government here constitute “extraneous identity information” that the Government does not have a legitimate need for at this stage of its investigation. Id. ⁸ Kraken argues that “[p]roduction of such information at this point would serve only to provide unfettered access to the private financial and personal information of thousands of otherwise law-abiding users that the IRS has no interest in auditing.” Id. Kraken contends the same approach should be taken here as was taken in Coinbase, and that the Government will only be able to establish that further identity information is necessary to its investigation when it has determined there was a potential taxable gain and it still has doubt as to a taxpayer's identity. Id.

8 Kraken stipulated at the hearing, however, that it does not object to providing the information sought in Request 1(a) of the proposed summons, that is, name (including full name, any pseudonym, or any user ID); date of birth; taxpayer identification number; physical address; telephone number; and email address.

Kraken also argues that the Government's requests for “historical user information in Request No. 1(b)-(d) are unreasonable and unenforceable as they are overbroad and disproportionate to the end sought here.” Id. First, it contends these requests are overbroad because they are “indefinite as to time and unbounded by the purported time and value limitations set forth in the definition of ‘User.'” Id. (citing as examples, Request No. 1(b) (seeking the history of all changes to personal information “since the inception of the account”); Request No. 1(c), (seeking “[c]omplete User history” for IP addresses); and Request No. 1(d) (seeking User payment methods “regardless of date.”)). According to Kraken, “[o]ther courts have held similar requests that were unlimited in time and not directly related to the tax years in dispute to be irrelevant and overbroad.” Id. at 13 (citing Zietzke v. U.S., No. 19-CV-03761-HSG(SK), 2020 WL 264394, at *9 (N.D. Cal. Jan. 17, 2020), report and recommendation adopted, 2020 WL 6585882 (N.D. Cal. Nov. 10, 2020); United States v. Monumental Life Ins. Co., 440 F.3d 729, 736 (6th Cir. 2006)).

Kraken further contends the Government's assertion that it needs information beyond basic identity information, which it labels as merely “nice to haves[,]” should be rejected to the extent the Government relies on a conclusory statement by Agent Cincotta that “[i]t is not uncommon for taxpayers to use aliases, false addresses or post office boxes, fictitious entity names, or other means to disguise their true identities.” Id. at 13 (quoting Kraken II, Cincotta Petition Decl. ¶ 42; and citing Id., ¶¶ 92-95). According to Kraken, this statement is insufficient because the Government has offered no evidence that suggest “Kraken's users have supplied false information or how expanding the request solves that problem.” Id. (emphasis in original). Kraken notes that “for Intermediate and Pro level accounts, users are required to provide verification information to confirm identity and address. So, the fear that those users are somehow falsifying information to disguise account ownership is baseless.” Id. Furthermore, Kraken contends, “[e]ven if some small subset of users provided fictious information, that does not justify the production of all this additional information, as to all 59,331 users.” Id. at 13-14.

Likewise, Kraken rejects Agent Cincotta's “speculat[ion] that an issue may arise with missing user data, solely based on the IRS's experience with Coinbase.” Id. at 14 (citing Kraken II, Cincotta Petition Decl. ¶¶ 43-51). The assumption that the data obtained from Kraken will suffer from the same defects as the information produced in Coinbase is not reasonable, Kraken contends, given that Coinbase informed the IRS “that certain account information for its oldest accounts may be missing because it did not necessarily collect all of that information at that time.” Id. (citing Kraken II, Cincotta Petition Decl. ¶ 46). In contrast, Kraken asserts, it “required the same information for each user at its different account levels during the relevant timeframe: name, date of birth, address, email address, and phone number [and] [t]axpayer ID numbers were also collected for all Intermediate and Pro level accounts.” Id. Even as to Kraken accounts where a taxpayer ID was not collected, Kraken asserts, the situation is not analogous to Coinbase; in particular, it points to Agent Cincotta's statement that lack of taxpayer IDs presented a problem as to Coinbase primarily when other information was also missing. Id. at 14 n. 9 (citing Kraken II, Cincotta Petition Decl. ¶ 47).

In addition, Kraken argues, the Government does not “come close to providing a sufficient explanation as to how the other requested identity information (historical user profile changes, IP address, or user payment methods) would even assist the IRS in identifying taxpayers when certain information is missing.” Id. at 14-15. For example, if “the IRS had a user's name, address, and birthdate, but was missing a taxpayer ID-being able to track an IP address to a general geographic area will not enhance its ability to identify a user[,]” Kraken contends. Id. at 15. Similarly, Kraken asserts, where users have provided “false identifying information[,]” there is nothing to suggest that such users are likely to be identified through the IRS's additional information requests.” Id.

Kraken also rejects a number of other justifications offered by the Government for needing this information. First, to the extent the Government suggests that “IP address information is a good way to search data from other exchanges and link transactional records from foreign exchanges to determine compliance,[,]” that justification fails because “[t]his is far beyond the basic identity information the Court in Coinbase determined was needed for the sole purpose of identifying taxpayers” and moreover, “it is unreasonable to insinuate that the IRS plans to go through IP address histories for almost 60,000 users and cross compare those with IP addresses used in transaction records from other exchanges.” Id. at 15 (citing Kraken II, Cincotta Petition Decl. ¶¶ 108, 112, 118).

Second, Kraken argues, “the only asserted basis for changes to user information is that Kraken's data may not match IRS's data for taxpayers . . . [b]ut this only speculates there may be some discrepancy and does not account for the existence of multiple user data points that could be used for identification.” Id. (citing Kraken II, Cincotta Petition Decl. ¶ 110).

Kraken also challenges the Government's assertion that account funding sources can shed light on tax compliance by permitting identification of cross-linked bank accounts. Id. (citing Kraken II, Cincotta Petition Decl. ¶¶ 121-122). This assertion, Kraken contends, is based on the unsupported assumption that “a user with lots of linked accounts and no tax reporting is somehow unlikely to be compliant.” Id. Moreover, Kraken argues, this information “is unnecessary to determine identity or a potentially taxable gain in the first instance” and also exceeds the scope of the IRS's investigative purpose to the extent that it is aimed at discovering “alternative taxpayers associated with the accounts.” Id.

Finally, Kraken argues that it would be overly burdensome for it to produce some of the requested user information in Request No. 1(b)-(d). Id. at 16-17. For example, because user records are not stored in manner that allows historical user information to be easily accessed, Kraken would have to manually pull account logs to determine whether any changes have been made, a process it estimates would take approximately 5,000 hours. Id. at 16 (citing Siemers Decl. ¶¶ 13-19). Similarly, it asserts, its storage of payment methods is not designed for a global query of historical payment information, meaning that compliance with that aspect of the summons would “require at least several weeks of work by a large[ ] team of data engineers, analysts, and core back-end engineers” to design a new search query. Id. (citing Siemers Decl. ¶¶ 20-22). The same is true of historical IP addresses, according to Kraken. Id. at 16-17 (citing Siemers Decl. ¶¶ 23-24).

Kraken also objects to Request No. 2, seeking information from Know-Your Customer (“KYC”) questionnaires relating to “employment, net worth, and source of wealth for individual Users” and “for business Users, . . . legal name, business address, country, website, contact information, industry, goods and services, government-issued business registration or tax identification number, and source of funds[.]” Id. at 17. Kraken points out that the court in Coinbase rejected the argument that such data was relevant at this stage, finding that KYC records were “broader than necessary” to determine identity and unreported taxable gains. Id. (citing Coinbase, 2017 WL 5890052, at *7.) Kraken emphasizes that “the IRS had little issue identifying 90% of taxpayers in Coinbase without this information, and with less identifying data than Kraken maintains. If the IRS ‘later determines that it needs more detailed records on a taxpayer,' it may issue a second summons to the taxpayer or Kraken with notice - an approach Coinbase acknowledged was preferrable to a John Doe Summons in any event.” Id. at 17-18 (citing Coinbase, 2017 WL 5890052, at *7).

Furthermore, Kraken contends, the KYC information the Government seeks beyond basic user profile information “is not necessary to its purposes and is premature at this stage.” Id. at 18. According to Kraken, “[t]his highly personal information will not reveal potential tax liabilities for the IRS to go after.” Id. Pointing to the Government's request for “employment, net worth and source of wealth” data for individual KYC questionnaires, Kraken argues that “[t]his has no bearing on potential tax liabilities from cryptocurrency transactions. Nor would net worth and source of wealth shed light on any particular tax year in dispute.” Id. Instead, it asserts, “the only potential use of this information would be to help confirm already known data or once there are doubts as to who exactly is responsible for a potential tax liability.” Id. To the extent that the Government “merely hopes to discover details about these users that may help its investigation[,]” Kraken contends, “[t]his is not the ‘narrowly tailored' request 26 U.S.C. § 7609(f) requires.” Id. at 19 (emphasis in original).

Kraken also argues that producing the information sought in Request No. 2 would be excessively burdensome, because “[u]nlike basic personal information and transactional ledgers, this KYC data must be pulled on an account-by-account basis for all Users for which that information exists” and “Kraken's systems are not natively designed to handle such a global query into or retrieval of this account-supporting documentation.” Id. at 19 (citing Siemers Decl. ¶ 25).

Kraken also opposes in its entirety Request No. 3, seeking “[a]ll exception reports produced by your anti-money laundering (‘AML') system, and all records of investigation of such exceptions.” Id. at 19-21. Kraken notes that the Government requested the same information in Coinbase before narrowing its summons to exclude that information, “tacitly acknowledg[ing] that AML records were not needed for its investigative purpose.” Id. at 19 (citing Coinbase, 2017 WL 5890052, at *1). The same is true here, Kraken asserts. Id. Kraken argues that the Government cannot seek such information until it determines that “a user has a potentially reportable taxable gain.” Id. at 20.

Kraken rejects the justifications offered by Agent Cincotta for needing the information covered by Request No. 3 as “nebulous[ ]” and “conclusory rhetoric.” Id. According to Kraken, Agent Cincotta claims “that exception reports would ‘allow[] the IRS to leverage the industry expertise' of Kraken as to what activities are ‘abnormal or suspicious'- which she asserts can be combined with (unspecified) ‘other information available to the IRS' to determine taxpayer compliance.” Id. (citing Kraken II, Cincotta Petition Decl. ¶¶ 132-135). Kraken argues that the IRS “simply assume[s] . . . that users associated with AML records may not be paying their taxes” but that “there could be any number of reasons that a user's account may get flagged under Kraken's AML system[,]” including “if a user makes too many log-in attempts, due to receipt of legal process, when there is a change in account verification levels, or for confirmation of OFAC-related checks.” Id. (citing Siemers Decl. ¶ 27).⁹

9 With respect to the AML reports, Siemers states:

27. I understand that the IRS is also requesting production of Kraken's AML “exception reports” and “records of investigation of such exceptions.” Kraken does not have documents called AML “exception reports” and so cannot produce any such records. As previously stated, Kraken does maintain an AML log for each account. However, there are numerous reasons, including minor or technical issues, that entries are generated in these logs. For example, these logs track security-related actions, Suspicious Activity Report (“SAR”) filings, actions taken in response to receipt of legal process, changes in account verification levels, rejected or recalled deposits, and confirmation of OFAC-related checks.

Siemers Decl. ¶ 27.

Kraken also rejects as “speculative and premature” the Government's reliance on Agent Cincotta's statement that “AML investigative information typically ‘contains information provided by the user explaining the nature of the questionable activity.'” Id. at 21 (quoting Kraken II, Cincotta Petition Decl. ¶ 134). Kraken contends such information would only be relevant when the IRS “has already identified a user and potentially taxable gains.” Id.

In addition, Kraken argues that this request, like Request No. 2, is “manifestly overbroad and far reaching because it is not confined to any relevant time period and is unbounded by any transaction type or amount[.]” Id. And like Request No. 2, Kraken contends, Request No. 3 would impose an excessive burden on it because “Kraken's AML records are not maintained in a way to allow for global search or retrieval across identified ‘Users.'” Id. (citing Siemers Decl. ¶ 28).¹⁰Kraken represents that in order to pull this information, it would have to “go into each of the 59,331 accounts to manually analyze and collect this information[]” which would include decrypting the data - a process that would require “several thousand hours of work.” Id. (citing Siemers Decl. ¶¶ 19, 33).¹¹

10 Siemers states in his declaration:

28. To the extent the IRS's request seeks Kraken records associated with events that trigger its AML system, and any associated investigation into material issues, determining whether accounts have associated AML records and retrieving those documents would be very time consuming and burdensome. As stated above, AML records are not kept in a manner that allows for global inquiry or retrieval across any identified users. This would require a manual, account-by-account review of the AML logs for each of the 59,331 accounts covered by the Summons. This AML data is also encrypted and would require decryption on an account-by account basis similar to the process described in Paragraph 19. This process would cause significant interruption to Kraken's business and direct valuable engineering time away from operational priorities.

Siemers Decl. ¶ 28.

11 Siemers states in his declaration:

19. Even if Kraken were required to analyze the AML logs only for the 59,331 accounts that meet the IRS's definition of User to determine (i) whether any changes were made to the account holder's personal information, and (ii) if so, what those substantive changes were, it would be extremely time consuming. Based on my experience, it is reasonable to assume it would take approximately five minutes per log for a Kraken employee to decrypt the log, review it for historical residency information, and collect that information. Thus, for 59,331 logs, it would require approximately 5,000 hours of work. In addition, historical changes to personal data have not been stored by Kraken in its AML logs for the entire period covered by the Summons, so the data collected would be incomplete. Since this is not data that Kraken formally maintains, I do not know how accurate the information retrieved would be or if we would successfully be able to collect historical personal information for all accounts. ... 33. I understand that the IRS also requests any invoices, billing statements, receipts, or other similar documents relating to account funding transactions. It is unclear the full extent of what documents the IRS is seeking based on these descriptions. Based on my knowledge and experience at Kraken, Kraken does not send invoices, billing statements, or receipts to its users. Any documents that may be captured by this request are individual records and not globally searchable data. Collection of these documents, to extent they exist, would be a very time consuming and likely require a manual review of each of the 59,331 accounts covered by the IRS summons. It is difficult to estimate the burden of this request since it is unclear the universe of documents being sought. But as previously stated, even if only a few minutes were required per account to conduct a manual review, this would lead to thousands of hours of work.

Siemers Decl. ¶¶ 19, 33.

The Government's Response

The Government rejects Kraken's argument that Request No. 1 is overbroad, arguing that the identifying information sought in this request, such as whether a user has changed their name on an account or IP address information, can be used to identify a taxpayer, which “might throw light upon the correctness of a return.” Kraken II, Reply at 7-8 (citing Kraken II, Cincotta Petition Decl. ¶¶ 111-119).¹²Likewise, the Government asserts, “[t]he IRS uses information about how a user funds their account, or what payment methods they use, to uncover related taxpayers or nominee situations, along with determining whether that user is in tax compliance.” Id. at 8. The Government offers the following example: “if bank accounts of one taxpayer are linked to another taxpayer's cryptocurrency exchange account and vice versa, or a taxpayer with minimal reported income has many linked funding sources, or a taxpayer has funding sources that are not in his own name, that taxpayer is more likely to not be complying with the internal revenue laws.” Id. (citing Kraken II, Cincotta Petition Decl. ¶¶ 120-25). The Government argues that “[h]aving this information certainly might throw light upon the correctness of a return.” Id.

12 Agent Cincotta explains how identifying information covered by Request No. 1 can be helpful in uncovering tax non-compliance as follows:

111. The summons request for complete user history is directed at identifying internet protocol (“IP”) addresses used to access the account. This information is helpful when initially confirming a user's identity and making an initial determination regarding whether the identified user is in tax compliance. 112. In situations where the IRS has had difficulty adequately confirming a taxpayer's identity, it has been able to employ IP address information as an additional data point to confirm that the IRS has connected information to the proper taxpayer. IP address information indicates the geographical location where a device accesses the internet (generally through an internet service provider). The geographical location of an IP address is publicly available so the IRS can use IP address information to search publicly available records to determine a location. 113. For example, a taxpayer accessing his Kraken account from San Francisco, California will have an IP address indicating that the access was made from San Francisco, California. 114. Based on my review of Kraken's account verification requirements, it is my understanding that IP address information is actively being collected and monitored by cryptocurrency exchanges such as Kraken. 115. Cryptocurrency exchanges use IP address information internally to determine from where an individual is attempting to access their platform so they can block access from jurisdictions where they do not operate. It is my understanding that Kraken employs this same process to monitor and block users from jurisdictions where it does not operate such as Washington State and New York. 116. Using this information, the IRS will be able to confirm a user's identity in situations where the user's identity is not certain based on the other personal information by confirming that the account was accessed from IP address locations that coincide with the taxpayer's known physical address. 117. Conversely, where the IP address information does not match, the IRS will be able to conduct additional due diligence to determine the proper account owner or whether there was an incidence of identity theft. 118. Aside from its utility in confirming an individual's identity, the IRS will be able to use this information to make a determination regarding a user's tax compliance. The IRS is in possession of data relating to foreign cryptocurrency exchanges. That data lacks a taxpayer ID number, but does include information such as telephone number, email address, and IP address. Being able to match the IP address information of a Kraken user to IP address information (and other data points contained in the IRS's information) will permit the IRS to link substantive transactional information from multiple sources for a single individual taxpayer and make a more accurate initial determination regarding that individual's tax compliance. 119. In my experience as a Revenue Agent, it is important for the IRS to receive this information at the same time it receives the other identity information because it helps identify users and can be searched against existing data in the IRS's possession to determine whether a user is in tax compliance.

Kraken II, Cincotta Petition Decl. ¶¶ 111-119.

The Government rejects Kraken's assertion that Agent Cincotta's statements about the use of aliases, false addresses or post office boxes, fictitious entity names, or other means to disguise account holders' true identities are insufficient because she does not address whether these practices are common among Kraken users specifically. Id. 8-9. According to the Government, given that Agent Cincotta has worked as a revenue agent since 2005, “particularly working in the offshore and electronic payments systems area and on other John Doe summonses[,]” these statements are persuasive evidence. Id. (citing Kraken II, Cincotta Petition Decl. ¶ 42; Kraken II, Cincotta Reply Decl. ¶ 1). Furthermore, the Government argues, “although Kraken is correct that the IRS doesn't know if Kraken's users have supplied false information, Kraken doesn't know either - at least not for the user accounts that are at its Starter or Express levels[,] [as] Kraken admits it only requires users at the Intermediate and Pro levels to provide identity verification information.” Id. at 9.

The Government dismisses Kraken's argument that the basic identity information that was produced in Coinbase is sufficient because “the IRS was able to identify most of the Coinbase users from the basic identifying information it received.” Id. at 9. It asserts, “what a summoned party believes is necessary for an IRS examination is not the standard under Powell and its progeny.” Id. (citing Tiffany Fine Arts, Inc. v. United States, 469 U.S. 310, 323 (1985)).

In a footnote, the Government rejects Kraken's assertion that Request No. 1 is overbroad because of the lack of a date restriction for the historical information it seeks. Kraken II, Reply at 8 n. 11 It asserts, that these requests are proper because “the summons requests that are unlimited in time are tied to the years under investigation, even though the IRS cannot more specifically identify the year in which the users may have submitted identity confirming information to Kraken.” Id. It notes that in Zietzke, cited by Kraken in support of its argument on this issue, the court “found that the IRS could modify its summons request to tie the information requested in prior years to the year under exam.” Id.

With respect to Request No. 2, the Government rejects Kraken's argument that “employment, net worth, and source of wealth data for individual user accounts [ ] is irrelevant to potential tax liabilities[,]” asserting that Agent Cincotta “explains in detail just how the IRS would use that information and why it may be relevant to the IRS's investigation.” Id. at 9 (citing Kraken II, Cincotta Petition Decl. ¶¶ 126-31).¹³As to Kraken's objection that this request isn't limited in time, the Government responds that this does not render the request overbroad because “the IRS can't possibly know when in time Kraken collected this information from each user.” Id. at 10 n. 14.

13 Agent Cincotta describes the Government's need for this information as follows:

127. With respect to the individual KYC questionnaire, the summons only requests the responses to the employment, net worth, and source of wealth questions. 128. Given that the KYC questionnaire is only required for pro level accounts, I expect that these responses will only be provided for a limited number of account holders. However, pro level account holders are permitted the largest movement of funds as well as access to Kraken's “dark pool”-a discrete market where the order books are secret, making it easier to buy or sell larger unit volumes without influencing the market. 129. Given the likely larger movement of funds and higher dollar values, and the overall increase in fair market value of bitcoin during the summoned period, it is almost certain that these pro level account individuals will have experienced a taxable gain. Having additional information such as employment, net worth, and source of wealth will help the IRS determine whether they are in tax compliance. 130. Employment information can be matched against Forms W-2 issued by the identified employer to both confirm the user's identity and identify the user's income level. Net worth and source of wealth questions can help the IRS understand whether the identified taxpayer has a level of wealth commensurate with his earnings or possibly unreported income. 131. With respect to the business KYC questionnaire, all the information obtained by the questionnaire is the same basic information requested for individual users. Each of the pieces of information identified in the questionnaire, if not already provided as part of the user profile information identified in summons request number 1, is necessary to properly identify the business taxpayer that controls the account as well as the actual individuals (contacts) that have access to the account.

Kraken II, Cincotta Petition Decl. ¶¶ 127-131.

As to Request No. 3, the Government argues that its withdrawal of the same request to Coinbase has no bearing on whether it is permissible here. Id. at 10. Moreover, it asserts, Agent Cincotta's declaration is sufficient to establish that Kraken's AML-triggered investigation records may be relevant to the IRS's investigation. Id. (citing Kraken II, Cincotta Petition Decl. ¶ 133).¹⁴

14 Agent Cincotta states in her declaration:

133. Exception reports identify questionable transactions engaged in by a user that warranted additional research and investigation by the money services business. Based on my experience, reviewing these reports allows the IRS to leverage the industry expertise of the business involved (here, a cryptocurrency exchange) regarding what type of activity is abnormal or suspicious and allows the IRS to combine that expertise with other information available to the IRS to determine. whether the subject taxpayer is complying with the internal revenue laws.

Kraken II, Cincotta Petition Decl. ¶ 133.

On the question of burden, the Government argues generally that “[t]he production of 160 million transaction records is not out of line with what the IRS receives, or expects to receive, when it issues a John Doe summons” and that “[t]he same can be said for the production of 59,351 user accounts.” Id. at 13 (citing Kraken II, Cincotta Reply Decl. ¶ 63). It responds further that “Kraken's costs can be offset by reimbursement or other IRS assistance.” Id. (citing 26 U.S.C. § 7610 ¹⁵; 26 C.F.R. 301.7610-1 ¹⁶). It also notes that “under the FinCEN regulations, Kraken is required to obtain and retain many of the summoned records.” Id. at 12 n. 16 (citing 31 C.F.R. § 1010.4100(e)(1)(i) and § 1022.400; Kraken II, Cincotta Petition Decl. ¶¶ 62-67). According to the Government, “under the FinCEN regulations, Kraken must be able to retrieve the records it is required to keep (‘have the information readily available'). Id. (quoting FIN-2016-G001 (Mar. 11, 2016)).

15 Under 26 U.S.C. § 7610, “The Secretary shall by regulations establish the rates and conditions under which payment may be made of . . . reimbursement for such costs that are reasonably necessary which have been directly incurred in searching for, reproducing, or transporting books, papers, records, or other data required to be produced by summons[,]” except that no payment may be made “if . . . the person with respect to whose liability the summons is issued has a proprietary interest in the books, papers, records or other data required to be produced, or . . . the person summoned is the person with respect to whose liability the summons is issued.”

16 This regulation addresses the types of costs that may be reimbursed in connection with compliance with an IRS summons and applicable rates.

ii. Discussion

As discussed above, the Court must determine whether the Government's summons is narrowly tailored, that is, whether it is “no broader than necessary to achieve its purpose.” United States v. Bisceglia, 420 U.S. 141, 151 (1975). The Court finds that to the extent the first three requests are aimed at establishing the identities of the Kraken account holders who fall within the Doe definition, the information sought in these requests is much broader than what is necessary to achieve that purpose for the vast majority of Doe users.

First, the record reflects that for Intermediate and Pro level accounts, at least, Kraken will be able to provide significant identifying information, including taxpayer IDs for some users, rendering superfluous the requests for the additional (and more intrusive) information sought in whether the subject taxpayer is complying with the internal revenue laws. these requests aimed at uncovering the identity of the account holders. While it is unclear how many Kraken accounts are at the Pro and Intermediate levels as compared to starter level accounts, the Government's requests that go beyond the basic information sought under Request 1(a), that is, the requests for historical information about changes to users' personal information, IP addresses and payment methods (Request Nos. 1(b)(-(d)), are clearly broader than necessary as to these users. Furthermore, to the extent it appears to be undisputed that Kraken verifies the identities of users at these account levels, Agent Cincotta's statement that taxpayers sometimes use aliases and fictitious entity names, see Kraken II, Cincotta Petition Decl. ¶ 42, does not establish that this additional information is required to determine these users' identities.

Second, even taking into consideration the more limited (and perhaps less reliable) information collected by Kraken from users with starter level accounts, the historical information sought in Request Nos. 1(b)(-(d) is broader than necessary. Kraken has provided evidence that during the relevant period it collected first and last name, date of birth, address, email address, and phone number for all users. Siemers Decl. ¶ 5. Although Agent Cincotta has stated that taxpayers sometimes provide false information as to their identity, this evidence at most suggests that the basic identity information collected by Kraken might not be sufficient to establish the identities of some users. On the other hand, the Government does not appear to dispute that as to the vast majority of Does, this information will allow it to identify these account holders. Indeed, in Coinbase, where the information collected by Coinbase appears to have been less complete than the information collected by Kraken, approximately 90% of the Does were identified using taxpayer IDs and after further efforts to obtain missing basic information (e.g., no name or use of a pseudonym, missing birth date or physical address) the Government was able to reduce the number of accounts that could not be identified to 750 (approximately 5% of the Does covered by the summons). Kraken II, Cincotta Petition Decl. ¶¶ 43-48. As to the remaining accounts that the Government has not been able to identify, the Government could have issued another Doe summons or summonses with notice to the account holders, but it apparently chose not to do so. Therefore, as to Request No. 1, the Court concludes that the Government has not established that it needs information beyond that covered by Request 1(a) to identify the Does.

The Court further finds that the information sought in Request Nos. 2 and 3 goes beyond what is reasonably necessary to achieve the purpose of these requests. This includes the Government's request for KYC due diligence questionnaire information, including individual User's employment, net worth, and source of wealth (Request No. 2), and AML Logs and records of investigations related to AML monitored actions (Request No. 3). While this information might shed light on a tax violation by an account holder, at this stage of the Government's investigation, it is only speculating on that point. To move beyond speculation, it must first address whether there is anything in the user's transaction history - whether considered on its own or in combination with other information the IRS has collected on that user after it has identified the account holder - that makes it reasonable to conclude that the information it seeks in these requests will actually yield information relevant to that user's tax compliance. At that point, the Government can issue another Doe summons or follow the preferable path of issuing a summons to the account holder.¹⁷

17 Because the Court finds that of the first three requests only Request 1(a) is relevant, and Kraken does not assert that production of that information will be overly burdensome, the Court need not address Kraken's arguments relating to the burden of producing the information requested in Request Nos. 1(b)-(d), Request 2 or Request 3. The Court also need not reach whether Request No. 1(b)-(d) is overbroad for the additional reason that these requests contain no time restriction. Although Kraken brings the same challenge to Request Nos. 4 and 5, the Government has stipulated that it only seeks records of account funding and activity for the period covered by summons, January 1, 2016, to December 31, 2020. Kraken II, Cincotta Reply Decl. ¶¶ 99-100.

The Court therefore finds that the relevant documents in Request Nos. 1-3 are those listed in Request No. 1(a), which must be produced. The items in Request Nos. 1(b)-(d), Request 2 and Request 3 are not relevant at this stage of the Government's investigation.

d. Requests Four and Five (Transactional Information)

i. Background

Request Nos. 4 and 5 are aimed at users' transactions. In particular, Request Four seeks records relating to the following account activity: a) date, time and amount of users' purchases or sales of cryptocurrency for fiat currency (that is, U.S. dollars or foreign legal tender); b) date, time and value of any lending, borrowing or margin position entered into the account; c) date and time, amount, U.S. dollar value, transaction hash (ID), and blockchain addresses of any cryptocurrency units transferred into or out of a Kraken account from another Kraken account or from outside Kraken; and d) cryptocurrency received in the account as the result of “a chainsplitting event such as a hard fork or promotional event.” Request Five seeks records relating to account funding, that is, all deposits, withdrawals, or transfers in U.S. dollars or foreign legal tender, as well as “invoices, billing statements, receipts, or other documents memorializing and describing such transactions.”

Kraken's Contentions

Kraken objects to both requests on the grounds that they do not contain temporal limitations. Kraken II, Opposition at 22, 23. It also challenges Request No. 4(c) as overbroad because it seeks “transaction hash (ID)” and “blockchain addresses[.]” Id. at 22. As to the former, Kraken contends the Government does not justify its need for this information and points out that in Coinbase, the Government did not request it. Id. As to the blockchain addresses, Kraken argues that this information is similar to the wallet addresses that the Government requested as identity information in Coinbase and the court found to be irrelevant and overbroad. Id. (citing Coinbase, 2017 WL 5890052, at *6).

Kraken also argues that production of the information sought in Request No. 4 would be extremely burdensome, in part because of the lack of date restrictions and in part because of specific challenges associated with this request. Id. In particular, with respect to 4(d), Kraken asserts that its “transactional data would reflect all executed transactions, but ‘chainsplitting event[s]' are not specifically demarcated as those particular events.” Id. at 23 (citing Siemers Decl. ¶ 30).¹⁸Likewise, it asserts, “[w]ith respect to 4(c), ‘transaction hash (ID)' and ‘blockchain addresses' for transfers will not be reflected in the transactional ledger.” Id. (citing Siemers Decl. ¶ 31).¹⁹Therefore, Kraken asserts, it cannot provide “complete and accurate data regarding the transaction hashes and blockchain addresses on a transaction-by-transaction basis” and it would “have to develop searching tools above and beyond what it employs in the normal course of business” to comply with Request No. 4(c). Id. It further represents that “because blockchain addresses are not part of a transactional ledger, such data would have to be pulled on an account-level basis, which would be a time consuming and expensive process.” Id. Kraken acknowledges that it is “currently working to backfill transaction hashes or blockchain addresses into its transaction data” but “does not expect to be able to provide this data completely and accurately for at least several months.” Id.

18 Siemers states as follows:

I understand that the IRS is specifically requesting information from all executed transactions, specifically “lending, borrowing, or margin position” data, along with data relating to the receipt of cryptocurrency resulting from a “chainsplitting event such as a hard fork or promotional event.” Kraken's transactional ledgers for each account include any deposits, withdrawals, or transfers of cryptocurrency conducted by the account, which would reflect any lending, borrowing or margin position that resulted in a completed transaction. It would also capture transactions resulting from chainsplitting events such as forks or “airdrops” that resulted in digital assets being credited to the account. However, chainsplitting events are not specifically identified as such in the transaction ledgers. For example, depending on the details of the chainsplitting event and how that event was handled by Kraken, corresponding transactions may

be captured as deposits, transfers, or adjustments to the account. Siemers Decl. ¶ 30.

19 Siemers states:

I understand that the IRS is requesting data related to “transaction hash (ID)” and “blockchain addresses” for cryptocurrency transactions. Like payments methods, the transaction history ledgers that Kraken maintains for each account do not include the transaction hash or blockchain addresses on a transaction-by-transaction basis. Thus, Kraken's systems are not natively designed to handle a global query or collection of such information. Kraken is currently working to backfill transaction hashes or blockchain addresses into its transaction data, but that work is ongoing. At this time, Kraken cannot provide complete and accurate data regarding the transaction hashes and blockchain addresses on a transaction-by-transaction basis. Kraken does not expect to be able to provide this data completely and accurately for at least several months, if not longer.

Siemers Decl. ¶ 31.

As to Request No. 5, Kraken acknowledges that “the transactional ledgers Kraken maintains for each account include deposit, withdrawal, and transfer activity and necessarily reflect account funding” but contends that the request is overbroad and unnecessarily burdensome to the extent it “seeks records beyond those ledgers.” Id. at 23. According to Kraken, “[b]asic transactional data should be enough to establish whether a potentially reportable gain exists and who is responsible for that gain.” Id. (citing Coinbase, 2017 WL 5890052, at *7). Kraken represents that it “does not keep record[s] of account funding in the same manner in which user profile or transactional data is stored” and “its systems are not natively designed to handle a global query into or collection of this information across identified users.” Id. (citing Siemers Decl. ¶ 32).²⁰Therefore, it asserts, “[t]o extract account funding activity, Kraken would have to design a new search query to collect that data on an account-level basis[,]” which it estimates “would take approximately two full data analyst days to develop a tool and extract the data.” Id.

20 Siemers states: I understand that the IRS is also requesting production of all records of account funding. As noted above, deposits, withdrawals, or transfers to and from an account are reflected in the transactional ledgers associated with each account. Beyond that, the search for and retrieval of any account funding data would be similar to the process for responding to the request for complete user payment methods. Kraken does not maintain a record of all account funding in the same way standard transactional data is stored in the ordinary course of business, and its systems are not natively designed to handle a global query into this information on a transaction by-transaction basis. Kraken would be required to design a search query to collect account funding data on an account-level basis. Based on my knowledge of Kraken's systems, I estimate it would take . . . at least two days of work for a full-time data analyst to develop a tool and to search, retrieve, and extract the information. Siemers Decl. ¶ 32.

Kraken further represents that as to the request for “invoices, billing statements, receipts, and similar documents, [it] does not send invoices, billing statements, or receipts to its users” and thus, “[a]ny documents that may be captured by this request would be individual account records and not globally searchable or extractable.” Id. (citing Siemers Decl. ¶ 33).²¹

21 Siemers states:

I understand that the IRS also requests any invoices, billing statements, receipts, or other similar documents relating to account funding transactions. It is unclear the full extent of what documents the IRS is seeking based on these descriptions. Based on my knowledge and experience at Kraken, Kraken does not send invoices, billing statements, or receipts to its users. Any documents that may be captured by this request are individual records and not globally searchable data. Collection of these documents, to extent they exist, would be a very time consuming and likely require a manual review of each of the 59,331 accounts covered by the IRS summons. It is difficult to estimate the burden of this request since it is unclear the universe of documents being sought. But as previously stated, even if only a few minutes were required per account to conduct a manual review, this would lead to thousands of hours of work.

Siemers Decl. ¶ 33.

The Government's Response

In its Reply, the Government stipulates that although the summons does not include any temporal limitation as to Request Nos. 4 and 5, it seeks only records in the period covered by the summons, that is, 2016-2020. Kraken II, Reply at 10-11 (citing Cincotta Kraken II, Reply Decl. ¶¶ 99-100). As to the request for transaction hash information and blockchain addresses in Request No. 4, the Government justifies its need for that information - even though it did not request the former and was not permitted to obtain the latter in Coinbase - on the basis that “the IRS's understanding of cryptocurrency is evolving and as it develops greater expertise in how to effectively trace transactions on the blockchain its requests for information have evolved too.” Id. at 11 (citing Kraken II, Cincotta Reply Decl. ¶¶ 95-98).²²It represents that “the IRS can better trace transactions on the blockchain to more accurately determine taxpayer compliance if it has “transaction hash information and blockchain addresses.” Id. To the extent it may take Kraken months to backfill this information into its transaction data, the Government says it is “willing to wait.” Id. And to the extent Kraken's transactions do not specifically identify transactions that are the result of chainsplitting, the Government states that “production of the raw transaction information is sufficient.” Id.

22 Agent Cincotta states:

95. Each transaction recorded on the blockchain is identified by a transaction hash (ID). The transaction hash (ID) can be used to retrieve and view the details of a transaction. Transaction hash information and blockchain addresses can be used to trace transactions between sending and receiving addresses, which can be used to identify other locations that a taxpayer may hold virtual currency or to determine whether cryptocurrency was transferred by one taxpayer to another in a potentially taxable transaction. Unlike traditional investment accounts where an account holder is buying and selling securities entirely within that account, cryptocurrency exchanges generally permit users to deposit and withdraw the cryptocurrency units themselves which allows users to shift property among multiple accounts for profit-maximization or other reasons. 96. The need to identify the existence of other accounts owned by a user and to trace the movement of cryptocurrency to those accounts makes calculating a taxpayer's gain for tax compliance purposes extremely difficult. The IRS needs to know this information to identify what other places the user is holding cryptocurrency so it can gather as much information as possible to make a determination regarding the user's tax compliance. 97. To evaluate this information to determine the proper tax characterization of the transactions and whether a user is in tax compliance, the IRS needs this transactional information, including the date and time of the transaction, cryptocurrency involved, amount of cryptocurrency involved, U.S. dollar value, transaction hash (ID), and blockchain addresses. 98. Transaction hash (ID) and blockchain addresses were not requested in the John Doe summons issued to Coinbase, because, at the time such requests were formulated, the IRS's knowledge of cryptocurrency technology and the data needed to effectively trace cryptocurrency transactions was still developing. Without transaction hash (ID) and blockchain address information, the IRS's ability to trace transactions was limited. Analytical software the IRS uses is less effective in tracing transactions without transaction hash (ID) or blockchain addresses,

Kraken II, Cincotta Reply Decl. ¶¶ 95-98.

As to Request No. 5, the Government states that it has sufficiently established its need for account funding information because this information will help “the IRS make the most informed decision on compliance.” Id. (citing Kraken II, Cincotta Petition Decl. ¶ 147²³; Kraken II, Cincotta Reply Decl. ¶¶ 102-106).²⁴ As to Kraken's representation that it does not send invoices, billing statements or receipts to its users, the Government states that “[t]he IRS is not asking Kraken to create any information, so if this information does not exist, then the IRS recognizes it cannot be produced.” Id.

23 Agent Cincotta states:

Summons request number 5 reflected on Exhibit A seeks all records of account funding transactions relating to the deposit, withdrawal, or transfer of fiat currency. The IRS uses this information to understand how a user is funding his or her purchases of cryptocurrency and where money may be getting sent after units are sold. This information is evaluated against other information in the IRS's possession and reported on the user's tax returns to make the most-informed decision the IRS can on whether an individual is complying with the internal revenue laws.

Kraken II, Cincotta Petition Decl. ¶ 147.

24 Agent Cincotta states:

102. In my experience as a Revenue Agent, I have been involved in tax examinations where the financial status of the taxpayer is difficult to determine. This is more common in cryptocurrency examinations because users of cryptocurrency tend to be younger taxpayers that often have non-traditional income sources. 103. Kraken permits users to fund their accounts with either fiat currency or with cryptocurrency. Understanding how the user's account was funded and where it was funded from can provide valuable insight for the IRS when determining whether an individual is in compliance with the internal revenue laws. 104. In my experience, information on how a user funds their cryptocurrency account can also be used to uncover related taxpayers or nominee situations. For example, the IRS conducted examinations of multiple seemingly unrelated taxpayers. Upon receiving summons information from cryptocurrency exchanges, the IRS was able to identify cross-linked bank accounts-that is, bank accounts of one taxpayer linked to another taxpayer's cryptocurrency exchange account and vice versa. Learning this information changed how the IRS approached the separate examinations and changed how the IRS approached any tax adjustments in the examinations. 105. Knowing the source of funds when initially reviewing a taxpayer's account information can provide important insight into determining whether an individual is in tax compliance. A taxpayer with minimal reported income and numerous linked funding sources is more likely to not be in compliance with the internal revenue laws. 106. Also, a taxpayer with funding sources that are not in his own name is more likely to not be in compliance.

Kraken II, Cincotta Reply Decl. ¶¶ 102-106.

Finally, the Government rejects Kraken's challenges based on undue burden, as discussed above. Id.

ii. Discussion

Request No. 4

Based on the Government's Reply, a number of Kraken's challenges to this request appear to be moot: the Government has clarified that it will cover only the period January 1, 2016 through December 31, 2020; it has stipulated that it is willing to wait for Kraken to complete a process that is already underway of backfilling transaction hashes and blockchain addresses into the transaction data; and in connection with Request No. 4(d), it will accept the raw data even though it does not specifically demarcate chainsplitting transactions. The primary challenge that remains is Kraken's assertion that that Government has not adequately supported its request in Request No. 4(c) for “transaction hash (ID)” and “blockchain addresses.” The Court finds, however, that the Government's evidence is sufficient to demonstrate its need for this information. In particular, Agent Cincotta explains that the IRS's understanding of how to trace cryptocurrency transactions has evolved since Coinbase and that the “[a]nalytical software the IRS uses is less effective in tracing transactions without transaction hash (ID) or blockchain addresses.” Kraken II, Cincotta Reply Decl. ¶ 98. Therefore, the Court concludes that this request is not overbroad. Nor is it unduly burdensome - at least to the extent Kraken has already begun a process of “backfilling” this information into its records such that it can be retrieved without manually searching each individual record.²⁵

25 As Kraken's witness indicates that this process is likely to be complete in a matter of months and the Government has stated it is willing to wait that long, the Court declines to reach whether any additional remedy might be appropriate down the road if, for example, the process is slower than expected or is discontinued by Kraken. The parties may raise that issue with the Court should Kraken not produce this information within the next 6 months. However, the parties shall meet and confer and attempt to resolve the issue before raising it with the Court.

Request No. 5

Apart from its challenge to the definition of “user,” Kraken does not dispute that the Government's request for Kraken's transactional ledgers is narrowly tailored. The Government's request sweeps more widely, however, asking for all records reflecting such transactions. The Government has not explained why this additional information is necessary. Neither has it challenged the accuracy or completeness of Kraken's transactional ledgers. Therefore, the Court concludes this request is overbroad to the extent it seeks records that go beyond Kraken's transactional ledgers.

IV. CONCLUSION

For the reasons stated above, the Court GRANTS the Petition in part and orders that Kraken shall produce the following documents for Kraken users with any combination of accounts having at least the equivalent of $20,000 in value of transactions (regardless of type) in cryptocurrency in any one year, for the period January 1, 2016 through December 31, 2020:

1. Name (including full name, any pseudonym, or any user ID);

2. Date of Birth;

3. Taxpayer Identification Number;

4. Physical Address;

5. Telephone Number;

6. Email Address;

7. All documents described in Request No. 4 for the period January 1, 2016 through December 31, 2020 except that: a) Kraken shall only be required to produce transaction hash (ID) and blockchain addresses to the extent that information has been or is in the future backfilled into its transaction data; and b) as to Request 4(d), Kraken may produce raw data even though it does not specifically demarcate chainsplitting transactions.

8. All transactional ledgers responsive to Request No. 5 for the period January 1, 2016 through December 31, 2020.

In all other respects the Petition is DENIED.

The Court also denies the parties' administrative motions to file under seal for the reasons stated above. The material that has been provisionally filed under seal in this case shall be filed, in unredacted form, in the public record. Each party is responsible for filing in the public record the sealed documents attached to its sealing motion.

IT IS SO ORDERED.