Actually, Don't Release the Kraken: Staking Under Howey, and More
The new year is only just with us, and already the crypto legal space is moving quickly. We wanted to take a look at some recent developments that may impact crypto projects and what they could mean.
(Standard Disclaimer: we're lawyers, but this isn't legal advice. Unless you've signed an engagement letter with us, we don't represent you. If you'd like us to represent you, please contact us through this website.)
First, you may be aware that earlier this month, the SEC charged the companies behind Kraken with offering and selling unregistered securities. To settle the charges, the companies agreed to stop offering securities through their staking services and programs, and to pay $30 million in penalties.
Uniquely among the SEC’s recent crypto cases, the SEC’s complaint doesn’t allege that any particular crypto asset is a security, but rather that Kraken’s “Staking Program,” whereby crypto holders could deposit crypto assets with Kraken, who would stake them on the holders’ behalf, constitutes a security. Applying the Howey test – the standard test used in the US to determine whether an instrument is a security – the SEC alleged that the Kraken Staking Program involved “an investment of money into a common enterprise with an expectation of profits from the efforts of others.”
A key element the SEC noted is that “[i]nvestor tokens are transferred and pooled in wallets,” and that Kraken determined “when and how many of these pooled tokens to stake.” Kraken didn’t “segregate or separately manage an individual investor’s crypto assets.” This is alleged as satisfying Howey prong 2: “into a common enterprise.” Due to this “pooling,” and to Kraken’s advertising “benefits that may not be available to those investors if they staked on their own,” the SEC may be effectively drawing a line between Kraken’s service and conventional validator staking (where the user retains custody and receives fewer potential benefits).
Additionally, as characterized by the SEC, “[t]he Kraken Staking Program is a passive investment.” Investors need only establish an account and purchase or transfer their tokens to Kraken, who would then “perform all of the efforts necessary and expected by the investors to obtain the advertised and promised investment return.” As mentioned above, this may draw a line between conventional validator staking, where the validator would need to make all the relevant choices and would be required to actually stake tokens, operate the nodes, and validate blockchain transactions in order to obtain rewards; and Kraken’s service, which does all of this on behalf of the user, in addition to “[d]etermining the pro rata investor return,” “[d]istributing those investor returns,” and “[p]roviding a user-friendly, one-stop-shop investor interface.” The SEC alleges that these services, performed on behalf of investors, constitute “efforts of others” (and satisfying an element of the Howey test).
One possible takeaway startup founders could consider from this would be to avoid pooling crypto services user assets with others, but rather to set up individual, segregated accounts, or to arrange self-custody (to avoid allegations of satisfying Howey prong 2). Additionally, it may be worth considering having such services avoid any actual decision making, especially to the extent that it affects any return a user receives (to avoid allegations of satisfying Howey prong 4). Instead, a service designed to automate ministerial functions without any decision-making by the project team may be a worthwhile consideration. Had Kraken designed their service with these restrictions in mind, it’s possible that they would be in a different legal position right now.
In other news, the SEC charged Terraform Labs and its CEO with “orchestrating a multi-billion dollar crypto asset securities fraud involving an algorithmic stablecoin and other crypto asset securities.”
One key point here is that the SEC alleges that Terraform Labs and its CEO lied to their users. Terraform claimed that “a popular Korean electronic mobile payment application called ‘Chai’” used the Terraform blockchain “to process and settle commercial transactions.” This would have been a feather in Terraform’s cap: a real-world use that could grow the platform’s value. However, according to the SEC, this didn’t happen: Terraform “deceptively replicated Chai payments onto the Terraform blockchain, to make it appear that they were occurring on the Terraform blockchain, when, in fact, Chai payments were made through traditional means.”
Then, the SEC alleges, when Terraform’s UST token, presented to the public as a stablecoin, “de-pegged” from $1 in May 2021, Terraform and its CEO secretly arranged for a third party to purchase massive amounts of UST to restore its $1 peg. Rather than disclose this to the public, which could undermine confidence in UST, they “publicly and repeatedly touted the restoration of the $1.00 UST peg as a triumph of decentralization and the ‘automatically self-heal[ing]’” algorithm. One year later, UST de-pegged again, but without a third party to save it, it plummeted in value to nearly zero, and never recovered.
You sometimes hear startup gurus promoting “fake it ’til you make it” as a virtue. But if talking up your product is one thing; lying about it is surely another. Depending on the lie, the speaker could end up facing charges for fraud. And unlike many other forms of records, blockchains are immutable, and can potentially cited as evidence of fraud years later.
As a final note, a recent ruling from the Court of Appeal for England and Wales may be of concern to crypto developers subject to that jurisdiction.
This case is the most recent development in the lawsuit by Australian computer scientist Craig Wright, asserting a claim that he is Satoshi Nakamoto, the creator of Bitcoin. Part of the legal theory underpinning Wright’s case hinges on the premise that the current Bitcoin developers owe fiduciary duties to owners of Bitcoin. This is a significant claim: fiduciary duties, under both UK and US law, carry with them a significant responsibility to act with care and loyalty on behalf of another, with potential civil liability in the case that such duties are breached.
In this case, the court found that the Bitcoin developers could, in fact, potentially owe fiduciary duties to Bitcoin holders. While that’s not the end of this case – it will now proceed to trial to determine, among other things, whether the developers actually do owe such duties – the implications should be of concern to crypto developers.
If crypto developers owe fiduciary duties to crypto holders, it could mean that they may face civil liability for their carelessness or for acting under a conflict of interest. Fiduciaries are generally expected to place the financial interests of their “principal” above their own interest, and to exercise care and prudence in their decision-making.
Under this theory, it's at least possible that if certain crypto developers accidentally introduced a bug into the source code of a crypto project that resulted in crypto holders losing money, the developers might find themselves civilly liable for a breach of their fiduciary duty of care. Even if the developers ultimately prevailed, they might not be able to avoid a lengthy, expensive trial over whether they owe such duties at all. Unless overruled or otherwise narrowed, this case may be of concern to any crypto developers subject to the jurisdiction of English courts.
(Cover image by Yaselyn Perez at Unsplash)