Smart Contract Developers May Be Held Liable by the SEC
Nick Szabo invented them but has reservations about what they’ve become. Vitalik Buterin adopted them but now regrets using their name. Dangerous when coded badly, and powerful when used intelligently, smart contracts have become a critical component of the cryptoconomy. Their code serves as the bond that glues the tokenized ecosystem together. Now, just to add further complexity, the SEC has begun monitoring smart contracts and their creators closely.
Smart Contracts, Legal Liability and the SEC
Smart contracts, explained the U.S. Securities and Exchange Commission (SEC), “provide the means for investors and market participants to find counterparties, discover prices, and trade a variety of digital asset securities.” In its Statement on Digital Asset Securities Issuance and Trading, published Nov. 16, the SEC referred to smart contracts five times, particularly in reference to Etherdelta, whose creator was prosecuted for operating an unregistered securities exchange that ran on smart contracts he’d coded. What this ruling means for developers, moving forwards, is a matter of some debate and great concern.
Code has often been likened to free speech, with advocates adamant that developers should not be held liable for how their code is used. In the case of Etherdelta, the prosecution of Zachary Coburn was relatively straightforward, since he’d personally developed the smart contracts that powered the platform. In future, however, the SEC may not make a distinction between the developer of a piece of code and the end user. If the creator of a smart contract used to facilitate decentralized trading can be identified, that individual could conceivably be held liable for securities violations. As the SEC’s report notes:
An entity that provides an algorithm, run on a computer program or on a smart contract using blockchain technology, as a means to bring together or execute orders, could be providing a trading facility. As another example, an entity that sets execution priorities, standardizes material terms for digital asset securities traded on the system, or requires orders to conform with predetermined protocols of a smart contract, could be setting rules.
More Code Brings Greater Complexity
Morally, code is neither “good” nor “bad”; the rules governing the operation of a smart contract are simply a consequence of the behavior mandated by its creator. These rules, and their permeation into every facet of the cryptoconomy, have forced a rethink of the way cryptocurrencies and their protocols are understood. With the emergence of sidechains such as Rootstock, federated chains such as Blockstream’s Liquid Network, and cross-chain products such as WBTC, the code that controls the cryptocurrency markets is becoming ever more labyrinthine and layered.
As the cryptocurrency industry’s reliance on smart contracts increases, regulators are going to have some difficult decisions to make. Who should be held liable when an entity conducts a securities violation, for example – the trader, the operator of the decentralized platform or the developer who coded the smart contract? Even the father of smart contracts, Nick Szabo, has acknowledged that, despite being wholly digital, they are ultimately an agreement that mirrors a traditional contract, writing: “‘Smart contract’ like ‘contract’ connotes a deal between people, but a deal intermediated and incentivized by dynamic machine-interpreted rules instead of the statically recorded human-interpreted rules of a traditional contract.”
For U.S.-based developers who wish to remain free to code without worrying about legal liabilities, the only solution may be to remain anonymous. This is the approach being favored by the team behind the forthcoming Grin cryptocurrency, which makes use of Mimblewimble privacy tech. It’s also the approach taken by a certain S. Nakamoto 10 years ago upon launching his cryptocurrency. The SEC can’t prosecute whom it doesn’t know.