Case Wallet: A Possible Case Study in Unintended Consequences

The Case Wallet is remarkable for consumer protection. However, it may be subject to state licensing like New York’s BitLicense—something regulators should want to avoid.

One of the main rationales for state licensing of Bitcoin startups is to make sure that businesses that hold customer funds don’t lose or steal those funds. As New York’s Superintendent of Financial Services Ben Lawsky has said, the impetus for the BitLicense is to avoid another Mt. Gox. And as the Conference of State Bank Supervisors argues in its Policy on State Virtual Currency Regulation, when a company takes custody of consumer funds, they take on a position of trust. “This position of trust,” they explain, “is the basis for most financial services laws and regulations, and should be applied regardless of the medium of value.” So, the key to deciding who should be subject to licensing—who should have to get a BitLicense and who shouldn’t—depends on whether a company is taking custody of customer funds and thus assuming a position of trust. For example, a hosted wallet service that makes it easy to use Bitcoin by managing private keys for customers would certainly qualify. A provider of software wallets that never has knowledge of customer’s private keys, on the other hand, assumes no position of trust and therefore shouldn’t need a license. So far, so simple. But then comes multi-sig. Multisignature addresses require m of n keys to sign a transaction before it can be executed. This is a phenomenal innovation that, among other things, improves security in a way that, had it been in use, could have prevented the failure of Mt. Gox. Essentially, consumers could deposit funds in an address that requires two out of three keys to move money. The service provider—say a wallet—would have only one key. This allows the wallet service to review and sign for transactions initiated by the consumer, but does not allow it to lose or steal the funds. In the above scenario, because the wallet service only has one key and could not execute a transaction on its own even if it wanted to, we can argue that it does not have custody of consumer funds, is not in a position of trust, and therefore should not be subject to licensing. But this would mean that the consumer is the one who would have the other two keys, and would be responsible for their safekeeping. An ideal consumer-friendly wallet service, however, probably wouldn’t leave consumers to arrange their own disaster recovery key storage solution. And that’s what we see in the recently launched Case hardware wallet. The Case Wallet is a remarkable product that allows one to use multi-sig and a fingerprint reader to safely store and spend bitcoin. As they explain in their FAQs:
Your bitcoin wallet has three keys and two of them are needed to complete a transaction. One key is embedded on the device so it is secured by the possession factor. No one can gain access to this key without having possession of the device. However, this key isn’t enough to complete a transaction. A second key is stored on our servers and transactions are only signed by the server key if the fingerprint scan is a match so this key is secured by a biometric factor. That means even if your device is lost or our servers are compromised, your bitcoins are safe. A third key sits in an offline vault and is only used if you ever lose your Case to help you recover your bitcoins.
It’s that last sentence that will raise questions in the mind of regulators. The third key may be in a vault, but if it is under Case’s control then it can be argued that Case has custody of the consumer’s funds--even if they never intend to use the third key for anything other than disaster recovery. As a result, Case would be in a position of trust and thus are subject to licensing. In practice, Case does not hold on to the third key. They have contracted with Andreas Antonopoulos’s Third Key Solutions (TKS) to securely store customer disaster recovery keys. But that may not save them from licensing, however. Even if it does not have physical possession of the third key, if Case’s agreement with TKS allows it to retrieve stored keys on demand, then it can still be argued to (functionally) have two out of three keys and thus the ability to move customer funds on its own. TKS, on the other hand, should never be subject to licensing because they only ever hold one key, and because they will hopefully fall under a business-to-business exemption for which we’ve advocated (see page 4 here). What this shows us is how a small, innovative startup, whose sole mission is to improve the security of consumer bitcoin wallets--to prevent another Mt. Gox--may find itself subject to complicated and expensive licensing. And it’s not just the BitLicense. A company like Case my find that it has to get a license in every state. Something that costs millions and takes years. This prospect could really squelch the development of positive innovative technologies like Case. This is why licensing schemes like New York’s BitLicense must include an on-ramp for startups. This is something we’ve advocated for again and again and again and again. A company like Case should be able to get off the ground without having to worry about licensing until they are of a sufficient size to pose a real risk to consumers. Licensing them from day zero is only going to discourage the development of security technologies like the one Case is trying to bring to market. There’s no regulator that should want this. Update: Case has published a blog post explaining their multisig key model. Interesting to note that you can choose to store the disaster recovery key yourself.
Based in Washington, D.C., Coin Center is the leading non-profit research and advocacy center focused on the public policy issues facing cryptocurrency and decentralized computing technologies like Bitcoin and Ethereum. Our mission is to build a better understanding of these technologies and to promote a regulatory climate that preserves the freedom to innovate using permisionless blockchain technologies.