Smart Contracts and Distributed Ledger Technology: a Lawyer's Guide

Smart Contracts and Distributed Ledger Technology: A Lawyer’s Guide

Presented by: Kenneth Moyle

Clear Law Institute | 4601 N. Fairfax Dr., Ste 1200 | Arlington | VA | 22203

www.clearlawinstitute.com

Questions? Please call us at 703-372-0550 or email us at [email protected] All-Access Membership Program

● Earn continuing education credit (CLE, CPE, SHRM, HRCI, etc.) in all states at no additional cost ● Access courses on a computer, tablet, or smartphone ● Access more than 75 live webinars each month ● Access more than 750 on-demand courses Register within 7 days after the webinar using promo code “7member” to receive a $200 discount off the $799 base price. Learn more and register here: http://clearlawinstitute.com/member Clear Law Institute, © 2017

Smart Contracts and Distributed Ledger Technology A Lawyer’s Guide

Agenda

Concepts and Confusion Smart Contracts: Theory and Reality The Lexicon • Legal vs. Technical viewpoints • Distributed Ledger • Common Accord • Blockchain Initial Coin Offerings and SAFTs • Cryptocurrency Regulatory Developments • Smart Contracts Statutory Developments Resources

“ The digital revolution is radically changing the kinds of relationships we can have. What parts of our hard-won legal tradition will still be valuable in the cyberspace era? ” - Nick Szabo, 1996

“What is the best way to apply these common law principles to the design of our online relationships?”

Integrity of record

Trust in the Enforceability outcome under law

Integrity of record

Trust in the Enforceability outcome under law

Integrity of record

Trust in the Enforceability outcome under law

The Lexicon Language of distributed ledger technology

Blockchain

Smart Legal Contract Agreement

This Photo by Unknown Author is licensed under CC BY-NC-ND

Blockchain

Smart Legal Contract Agreement

This Photo by Unknown Author is licensed under CC BY-SA This Photo by Unknown Author is licensed under CC BY-NC-ND

Blockchain • Immutable record • Record maintained outside parties’ control

Smart Contract Legal • Prescribed Agreement outcome based on • Enforceable under conditions common law • Outside control of • Disputes resolved interested parties under law

Distributed Ledger

• A distributed ledger is a type of database spread across multiple sites, regions, or participants. • All of the participants on the distributed ledger can view all of the records in question. The technology provides a verifiable and auditable history of all information stored on that particular dataset. • A blockchain is a type of distributed ledger

Blockchain A continuously growing list of records, called blocks, which are linked and secured using cryptography. Each block typically contains a hash pointer as a link to a previous block, a timestamp and transaction data.

This Photo by Unknown Author is licensed under CC BY-SA

Blockchain

• The first distributed blockchain was conceptualized in 2008 by an anonymous person or group known as Satoshi Nakamoto and implemented in 2009 as a core component of bitcoin, where it serves as the public ledger for all transactions..

Distributed Ledger vs. Blockchain

Distributed Ledger Blockchain A database that: A type of distributed ledger that: • Addresses the problem of “untrusted” • Is decentralized into nodes (participants, nodes (consensus layer) sites, regions, etc.) • Creates “blocks” of encrypted data that • A copy of the ledger resides on each node point to the previous blocks

Cryptocurrency

A digital asset designed to work as a medium of exchange using cryptography to 1) secure the transactions, 2) control the creation of additional units, and 3) verify the transfer of assets.

This Photo by Unknown Author is licensed under CC BY

Cryptocurrency

• The invention of the blockchain for bitcoin made it the first digital currency to solve the double spending problem without the need of a trusted authority or central server.

Cryptocurrency Transaction

How Blockchain Technology Powers Bitcoin

CB Insights, “What is Blockchain Technology? (2017)

DLT, Blockchain & Cryptocurrency Distributed Ledger

Verifiable by Blockchain multiple participants

Immutable record (public/private) Cryptocurrency

Usually private Hash points to Public ledger of single asset Miners/reward previous block

Smart Contract

• Introduced by Nick Szabo in 1996 (before blockchain) • Problem of immutability left Smart Contracts mostly theoretical • Advent of blockchain revived interest in so-called “self-executing” legal contracts • Much confusion about the definition and purpose of Smart Contract

Smart Contract: What is it?

• “A smart contract is a computer protocol intended • Smart Contract is an event driven program, with to facilitate, verify, or enforce the negotiation or state, that runs on a distributed, decentralized, performance of a contract.” – Wikipedia shared and replicated ledger that can take custody over and instruct transfer of assets on that ledger. • “A smart contract is a computer protocol that – AZ HB 2417 facilities the transfer of digital assets between parties under the agreed-upon stipulations or • A smart contract is an agreement in digital form terms.” - Techopedia that is self-executing and self-enforcing. – Wharton Law Professor • Smart Contracts are "autonomous agents" that live inside of the … execution environment, always • “Smart contracts are self-executing contracts with executing a specific piece of code when "poked" the terms of the agreement between buyer and by a message or transaction, and having direct seller being directly written into lines of code. The control over their own [token] balance and their own code and the agreements contained therein exist key/value store to keep track of persistent variables. across a distributed, decentralized blockchain - Ethereum network.” – Investopia

Blockchain Smart Contracts + Blockchains

AKA the Technologists’ view Smart Contract

Smart Contract

This is an actual Smart Contract, written on the Ethereum blockchain

Source: https://www.ethereum.org/token

Smart Contracts + Legal Agreements

AKA the Lawyers’ view Smart Legal Contract Agreement

Blockchain Blockchain + Legal Agreements

AKA the Real Estate view Legal Agreement This Photo by Unknown Author is licensed under CC BY

Smart Contract

“a set of promises, specified in digital form, including protocols within which the parties perform on these promises” without the use of artificial intelligence. – Nick Szabo

Blockchain

Smart Legal Contract Agreement

This Photo by Unknown Author is licensed under CC BY-SA This Photo by Unknown Author is licensed under CC BY-NC-ND

Common Accord

• http://www.commonaccord.org/ • Attempting to bridge the gap between smart contracts and legal contracts • “Wise” contracts

How Smart Contracts Work

Smart contracts help you exchange money, property, shares, or anything of value in a transparent, conflict-free way while avoiding the services of a middleman. Built upon a distributed ledger, a smart contract is usually: 1. Pre-written logic in the form of computer code 2. Stored and replicated on the distributed ledger 3. Executed and run by the network of computers running the ledger 4. Can result in updates to accounts on the ledger (i.e. payment for an executed contract)

How Smart Contracts Work

Using the Ethereum platform, smart contracts can be programmed using basic logic. On the most basic level, they can: 1. Perform calculations (i.e. calculating interest) 2. Store information (i.e. membership records) 3. Send transactions to other accounts (i.e. payment for a good or service) But most importantly, smart contracts are autonomous. They are not controlled by anyone – instead, they self-execute based on a set of instructions that the parties have agreed to (ie. the code).

How a smart contract works (in theory)

Source: Etherparty.io

Token sales, or “ICOs”

• ICOs are similar to initial public offerings, or IPOs, in that they are a way for companies to raise money from the public. In an IPO, a company sells stock, or ownership stakes, to the public; in an ICO, a company sells its tokens. After an ICO, the public can buy, sell, or hold the tokens in much the same way they can stock. • Ultimately, investors and VCs hope that the tokens gain enough value that they'll be able to cash out their tokens for a profit. • The first ICO was held in 2013, but the technique has boomed in recent months. Startups have raised nearly $4 billion since mid-2016, and most of that has been raised since May. • There's growing concern about how well companies that are choosing to use ICOs for fundraising are being vetted and how well the public is being informed about the process. Controversy has swirled recently around Centra and Tezos, both of which raised money through an ICO this year.

SAFTs

• Simple Agreements for Future Tokens • SAFTs are venture capital's way of adapting to the boom in ICOs. • In traditional venture capital investing, investors give a startup money in exchange for an ownership stake in the company. But with SAFTs, venture capitalists receive the rights to future tokens instead. • Typically, the VCs get the rights to a certain portion of the tokens a company issues in an ICO.

Regulatory Developments Federal agencies respond to DLT

IRS

• Internal Revenue Service has determined cryptocurrencies should be classified and treated as property for federal tax purposes. • Cryptocurrency payments are subject to reporting, and owners must keep track of capital gains or losses associated with any given transaction.

This Photo by Unknown Author is licensed under CC BY-NC-SA

FinCEN

• FinCEN issued interpretive guidance in 2013 on money services businesses transmitting/transferring virtual currencies (tokens) • In October 2014, FinCEN released new guidance for custodial bitcoin exchanges and payment processors, ruling that such companies may be considered money services businesses under US law • In July 2017, assessed a $110,003,314 civil money penalty against BTC- e for willfully violating U.S. anti-money laundering laws.

This Photo by Unknown Author is licensed under CC BY-SA

CFTC

• CFTC found Bitcoin to be a commodity for the purposes of Section 4c of the CEA and Part 32 of the CFTC’s Regulations. • Enforcement action In re Coinflip, Inc. (2015) directed defendants to cease and desist designating put and call options for the delivery of Bitcoins as eligible for trading.

This Photo by Unknown Author is licensed under CC BY-SA

SEC

• SEC formed Cyber Unit early 2017 to investigate cyber fraud, hacking, misconduct. Specifically lists violations involving distributed ledger technology and initial coin offerings. • Issued guidance in July 2017 that tokens may be classified as “investment contracts” under Article 8 of the Uniform Commercial Code, and therefore subject to Federal securities laws • On November 16, 2017, SEC Chairman Jay Clayton announced in a symposium on cybersecurity and financial crimes that the SEC would start taking enforcement action against coin offering issuers who fail to register with the SEC.

This Photo by Unknown Author is licensed under CC BY-SA

SEC

• SEC v. Howey, 67 S.Ct. 27 (1946) provides test for whether a transaction is an investment contract under Art. 8 UCC. • Howey Test: • It is an investment of money • There is an expectation of profits from the investment • The investment of money is in a common enterprise • Any profit comes from the efforts of a promoter or third party

This Photo by Unknown Author is licensed under CC BY-SA

SEC

• Release 82017 (July 25, 2017) – “DAO Report” • Slock.it tokens found to be “securities” under the Howey test • Stopped short of saying ALL decentralized currencies are securities

This Photo by Unknown Author is licensed under CC BY-SA

Wyoming Money Transmitters Act (2003)

• As in most states, Wyoming has licensing requirements for money transmitters. • Wyoming Banking Commission found Coinbase, a cryptocurrency exchange to be a money transmitter, and required a 100% reserve in fiat currency. • Under current interpretation, it is technically difficult to conduct Bitcoin transactions in Wyoming.

This Photo by Unknown Author is licensed under CC BY-SA

Statutory developments State and federal enactments

Delaware Blockchain Initiative

• Amendments to DGCL effective August 1, 2017 allow companies to create and maintain corporate records, including stock ledgers, on a blockchain. • Delaware Public Archives seeking to store state archival records on a distributed ledger. • Delaware has announced that it expects to introduce “smart UCC” filings that “will automate the release or renewal of UCC filings and related collateral….”

Vermont Blockchain Law

• H.868 (enacted 2016) provides that a blockchain-based digital record will be considered a business record under the Vermont Rules of Evidence

This Photo by Unknown Author is licensed under CC BY-SA

Arizona Blockchain Laws

• HB 2417 amended state e-signature law in March 2017 to clarify that electronic records, signatures, and smart contracts — guaranteed via blockchain technology and governed by UCC Articles 2, 2A, and 7 — are treated as legal electronic signatures. • HB 2216, enacted April 2017, prohibits the use of blockchain technology to track firearm information.

This Photo by Unknown Author is licensed under CC BY-SA

Nevada Blockchain Law (SB398)

• Enacted June 5, 2017, amends state e-signature law to clarify legal recognition of the use of blockchain technology for electronic signatures and records • Prohibits a local government from: 1) imposing a tax or fee on the use of a blockchain; (2) requiring a certificate, license or permit to use a blockchain; and (3) imposing any other requirement relating to the use of a blockchain.

Modernization of Government Technology Act

• MGT is part of National Defense Authorization Act (NDAA), currently in conference committee • Under the MGT provision, government agencies are authorized to spend their working capital funds for modernization initiatives falling in three categories, namely, migrating legacy systems to the cloud services, cybersecurity and other innovative and disruptive technologies and platforms. • Although it was not categorically stated in the bill, Blockchain technology is qualified as a potential direction for the allocation of funds for further advancement beyond the proof-of-concept stage at the agency level.

Reference Materials

• “General tax principles applicable to property transactions apply to transactions using virtual currency,” IRS Notice 2014-21 (2014), at http://www.irs.gov/pub/irs-drop/n-14-21.pdf. • Report of Investigation Pursuant to Section 21(a) of the Securities Exchange Act of 1934: The DAO, Exchange Act, Release No. 81207 (July 25, 2017), at http://www.sec.gov/litigation/investreport/34-81207.pdf. • “Application of FinCEN’s Regulations to Persons Administering, Exchanging, or Using Virtual Currencies,” Guidance, Department of the Treasury Financial Crimes Enforcement Network, FIN-2013-G001, 18 (March 18, 2013), at https://www.fincen.gov/sites/default/files/shared/FIN-2013-G001.pdf. • In re Coinflip, Inc., C.F.T.C. Docket No. 15-29, 3 (Sep. 17, 2015), at http://www.cftc.gov/idc/groups/public/@lrenforcementactions/documents/legalpleading/enfcoinfliprorder09172015.pdf. • Szabo, Nick, Formalizing and Securing Relationships on Public Networks. First Monday, [S.l.], (September,1997) ISSN 13960466, at http://ojphi.org/ojs/index.php/fm/article/view/548/469. • Buterin, V. et al. "A Next-Generation Smart Contract and Decentralized Application Platform". Ethereum Wiki, at https://github.com/ethereum/wiki/wiki/White-Paper. • Hazard, James Gardiner and Haapio, Helena, Wise Contracts: Smart Contracts that Work for People and Machines (February 23, 2017). Erich Schweighofer et al. (Eds.), Trends and Communities of Legal Informatics. Proceedings of the 20th International Legal Informatics Symposium IRIS 2017. Österreichische Computer Gesellschaft, Wien 2017, pp. 425–432 (ISBN 978-3-903035-15-7); Jusletter IT, 23 February 2017, at https://ssrn.com/abstract=2925871. • Smart Contract Infographic, courtesy Etherparty.io. at http://www.visualcapitalist.com/smart-contracts-blockchain/.

ESRA (Electronic Signature and Records Association) With expansive membership and cross-functional representation, ESRA is uniquely positioned to stay on top of current and future conversations around electronic signatures and records. Other Resources http://www.esignrecords.org Chamber of Digital Commerce Mission to promote the acceptance and use of www.k6legal.com digital assets and blockchain-based technologies https://digitalchamber.org/

Common Accord Initiative to create global codes for legal transactions by codifying and automating legal documents http://www.commonaccord.org/

K6 Partners / K6 Legal Blog Blockchain law and policy http://www.k6blog.com

Thank You! Ken Moyle [email protected] @moyleken www.linkedin.com/in/kenmoyle

www.ClearLawInstitute.com (703) 372-0550

UNITED STATES OF AMERICA Before the COMMODITY FUTURES TRADING COMMISSION

) In the Matter of: ) ) Coinflip, Inc., d/b/a Derivabit, and ) Francisco Riordan, ) CFTC Docket No. 15-29 ) Respondents. ) ) )

ORDER INSTITUTING PROCEEDINGS PURSUANT TO SECTIONS 6(c) AND 6(d) OF THE COMMODITY EXCHANGE ACT, MAKING FINDINGS AND IMPOSING REMEDIAL SANCTIONS

The Commodity Futures Trading Commission (“Commission”) has reason to believe that from in or about March 2014 to at least August 2014 (the “Relevant Period”), Coinflip, Inc., d/b/a Derivabit (“Coinflip”) and Francisco Riordan (“Riordan”) (the “Respondents”) violated Sections 4c(b) and 5h(a)(1) of the Commodity Exchange Act, as amended (the “Act”), 7 U.S.C. §§ 6c(b) and 7b-3(a)(1) (2012), and Commission Regulations 32.2 and 37.3(a)(1), 17 C.F.R. § 32.2 and 37.3(a)(1) (2014). Therefore, the Commission deems it appropriate and in the public interest that public administrative proceedings be, and hereby are, instituted to determine whether the Respondents engaged in the violations set forth herein and to determine whether any order should be issued imposing remedial sanctions.

II.

In anticipation of the institution of an administrative proceeding, the Respondents have submitted an Offer of Settlement (“Offer”), which the Commission has determined to accept. Without admitting or denying any of the findings or conclusions herein, Respondents consent to the entry of this Order Instituting Proceedings Pursuant to Sections 6(c) and 6(d) of the Commodity Exchange Act, Making Findings and Imposing Remedial Sanctions (“Order”) and acknowledge service of this Order.1

1 Respondents consent to the entry of this Order and to the use of these findings in this proceeding and in any other proceeding brought by the Commission or to which the Commission is a party; provided, however, that Respondents do not consent to the use of the Offer, or the findings or conclusions in the Order consented to in the Offer, as the sole basis for any other proceeding brought by the Commission, other than in a proceeding in bankruptcy or to enforce the terms of this Order. Nor do Respondents consent to the use of the Offer or the Order, or the findings or conclusions in this Order consented to in the Offer, by any other party in any other proceeding.

III.

The Commission finds the following:

A. Summary

During the Relevant Period, Respondents violated Sections 4c(b) and 5h(a)(l) of the Act and Commission Regulations 32.2 and 37.3(a)(l) by conducting activity related to commodity options contrary to Commission Regulations and by operating a facility for the trading or processing of swaps without being registered as a swap execution facility or designated contract market. Specifically, during the Relevant Period, Respondents operated an online facility named Derivabit, offering to connect buyers and sellers of Bitcoin option contracts. 2

B. Respondents

Coinflip, Inc. is a Delaware corporation with a principal place of business in San Francisco, California. During the Relevant period, Coinflip operated Derivabit and its website derivabit.com. Coinflip has never been registered with the Commission.

Francisco Riordan is an individual residing in San Francisco, California. Riordan is a founder, the chief executive officer, and controlling person of Coinflip. Riordan has never been registered with the Commission.

C. Facts

Coinflip Conducted Activity Related to Illegal Commodity Options

Beginning in March 2014, Coinflip adve1iised Derivabit as a "risk management platform ... that connects buyers and sellers of standardized Bitcoin options and futures contracts." During this period, Coinflip designated numerous put and call options contracts as eligible for trading on the Derivabit platform. 3 For these contracts, Coinflip listed Bitcoin as the asset underlying the option and denominated the strike and delivery prices in US Dollars. According to the derivabit.com website, a customer could place orders by registering as a user and depositing Bitcoin into an account in the user's name. Premiums and payments of settlement of the option contracts were to be paid using Bitcoin at a spot rate determined by a designated third pmiy Bitcoin currency exchange. Users had the ability to, and in fact did, post bids or offers for

2 Bitcoin is a "virtual cutTency," defined here as a digital representation of value that functions as a medium of exchange, a unit of account, and/or a store ofvalue, but does not have legal tender status in any jurisdiction. Bitcoin and other virtual currencies are distinct from "real" currencies, which are the coin and paper money of the United States or another country that are designated as legal tender, circulate, and are customarily used and accepted as a medium of exchange in the country of issuance. 3 Although referenced it its solicitation materials, Coinflip did not offer any futures contracts during the Relevant Period.

2 the designated options contracts. Coinflip confirmed the bid or offer by communicating it to all users through its website. 4

During the Relevant Period, Derivabit had approximately 400 users. Riordan Controlled Coinflip and Directed Its Operations

Riordan was the founder, engineer and Chief Executive Officer of Coinflip. He exercised control over Coinflip's daily operations and possessed the power or ability to control all aspects ofthe Derivabit platform. Riordan participated in key aspects of Coinflip's illegal activity, including designing and implementing the Derivabit trading platform. Riordan's control enabled him to make design and substantive changes to Coinflip's operations, including the transition from offering Bitcoin options to OTC Bitcoin Forward Contracts. Ultimately, Riordan possessed the power and ability to direct Coinflip to cease operating the Derivabit platform.

LEGAL DISCUSSION

A. Virtual Currencies Such as Bitcoin are Commodities

Section 1a(9) of the Act defines "commodity" to include, among other things, "all services, rights, and interests in which contracts for future delivery are presently or in the future dealt in." 7 U.S.C. § 1a(9). The definition of a "commodity" is broad. See, e.g., Board ofTrade ofCity ofChicago v. SEC, 677 F. 2d 1137, 1142 (7th Cir. 1982). Bitcoin and other virtual currencies are encompassed in the definition and properly defined as commodities.

B. Coinflip Violated Sections 4c(b) Act and Commission Regulation 32.2

Section 4c(b) ofthe Act makes it unlawful for any person to "offer to enter into, enter into or confirm the execution of, any transaction involving any commodity ... which is of the character of, or is commonly known to the trade as, an 'option' ... , 'bid', 'offer', 'put', [or] 'call' ... contrary to any rule, regulation, or order of the Commission prohibiting any such transaction." Section 1.3(hh) defines a "commodity option transaction" and "commodity option" to "mean any transaction or agreement in interstate commerce which is or is held out to be of the character of, or is commonly known to the trade as, an 'option,' 'privilege,' 'indemnity,' 'bid,' 'offer,' 'call,' 'put,' 'advance guaranty,' or 'decline guaranty,' and which is subject to regulation under the Act and these regulations." Section 32.2 of the Commission's Regulations, in turn,

4 In July 2014, Coinflip began to offer what it characterized as "OTC Bitcoin Forward Contracts" for trading. Under this model, a Derivabit user would be matched through competitive bidding with a counterparty to execute a contract to exchange US Dollars for Bitcoins at a predetermined price and date. As part of its services, Coinflip would calculate and hold initial and maintenance margin payments and would also calculate and facilitate the transfer of final settlements at maturity or early termination. Coin flip advettised that the users could choose to institute an early termination at any time if its position was "in the money." Although the price would be expressed as an exchange rate between US Dollars and Bitcoins, Coinflip required all settlements and margin payments to be transacted in Bitcoins. No bids or offers were posted by Derivabit users for these contracts. Although these activities may have violated, or led to violations of, the Commodity Exchange Act, the Commission does not address this conduct here.

3 provides that it shall be unlawful for any person to "offer to enter into, enter into, confirm the execution of, maintain a position in, or otherwise conduct activity related to any transaction in interstate commerce that is a commodity option transaction unless: (a) [s]uch transaction is conducted in compliance with and subject to the provisions of the Act, including any Commission rule, regulation, or order thereunder, otherwise applicable to any other swap, or (b) [s]uch transaction is conducted pursuant to [Regulation] 32.3."

Between at least March 2014 and July 2014, Respondents conducted activity related to commodity option transactions, offered to enter into commodity option transactions and/or confirmed the existence of commodity option transactions. The options transactions were not conducted in compliance with Section 5h(a)(1) of the Act or Regulation 37.3(a)(l), a section of the Act and a Commission regulation otherwise applicable to swaps (see infra Section C) and were not conducted pursuant to Regulation 32.3. 5 Accordingly, Coinflip violated Section 4c(b) of the Act and Commission Regulation 32.2.

C. Coinflip Violated Section Sh(a)(l) of the Act

Section 5h(a)(1) ofthe Act forbids any person from operating "a facility for the trading or processing of swaps unless the facility is registered as a swap execution facility or as a designated contract market ...." 7 U.s.c.' § 7b-3(a)(1). Section 1a(47) of the Act's definition of"swap" includes option contracts. 7 U.S.C. § 1a(47)(A)(i). Regulation 37.3(a)(1) similarly requires that any "person operating a facility that offers a trading system or platform in which more than one market participant has the ability to execute or trade swaps with more than one other market participant on the system or platform shall register the facility as a swap execution facility under this part or as a designated contract market under part 38 of this chapter." 17 C.P.R. § 37.3(a)(l) (2014).

During the Relevant Period, Coinflip operated a facility for the trading of swaps. However, Coinflip did not register the facility as a swap execution facility or designated contract market. Accordingly, Coinflip violated Section 5h(a)(l) ofthe Act and Regulation 37.3(a)(1).

D. Riordan Is Liable for Coinflip's Violations as Its Controlling Person Under Section 13(b) of the Act

Riordan controlled Coinflip, directly or indirectly, and did not act in good faith or knowingly induced, directly or indirectly, Coinflip's acts in violation of the Act and Regulations; therefore, pursuant to Section 13(b) of the Act, 7 U.S.C. § 13c(b) (2012), Riordan is liable for Coinflip's violations of Sections 4c(b) and 5h(a)(1) ofthe Act, 7 U.S.C. §§ 6c(b) and 7b-3(a)(l) (2012) and Regulations 32.2 and 37.3(a)(1), 17 C.P.R.§§ 32.2 and 37.3(a)(1) (2014).

5 To take advantage of the "trade option" exemptions set forth in Regulation 32.3, the offeror of the option must be an eligible contract participant as defined in Section 1a( 18) of the Act or "producer, processor, or commercial user of, or a merchant handling the commodity," and have a reasonable basis to believe that the offeree was a "producer, processor, or commercial user of, or a merchant handling the commodity that is the subject of the commodity option transaction, or the products or by-products thereof, and such offeree is offered or entering into the commodity option transaction solely for purposes related to its business as such." 17 C.F.R. §§ 32.3(a)(1)(i)-(ii) and 32.3(a)(2).

4 IV.

FINDINGS OF VIOLATIONS

Based on the foregoing, the Commission finds that, during the Relevant Period, Respondents violated Sections 4c(b) and 5h(a)(1) ofthe Act, 7 U.S.C. §§ 4c(b) and 7b-3(a)(l) (2012), and Commission Regulations 32.2 and 37.3(a)(l), 17 C.P.R. §§ 32.2 and 37.3(a)(1) (2014). v.

OFFER OF SETTLEMENT

Respondents have submitted an Offer in which they, without admitting or denying the findings and conclusions herein:

A. Acknowledge receipt of service of this Order;

B. Admit the jurisdiction ofthe Commission with respect to all matters set forth in this Order and for any action or proceeding brought or authorized by the Commission based on violation of or enforcement of this Order;

C. Waive:

1. the filing and service of a complaint and notice of hearing;

2. a hearing;

3. all post-hearing procedures;

4. judicial review by any court;

5. any and all objections to the participation by any member of the Commission's staff in the Commission's consideration ofthe Offer;

6. any and all claims that they may possess under the Equal Access to Justice Act, 5 U.S.C. § 504 (2012) and 28 U.S.C. § 2412 (2012), and/or the rules promulgated by the Commission in conformity therewith, Part 148 of the Commission's Regulations, 17 C.P.R.§§ 148.1-30 (2014), relating to, or arising from, this proceeding;

7. any and all claims that they may possess under the Small Business Regulatory Enforcement Fairness Act of 1996, Pub. L. No. 104-121, §§ 201-253, 110 Stat. 847, 857-868 (1996), as amended by Pub. L. No. 110-28, § 8302, 121 Stat. 112, 204-205 (2007), relating to, or arising from, this proceeding; and

5 8. any claims of Double Jeopardy based on the institution of this proceeding or the entry in this proceeding of any order imposing a civil monetary penalty or any other relief;

D. Stipulate that the record basis on which this Order is entered shall consist solely ofthe findings contained in this Order to which Respondents have consented in the Offer;

E. Consent, solely on the basis of the Offer, to the Commission's entry of this Order that:

1. makes findings by the Commission that Respondents violated Sections 4c(b) and 5h(a)(1) ofthe Act, 7 U.S.C. §§ 6c(b) and 7b-3(a)(1) (2012), and Commission Regulations 32.2 and 37.3(a)(l), 17 C.P.R. §§ 32.2 and 37.3(a)(l) (2014);

2. orders Respondents to cease and desist from violating Sections 4c(b) and 5h(a)(l) of the Act and Commission Regulations 32.2 and 37.3(a)(1); and

3. orders Respondents and their successors and assigns to comply with the conditions and undertakings consented to in the Offer and as set fmih in Pmi VI of this Order.

Upon consideration, the Commission has determined to accept Respondents' Offer.

VI.

ORDER

Accordingly, IT IS HEREBY ORDERED THAT:

A. Respondents shall cease and desist from violating Sections 4c(b) and 5h(a)(1) of the Act, 7 U.S.C. §§ 6c(b) and 7b-3(a)(l) (2012), and Commission Regulations 32.2 and 37.3(a)(1), 17 C.P.R. §§ 32.2 and 37.3(a)(1) (2014).

B. Respondents and their successors and assigns shall comply with the following conditions and undertakings set forth in the Offer:

1. Public Statements: Respondents agree that neither they nor any of their successors and assigns, agents, or employees under their authority or control shall take any action or make any public statement denying, directly or indirectly, any findings or conclusions in the Order or creating, or tending to create, the impression that the Order is without a factual basis; provided, however, that nothing in this provision shall affect Respondents' (i) testimonial obligations; or (ii) right to take legal positions in other proceedings to which the Commission is not a party. Respondents and their successors and assigns shall undetiake all steps necessary to ensure that all of their agents and/or employees under their authority or control understand and comply with this agreement.

2. Cooperation with the Commission: Respondents shall cooperate fully and expeditiously with the Commission, including the Commission's Division of

6 Enforcement, and any other governmental agency in this action, and in any investigation, civil litigation, or administrative matter related to the subject matter of this action or any current or future Commission investigation related thereto.

The provisions of this Order shall be effective as of this date.

By the Commission.

Christopher J. Grkpatrick Secretary of the Commission Commodity Futures Trading Commission

Dated: September 17, 2015

Guidance

FIN-2013-G001 Issued: March 18, 2013 Subject: Application of FinCEN’s Regulations to Persons Administering, Exchanging, or Using Virtual Currencies

The Financial Crimes Enforcement Network (“FinCEN”) is issuing this interpretive guidance to clarify the applicability of the regulations implementing the Bank Secrecy Act (“BSA”) to persons creating, obtaining, distributing, exchanging, accepting, or transmitting virtual currencies.1 Such persons are referred to in this guidance as “users,” “administrators,” and “exchangers,” all as defined below.2 A user of virtual currency is not an MSB under FinCEN’s regulations and therefore is not subject to MSB registration, reporting, and recordkeeping regulations. However, an administrator or exchanger is an MSB under FinCEN’s regulations, specifically, a money transmitter, unless a limitation to or exemption from the definition applies to the person. An administrator or exchanger is not a provider or seller of prepaid access, or a dealer in foreign exchange, under FinCEN’s regulations.

Currency vs. Virtual Currency

FinCEN’s regulations define currency (also referred to as “real” currency) as “the coin and paper money of the United States or of any other country that [i] is designated as legal tender and that [ii] circulates and [iii] is customarily used and accepted as a medium of exchange in the country of issuance.”3 In contrast to real currency, “virtual” currency is a medium of exchange that operates like a currency in some environments, but does not have all the attributes of real currency. In particular, virtual currency does not have legal tender status in any jurisdiction. This guidance addresses “convertible” virtual currency. This type of virtual currency either has an equivalent value in real currency, or acts as a substitute for real currency.

1 FinCEN is issuing this guidance under its authority to administer the Bank Secrecy Act. See Treasury Order 180- 01 (March 24, 2003). This guidance explains only how FinCEN characterizes certain activities involving virtual currencies under the Bank Secrecy Act and FinCEN regulations. It should not be interpreted as a statement by FinCEN about the extent to which those activities comport with other federal or state statutes, rules, regulations, or orders. 2 FinCEN’s regulations define “person” as “an individual, a corporation, a partnership, a trust or estate, a joint stock company, an association, a syndicate, joint venture, or other unincorporated organization or group, an Indian Tribe (as that term is defined in the Indian Gaming Regulatory Act), and all entities cognizable as legal personalities.” 31 CFR § 1010.100(mm). 3 31 CFR § 1010.100(m).

www.fincen.gov

Background

On July 21, 2011, FinCEN published a Final Rule amending definitions and other regulations relating to money services businesses (“MSBs”).4 Among other things, the MSB Rule amends the definitions of dealers in foreign exchange (formerly referred to as “currency dealers and exchangers”) and money transmitters. On July 29, 2011, FinCEN published a Final Rule on Definitions and Other Regulations Relating to Prepaid Access (the “Prepaid Access Rule”).5 This guidance explains the regulatory treatment under these definitions of persons engaged in virtual currency transactions.

Definitions of User, Exchanger, and Administrator

This guidance refers to the participants in generic virtual currency arrangements, using the terms “user,” “exchanger,” and “administrator.”6 A user is a person that obtains virtual currency to purchase goods or services.7 An exchanger is a person engaged as a business in the exchange of virtual currency for real currency, funds, or other virtual currency. An administrator is a person engaged as a business in issuing (putting into circulation) a virtual currency, and who has the authority to redeem (to withdraw from circulation) such virtual currency.

Users of Virtual Currency

A user who obtains convertible virtual currency and uses it to purchase real or virtual goods or services is not an MSB under FinCEN’s regulations.8 Such activity, in and of itself, does not fit within the definition of “money transmission services” and therefore is not subject to FinCEN’s registration, reporting, and recordkeeping regulations for MSBs.9

4 Bank Secrecy Act Regulations – Definitions and Other Regulations Relating to Money Services Businesses, 76 FR 43585 (July 21, 2011) (the “MSB Rule”). This defines an MSB as “a person wherever located doing business, whether or not on a regular basis or as an organized or licensed business concern, wholly or in substantial part within the United States, in one or more of the capacities listed in paragraphs (ff)(1) through (ff)(7) of this section. This includes but is not limited to maintenance of any agent, agency, branch, or office within the United States.” 31 CFR § 1010.100(ff). 5 Final Rule – Definitions and Other Regulations Relating to Prepaid Access, 76 FR 45403 (July 29, 2011), 6 These terms are used for the exclusive purpose of this regulatory guidance. Depending on the type and combination of a person’s activities, one person may be acting in more than one of these capacities. 7 How a person engages in “obtaining” a virtual currency may be described using any number of other terms, such as “earning,” “harvesting,” ”mining,” “creating,” “auto-generating,” “manufacturing,” or “purchasing,” depending on the details of the specific virtual currency model involved. For purposes of this guidance, the label applied to a particular process of obtaining a virtual currency is not material to the legal characterization under the BSA of the process or of the person engaging in the process. 8 As noted above, this should not be interpreted as a statement about the extent to which the user’s activities comport with other federal or state statutes, rules, regulations, or orders. For example, the activity may still be subject to abuse in the form of trade-based money laundering or terrorist financing. The activity may follow the same patterns of behavior observed in the “real” economy with respect to the purchase of “real” goods and services, such as systematic over- or under-invoicing or inflated transaction fees or commissions. 9 31 CFR § 1010.100(ff)(1-7).

2 Administrators and Exchangers of Virtual Currency

An administrator or exchanger that (1) accepts and transmits a convertible virtual currency or (2) buys or sells convertible virtual currency for any reason is a money transmitter under FinCEN’s regulations, unless a limitation to or exemption from the definition applies to the person.10 FinCEN’s regulations define the term “money transmitter” as a person that provides money transmission services, or any other person engaged in the transfer of funds. The term “money transmission services” means “the acceptance of currency, funds, or other value that substitutes for currency from one person and the transmission of currency, funds, or other value that substitutes for currency to another location or person by any means.”11

The definition of a money transmitter does not differentiate between real currencies and convertible virtual currencies. Accepting and transmitting anything of value that substitutes for currency makes a person a money transmitter under the regulations implementing the BSA.12 FinCEN has reviewed different activities involving virtual currency and has made determinations regarding the appropriate regulatory treatment of administrators and exchangers under three scenarios: brokers and dealers of e-currencies and e-precious metals; centralized convertible virtual currencies; and de-centralized convertible virtual currencies.

a. E-Currencies and E-Precious Metals

The first type of activity involves electronic trading in e-currencies or e-precious metals.13 In 2008, FinCEN issued guidance stating that as long as a broker or dealer in real currency or other commodities accepts and transmits funds solely for the purpose of effecting a bona fide purchase or sale of the real currency or other commodities for or with a customer, such person is not acting as a money transmitter under the regulations.14

However, if the broker or dealer transfers funds between a customer and a third party that is not part of the currency or commodity transaction, such transmission of funds is no longer a fundamental element of the actual transaction necessary to execute the contract for the purchase or sale of the currency or the other commodity. This scenario is, therefore, money

10 FinCEN’s regulations provide that whether a person is a money transmitter is a matter of facts and circumstances. The regulations identify six circumstances under which a person is not a money transmitter, despite accepting and transmitting currency, funds, or value that substitutes for currency. 31 CFR § 1010.100(ff)(5)(ii)(A)–(F). 11 31 CFR § 1010.100(ff)(5)(i)(A). 12 Ibid. 13 Typically, this involves the broker or dealer electronically distributing digital certificates of ownership of real currencies or precious metals, with the digital certificate being the virtual currency. However, the same conclusions would apply in the case of the broker or dealer issuing paper ownership certificates or manifesting customer ownership or control of real currencies or commodities in an account statement or any other form. These conclusions would also apply in the case of a broker or dealer in commodities other than real currencies or precious metals. A broker or dealer of e-currencies or e-precious metals that engages in money transmission could be either an administrator or exchanger depending on its business model. 14 Application of the Definition of Money Transmitter to Brokers and Dealers in Currency and other Commodities, FIN-2008-G008, Sept. 10, 2008. The guidance also notes that the definition of money transmitter excludes any person, such as a futures commission merchant, that is “registered with, and regulated or examined by…the Commodity Futures Trading Commission.”

3 transmission.15 Examples include, in part, (1) the transfer of funds between a customer and a third party by permitting a third party to fund a customer’s account; (2) the transfer of value from a customer’s currency or commodity position to the account of another customer; or (3) the closing out of a customer’s currency or commodity position, with a transfer of proceeds to a third party. Since the definition of a money transmitter does not differentiate between real currencies and convertible virtual currencies, the same rules apply to brokers and dealers of e-currency and e-precious metals.

b. Centralized Virtual Currencies

The second type of activity involves a convertible virtual currency that has a centralized repository. The administrator of that repository will be a money transmitter to the extent that it allows transfers of value between persons or from one location to another. This conclusion applies, whether the value is denominated in a real currency or a convertible virtual currency. In addition, any exchanger that uses its access to the convertible virtual currency services provided by the administrator to accept and transmit the convertible virtual currency on behalf of others, including transfers intended to pay a third party for virtual goods and services, is also a money transmitter.

FinCEN understands that the exchanger’s activities may take one of two forms. The first form involves an exchanger (acting as a “seller” of the convertible virtual currency) that accepts real currency or its equivalent from a user (the “purchaser”) and transmits the value of that real currency to fund the user’s convertible virtual currency account with the administrator. Under FinCEN’s regulations, sending “value that substitutes for currency” to another person or to another location constitutes money transmission, unless a limitation to or exemption from the definition applies.16 This circumstance constitutes transmission to another location, namely from the user’s account at one location (e.g., a user’s real currency account at a bank) to the user’s convertible virtual currency account with the administrator. It might be argued that the exchanger is entitled to the exemption from the definition of “money transmitter” for persons involved in the sale of goods or the provision of services. Under such an argument, one might assert that the exchanger is merely providing the service of connecting the user to the administrator and that the transmission of value is integral to this service. However, this exemption does not apply when the only services being provided are money transmission services.17

The second form involves a de facto sale of convertible virtual currency that is not completely transparent. The exchanger accepts currency or its equivalent from a user and privately credits the user with an appropriate portion of the exchanger’s own convertible virtual currency held with the administrator of the repository. The exchanger then transmits that

15 In 2011, FinCEN amended the definition of money transmitter. The 2008 guidance, however, was primarily concerned with the core elements of the definition – accepting and transmitting currency or value – and the exemption for acceptance and transmission integral to another transaction not involving money transmission. The 2011 amendments have not materially changed these aspects of the definition. 16 See footnote 11 and adjacent text. 17 31 CFR § 1010.100(ff)(5)(ii)(F).

4 internally credited value to third parties at the user’s direction. This constitutes transmission to another person, namely each third party to which transmissions are made at the user’s direction. To the extent that the convertible virtual currency is generally understood as a substitute for real currencies, transmitting the convertible virtual currency at the direction and for the benefit of the user constitutes money transmission on the part of the exchanger.

c. De-Centralized Virtual Currencies

A final type of convertible virtual currency activity involves a de-centralized convertible virtual currency (1) that has no central repository and no single administrator, and (2) that persons may obtain by their own computing or manufacturing effort.

A person that creates units of this convertible virtual currency and uses it to purchase real or virtual goods and services is a user of the convertible virtual currency and not subject to regulation as a money transmitter. By contrast, a person that creates units of convertible virtual currency and sells those units to another person for real currency or its equivalent is engaged in transmission to another location and is a money transmitter. In addition, a person is an exchanger and a money transmitter if the person accepts such de-centralized convertible virtual currency from one person and transmits it to another person as part of the acceptance and transfer of currency, funds, or other value that substitutes for currency.

Providers and Sellers of Prepaid Access

A person’s acceptance and/or transmission of convertible virtual currency cannot be characterized as providing or selling prepaid access because prepaid access is limited to real currencies.18

Dealers in Foreign Exchange

A person must exchange the currency of two or more countries to be considered a dealer in foreign exchange.19 Virtual currency does not meet the criteria to be considered “currency” under the BSA, because it is not legal tender. Therefore, a person who accepts real currency in

18 This is true even if the person holds the value accepted for a period of time before transmitting some or all of that value at the direction of the person from whom the value was originally accepted. FinCEN’s regulations define “prepaid access” as “access to funds or the value of funds that have been paid in advance and can be retrieved or transferred at some point in the future through an electronic device or vehicle, such as a card, code, electronic serial number, mobile identification number, or personal identification number.” 31 CFR § 1010.100(ww). Thus, “prepaid access” under FinCEN’s regulations is limited to “access to funds or the value of funds.” If FinCEN had intended prepaid access to cover funds denominated in a virtual currency or something else that substitutes for real currency, it would have used language in the definition of prepaid access like that in the definition of money transmission, which expressly includes the acceptance and transmission of “other value that substitutes for currency.” 31 CFR § 1010.100(ff)(5)(i) . 19 FinCEN defines a “dealer in foreign exchange” as a “person that accepts the currency, or other monetary instruments, funds, or other instruments denominated in the currency, of one or more countries in exchange for the currency, or other monetary instruments, funds, or other instruments denominated in the currency, of one or more other countries in an amount greater than $1,000 for any other person on any day in one or more transactions, whether or not for same-day delivery.” 31 CFR § 1010.100(ff)(1).

5 exchange for virtual currency, or vice versa, is not a dealer in foreign exchange under FinCEN’s regulations.

* * * * *

Financial institutions with questions about this guidance or other matters related to compliance with the implementing regulations of the BSA may contact FinCEN’s Regulatory Helpline at (800) 949-2732.

6 1

Notice 2014-21

SECTION 1. PURPOSE

This notice describes how existing general tax principles apply to transactions using virtual currency. The notice provides this guidance in the form of answers to frequently asked questions.

SECTION 2. BACKGROUND

The Internal Revenue Service (IRS) is aware that “virtual currency” may be used to pay for goods or services, or held for investment. Virtual currency is a digital representation of value that functions as a medium of exchange, a unit of account, and/or a store of value. In some environments, it operates like “real” currency -- i.e., the coin and paper money of the United States or of any other country that is designated as legal tender, circulates, and is customarily used and accepted as a medium of exchange in the country of issuance -- but it does not have legal tender status in any jurisdiction.

Virtual currency that has an equivalent value in real currency, or that acts as a substitute for real currency, is referred to as “convertible” virtual currency. Bitcoin is one example of a convertible virtual currency. Bitcoin can be digitally traded between users and can be purchased for, or exchanged into, U.S. dollars, Euros, and other real or virtual currencies. For a more comprehensive description of convertible virtual currencies to date, see Financial Crimes Enforcement Network (FinCEN) Guidance on the Application of FinCEN’s Regulations to Persons Administering, Exchanging, or Using Virtual Currencies (FIN-2013-G001, March 18, 2013).

SECTION 3. SCOPE

In general, the sale or exchange of convertible virtual currency, or the use of convertible virtual currency to pay for goods or services in a real-world economy transaction, has tax consequences that may result in a tax liability. This notice addresses only the U.S. federal tax consequences of transactions in, or transactions that use, convertible virtual currency, and the term “virtual currency” as used in Section 4 refers only to convertible virtual currency. No inference should be drawn with respect to virtual currencies not described in this notice.

The Treasury Department and the IRS recognize that there may be other questions regarding the tax consequences of virtual currency not addressed in this notice that warrant consideration. Therefore, the Treasury Department and the IRS request comments from the public regarding other types or aspects of virtual currency transactions that should be addressed in future guidance.

Comments should be addressed to: 2

Internal Revenue Service Attn: CC:PA:LPD:PR (Notice 2014-21) Room 5203 P.O. Box 7604 Ben Franklin Station Washington, D.C. 20044

or hand delivered Monday through Friday between the hours of 8 A.M. and 4 P.M. to:

Courier’s Desk Internal Revenue Service Attn: CC:PA:LPD:PR (Notice 2014-21) 1111 Constitution Avenue, N.W. Washington, D.C. 20224

Alternatively, taxpayers may submit comments electronically via e-mail to the following address: [email protected]. Taxpayers should include “Notice 2014-21” in the subject line. All comments submitted by the public will be available for public inspection and copying in their entirety.

For purposes of the FAQs in this notice, the taxpayer’s functional currency is assumed to be the U.S. dollar, the taxpayer is assumed to use the cash receipts and disbursements method of accounting and the taxpayer is assumed not to be under common control with any other party to a transaction.

SECTION 4. FREQUENTLY ASKED QUESTIONS

Q-1: How is virtual currency treated for federal tax purposes?

A-1: For federal tax purposes, virtual currency is treated as property. General tax principles applicable to property transactions apply to transactions using virtual currency.

Q-2: Is virtual currency treated as currency for purposes of determining whether a transaction results in foreign currency gain or loss under U.S. federal tax laws?

A-2: No. Under currently applicable law, virtual currency is not treated as currency that could generate foreign currency gain or loss for U.S. federal tax purposes.

Q-3: Must a taxpayer who receives virtual currency as payment for goods or services include in computing gross income the fair market value of the virtual currency?

A-3: Yes. A taxpayer who receives virtual currency as payment for goods or services must, in computing gross income, include the fair market value of the virtual currency, 3

measured in U.S. dollars, as of the date that the virtual currency was received. See Publication 525, Taxable and Nontaxable Income, for more information on miscellaneous income from exchanges involving property or services.

Q-4: What is the basis of virtual currency received as payment for goods or services in Q&A-3?

A-4: The basis of virtual currency that a taxpayer receives as payment for goods or services in Q&A-3 is the fair market value of the virtual currency in U.S. dollars as of the date of receipt. See Publication 551, Basis of Assets, for more information on the computation of basis when property is received for goods or services.

Q-5: How is the fair market value of virtual currency determined?

A-5: For U.S. tax purposes, transactions using virtual currency must be reported in U.S. dollars. Therefore, taxpayers will be required to determine the fair market value of virtual currency in U.S. dollars as of the date of payment or receipt. If a virtual currency is listed on an exchange and the exchange rate is established by market supply and demand, the fair market value of the virtual currency is determined by converting the virtual currency into U.S. dollars (or into another real currency which in turn can be converted into U.S. dollars) at the exchange rate, in a reasonable manner that is consistently applied.

Q-6: Does a taxpayer have gain or loss upon an exchange of virtual currency for other property?

A-6: Yes. If the fair market value of property received in exchange for virtual currency exceeds the taxpayer’s adjusted basis of the virtual currency, the taxpayer has taxable gain. The taxpayer has a loss if the fair market value of the property received is less than the adjusted basis of the virtual currency. See Publication 544, Sales and Other Dispositions of Assets, for information about the tax treatment of sales and exchanges, such as whether a loss is deductible.

Q-7: What type of gain or loss does a taxpayer realize on the sale or exchange of virtual currency?

A-7: The character of the gain or loss generally depends on whether the virtual currency is a capital asset in the hands of the taxpayer. A taxpayer generally realizes capital gain or loss on the sale or exchange of virtual currency that is a capital asset in the hands of the taxpayer. For example, stocks, bonds, and other investment property are generally capital assets. A taxpayer generally realizes ordinary gain or loss on the sale or exchange of virtual currency that is not a capital asset in the hands of the taxpayer. Inventory and other property held mainly for sale to customers in a trade or 4

business are examples of property that is not a capital asset. See Publication 544 for more information about capital assets and the character of gain or loss.

Q-8: Does a taxpayer who “mines” virtual currency (for example, uses computer resources to validate Bitcoin transactions and maintain the public Bitcoin transaction ledger) realize gross income upon receipt of the virtual currency resulting from those activities?

A-8: Yes, when a taxpayer successfully “mines” virtual currency, the fair market value of the virtual currency as of the date of receipt is includible in gross income. See Publication 525, Taxable and Nontaxable Income, for more information on taxable income.

Q-9: Is an individual who “mines” virtual currency as a trade or business subject to self-employment tax on the income derived from those activities?

A-9: If a taxpayer’s “mining” of virtual currency constitutes a trade or business, and the “mining” activity is not undertaken by the taxpayer as an employee, the net earnings from self-employment (generally, gross income derived from carrying on a trade or business less allowable deductions) resulting from those activities constitute self- employment income and are subject to the self-employment tax. See Chapter 10 of Publication 334, Tax Guide for Small Business, for more information on self- employment tax and Publication 535, Business Expenses, for more information on determining whether expenses are from a business activity carried on to make a profit.

Q-10: Does virtual currency received by an independent contractor for performing services constitute self-employment income?

A-10: Yes. Generally, self-employment income includes all gross income derived by an individual from any trade or business carried on by the individual as other than an employee. Consequently, the fair market value of virtual currency received for services performed as an independent contractor, measured in U.S. dollars as of the date of receipt, constitutes self-employment income and is subject to the self-employment tax. See FS-2007-18, April 2007, Business or Hobby? Answer Has Implications for Deductions, for information on determining whether an activity is a business or a hobby.

Q-11: Does virtual currency paid by an employer as remuneration for services constitute wages for employment tax purposes?

A-11: Yes. Generally, the medium in which remuneration for services is paid is immaterial to the determination of whether the remuneration constitutes wages for employment tax purposes. Consequently, the fair market value of virtual currency paid as wages is subject to federal income tax withholding, Federal Insurance Contributions 5

Act (FICA) tax, and Federal Unemployment Tax Act (FUTA) tax and must be reported on Form W-2, Wage and Tax Statement. See Publication 15 (Circular E), Employer’s Tax Guide, for information on the withholding, depositing, reporting, and paying of employment taxes.

Q-12: Is a payment made using virtual currency subject to information reporting?

A-12: A payment made using virtual currency is subject to information reporting to the same extent as any other payment made in property. For example, a person who in the course of a trade or business makes a payment of fixed and determinable income using virtual currency with a value of $600 or more to a U.S. non-exempt recipient in a taxable year is required to report the payment to the IRS and to the payee. Examples of payments of fixed and determinable income include rent, salaries, wages, premiums, annuities, and compensation.

Q-13: Is a person who in the course of a trade or business makes a payment using virtual currency worth $600 or more to an independent contractor for performing services required to file an information return with the IRS?

A-13: Generally, a person who in the course of a trade or business makes a payment of $600 or more in a taxable year to an independent contractor for the performance of services is required to report that payment to the IRS and to the payee on Form 1099- MISC, Miscellaneous Income. Payments of virtual currency required to be reported on Form 1099-MISC should be reported using the fair market value of the virtual currency in U.S. dollars as of the date of payment. The payment recipient may have income even if the recipient does not receive a Form 1099-MISC. See the Instructions to Form 1099-MISC and the General Instructions for Certain Information Returns for more information. For payments to non-U.S. persons, see Publication 515, Withholding of Tax on Nonresident Aliens and Foreign Entities.

Q-14: Are payments made using virtual currency subject to backup withholding?

A-14: Payments made using virtual currency are subject to backup withholding to the same extent as other payments made in property. Therefore, payors making reportable payments using virtual currency must solicit a taxpayer identification number (TIN) from the payee. The payor must backup withhold from the payment if a TIN is not obtained prior to payment or if the payor receives notification from the IRS that backup withholding is required. See Publication 1281, Backup Withholding for Missing and Incorrect Name/TINs, for more information.

Q-15: Are there IRS information reporting requirements for a person who settles payments made in virtual currency on behalf of merchants that accept virtual currency from their customers? 6

A-15: Yes, if certain requirements are met. In general, a third party that contracts with a substantial number of unrelated merchants to settle payments between the merchants and their customers is a third party settlement organization (TPSO). A TPSO is required to report payments made to a merchant on a Form 1099-K, Payment Card and Third Party Network Transactions, if, for the calendar year, both (1) the number of transactions settled for the merchant exceeds 200, and (2) the gross amount of payments made to the merchant exceeds $20,000. When completing Boxes 1, 3, and 5a-1 on the Form 1099-K, transactions where the TPSO settles payments made with virtual currency are aggregated with transactions where the TPSO settles payments made with real currency to determine the total amounts to be reported in those boxes. When determining whether the transactions are reportable, the value of the virtual currency is the fair market value of the virtual currency in U.S. dollars on the date of payment.

See The Third Party Information Reporting Center, http://www.irs.gov/Tax- Professionals/Third-Party-Reporting-Information-Center, for more information on reporting transactions on Form 1099-K.

Q-16: Will taxpayers be subject to penalties for having treated a virtual currency transaction in a manner that is inconsistent with this notice prior to March 25, 2014?

A-16: Taxpayers may be subject to penalties for failure to comply with tax laws. For example, underpayments attributable to virtual currency transactions may be subject to penalties, such as accuracy-related penalties under section 6662. In addition, failure to timely or correctly report virtual currency transactions when required to do so may be subject to information reporting penalties under section 6721 and 6722. However, penalty relief may be available to taxpayers and persons required to file an information return who are able to establish that the underpayment or failure to properly file information returns is due to reasonable cause.

SECTION 5. DRAFTING INFORMATION

The principal author of this notice is Keith A. Aqui of the Office of Associate Chief Counsel (Income Tax & Accounting). For further information about income tax issues addressed in this notice, please contact Mr. Aqui at (202) 317-4718; for further information about employment tax issues addressed in this notice, please contact Mr. Neil D. Shepherd at (202) 317- 4774; for further information about information reporting issues addressed in this notice, please contact Ms. Adrienne E. Griffin at (202) 317- 6845; and for further information regarding foreign currency issues addressed in this notice, please contact Mr. Raymond J. Stahl at (202) 317- 6938. These are not toll-free calls.

S.B. 398

SENATE BILL NO. 398–SENATOR KIECKHEFER

MARCH 20, 2017 ______

Referred to Committee on Judiciary

SUMMARY—Establishes various provisions relating to the use of blockchain technology. (BDR 59-158)

FISCAL NOTE: Effect on Local Government: No. Effect on the State: No.

EXPLANATION – Matter in bolded italics is new; matter between brackets [omitted material] is material to be omitted.

AN ACT relating to electronic transactions; recognizing and authorizing the use of blockchain technology; prohibiting a local government from taxing or imposing restrictions upon the use of a blockchain; and providing other matters properly relating thereto.

Legislative Counsel’s Digest: 1 Existing law gives legal recognition to electronic records, signatures and 2 contracts that comply with certain requirements and allows an electronic record or 3 signature to satisfy a requirement for a written record or signature in certain 4 circumstances. (NRS 719.240-719.350) Sections 2-10 of this bill provide similarly 5 for the legal recognition of the use of blockchain technology for similar purposes. 6 Section 11 of this bill prohibits a local government from: (1) imposing a tax or fee 7 on the use of a blockchain; (2) requiring a certificate, license or permit to use a 8 blockchain; and (3) imposing any other requirement relating to the use of a 9 blockchain.

THE PEOPLE OF THE STATE OF NEVADA, REPRESENTED IN SENATE AND ASSEMBLY, DO ENACT AS FOLLOWS:

1 Section 1. Title 59 of NRS is hereby amended by adding 2 thereto a new chapter to consist of the provisions set forth as 3 sections 2 to 13, inclusive, of this act. 4 Sec. 2. As used in this chapter, unless the context otherwise 5 requires, the words and terms defined in sections 3 to 9, inclusive, 6 of this act have the meanings ascribed to them in those sections.

- *SB398*

– 2 –

1 Sec. 3. “Agreement” has the meaning ascribed to it in NRS 2 719.030. The term includes an agreement formed by use of one or 3 more electronic agents, as defined in NRS 719.080. 4 Sec. 4. “Blockchain” means an electronic record created by 5 the use of a decentralized method by multiple parties to verify and 6 store a digital record of transactions which is secured by the use of 7 a cryptographic hash of previous transaction information. 8 Sec. 5. “Cryptographic hash” means a mathematical 9 algorithm which performs a one-way conversion of input data into 10 output data of a specified size to verify the integrity of the data. 11 Sec. 6. “Electronic” has the meaning ascribed to it in 12 NRS 719.070. 13 Sec. 7. “Electronic record” has the meaning ascribed to it in 14 NRS 719.090. 15 Sec. 8. “Record” has the meaning ascribed to it in 16 NRS 719.150. 17 Sec. 9. “Smart contract” means a contract stored as an 18 electronic record pursuant to chapter 719 of NRS which is verified 19 by the use of a blockchain. 20 Sec. 10. For the purposes of NRS 719.260 to 719.290, 21 inclusive, and 719.310 to 719.350, inclusive, a blockchain or a 22 smart contract shall be deemed to be an electronic record. 23 Sec. 11. 1. A smart contract, record or signature may not 24 be denied legal effect or enforceability solely because a blockchain 25 was used to create, store or verify the smart contract, record or 26 signature. 27 2. In a proceeding, evidence of a smart contract, record or 28 signature must not be excluded solely because a blockchain was 29 used to create, store or verify the smart contract, record or 30 signature. 31 3. If a law requires a record to be in writing, submission of a 32 blockchain which electronically contains the record satisfies the 33 law. 34 4. If a law requires a signature, submission of a blockchain 35 which electronically contains the signature or verifies the intent of 36 a person to provide the signature satisfies the law. 37 Sec. 12. 1. If parties have agreed to conduct a transaction 38 by use of a blockchain and a law requires that a contract or other 39 record relating to the transaction be in writing, the legal effect, 40 validity or enforceability of the contract or other record may be 41 denied if the blockchain containing an electronic record of the 42 transaction is not in a form that is capable of being retained and 43 accurately reproduced for later reference by all parties or other 44 persons who are entitled to retain the contract or other record.

- *SB398*

– 3 –

1 2. Except as otherwise provided in subsection 6, if a law other 2 than this chapter requires a record to be posted or displayed in 3 a certain manner, to be sent, communicated or transmitted by a 4 specified method or to contain information that is formatted in a 5 certain matter, the use of a blockchain to post, display, send, 6 communicate, transmit or store such a record does not satisfy the 7 requirement of the other law. 8 3. If a person inhibits the ability of another person to store or 9 retrieve information contained in a blockchain, such information 10 is not enforceable by the person who inhibited the storage or 11 retrieval. 12 4. Regardless of whether a smart contract was used to 13 establish the relationship between the parties to an agreement, a 14 requirement that a notice or an acknowledgment or other response 15 to a notice be in writing is not satisfied by providing or delivering 16 the notice or recording an acknowledgment or other response to 17 the notice by the use of a blockchain if the notice is a notice of: 18 (a) The cancellation or termination of service by a public 19 utility; 20 (b) Default, acceleration, repossession, foreclosure or eviction, 21 or the right to cure, under a credit agreement secured by, or a 22 rental agreement for, a primary residence of a natural person; 23 (c) The cancellation or termination of a policy of health 24 insurance, benefits received pursuant to a policy of health 25 insurance or benefits received pursuant to a policy of life 26 insurance, excluding annuities; or 27 (d) The recall of a product, or material failure of a product, 28 that risks endangering the health or safety of a person. 29 5. A requirement that a document be in writing is not 30 satisfied by the use of a blockchain if the document is required to 31 accompany any transportation or handling of hazardous 32 materials, pesticides or other toxic or dangerous materials. 33 6. The requirements of this section may not be varied by 34 agreement, except that: 35 (a) To the extent a law other than this chapter requires that a 36 contract or other record relating to a transaction be in writing but 37 permits that requirement to be varied by agreement, the provisions 38 of subsection 1 concerning the denial of legal effect, validity or 39 enforceability of the contract or other record relating to the 40 transaction may also be varied by agreement; and 41 (b) A requirement under a law other than this chapter to send, 42 communicate or transmit a record by first-class mail, postage 43 prepaid, regular United States mail, may be varied by agreement to 44 the extent permitted by the other law.

- *SB398*

– 4 –

1 Sec. 13. 1. A local governmental entity shall not: 2 (a) Impose any tax or fee on the use of a blockchain or smart 3 contract by any person or entity; 4 (b) Require any person or entity to obtain from the local 5 governmental entity any certificate, license or permit to use a 6 blockchain or smart contract; or 7 (c) Impose any other requirement relating to the use of a 8 blockchain or smart contract by any person or entity. 9 2. Nothing in this section prohibits a local governmental 10 entity from using a blockchain or smart contract in the 11 performance of its powers or duties in a manner not inconsistent 12 with the provisions of this chapter. 13 Sec. 14. This act becomes effective upon passage and 14 approval.

- *SB398* SECURITIES AND EXCHANGE COMMISSION

SECURITIES EXCHANGE ACT OF 1934

Release No. 81207 / July 25, 2017

Report of Investigation Pursuant to Section 21(a) of the Securities Exchange Act of 1934: The DAO

I. Introduction and Summary

The United States Securities and Exchange Commission’s (“Commission”) Division of Enforcement (“Division”) has investigated whether The DAO, an unincorporated organization; Slock.it UG (“Slock.it”), a German corporation; Slock.it’s co-founders; and intermediaries may have violated the federal securities laws. The Commission has determined not to pursue an enforcement action in this matter based on the conduct and activities known to the Commission at this time.

As described more fully below, The DAO is one example of a Decentralized Autonomous Organization, which is a term used to describe a “virtual” organization embodied in computer code and executed on a distributed ledger or blockchain. The DAO was created by Slock.it and Slock.it’s co-founders, with the objective of operating as a for-profit entity that would create and hold a corpus of assets through the sale of DAO Tokens to investors, which assets would then be used to fund “projects.” The holders of DAO Tokens stood to share in the anticipated earnings from these projects as a return on their investment in DAO Tokens. In addition, DAO Token holders could monetize their investments in DAO Tokens by re-selling DAO Tokens on a number of web-based platforms (“Platforms”) that supported secondary trading in the DAO Tokens.

After DAO Tokens were sold, but before The DAO was able to commence funding projects, an attacker used a flaw in The DAO’s code to steal approximately one-third of The DAO’s assets. Slock.it’s co-founders and others responded by creating a work-around whereby DAO Token holders could opt to have their investment returned to them, as described in more detail below.

The investigation raised questions regarding the application of the U.S. federal securities laws to the offer and sale of DAO Tokens, including the threshold question whether DAO Tokens are securities. Based on the investigation, and under the facts presented, the Commission has determined that DAO Tokens are securities under the Securities Act of 1933 (“Securities Act”) and the Securities Exchange Act of 1934 (“Exchange Act”).1 The Commission deems it appropriate and in the public interest to issue this report of investigation (“Report”) pursuant to

1 This Report does not analyze the question whether The DAO was an “investment company,” as defined under Section 3(a) of the Investment Company Act of 1940 (“Investment Company Act”), in part, because The DAO never commenced its business operations funding projects. Those who would use virtual organizations should consider their obligations under the Investment Company Act.

1 Section 21(a) of the Exchange Act2 to advise those who would use a Decentralized Autonomous Organization (“DAO Entity”), or other distributed ledger or blockchain-enabled means for capital raising, to take appropriate steps to ensure compliance with the U.S. federal securities laws. All securities offered and sold in the United States must be registered with the Commission or must qualify for an exemption from the registration requirements. In addition, any entity or person engaging in the activities of an exchange must register as a national securities exchange or operate pursuant to an exemption from such registration.

This Report reiterates these fundamental principles of the U.S. federal securities laws and describes their applicability to a new paradigm—virtual organizations or capital raising entities that use distributed ledger or blockchain technology to facilitate capital raising and/or investment and the related offer and sale of securities. The automation of certain functions through this technology, “smart contracts,”3 or computer code, does not remove conduct from the purview of the U.S. federal securities laws.4 This Report also serves to stress the obligation to comply with the registration provisions of the federal securities laws with respect to products and platforms involving emerging technologies and new investor interfaces.

II. Facts

A. Background

From April 30, 2016 through May 28, 2016, The DAO offered and sold approximately 1.15 billion DAO Tokens in exchange for a total of approximately 12 million Ether (“ETH”), a

2 Section 21(a) of the Exchange Act authorizes the Commission to investigate violations of the federal securities laws and, in its discretion, to “publish information concerning any such violations.” This Report does not constitute an adjudication of any fact or issue addressed herein, nor does it make any findings of violations by any individual or entity. The facts discussed in Section II, infra, are matters of public record or based on documentary records. We are publishing this Report on the Commission’s website to ensure that all market participants have concurrent and equal access to the information contained herein. 3 Computer scientist Nick Szabo described a “smart contract” as: a computerized transaction protocol that executes terms of a contract. The general objectives of smart contract design are to satisfy common contractual conditions (such as payment terms, liens, confidentiality, and even enforcement), minimize exceptions both malicious and accidental, and minimize the need for trusted intermediaries. Related economic goals include lowering fraud loss, arbitrations and enforcement costs, and other transaction costs. See Nick Szabo, Smart Contracts, 1994, http://www.virtualschool.edu/mon/Economics/SmartContracts.html. 4 See SEC v. C.M. Joiner Leasing Corp., 320 U.S. 344, 351 (1943) (“[T]he reach of the [Securities] Act does not stop with the obvious and commonplace. Novel, uncommon, or irregular devices, whatever they appear to be, are also reached if it be proved as matter of fact that they were widely offered or dealt in under terms or courses of dealing which established their character in commerce as ‘investment contracts,’ or as ‘any interest or instrument commonly known as a ‘security’.”); see also Reves v. Ernst & Young, 494 U.S. 56, 61 (1990) (“Congress’ purpose in enacting the securities laws was to regulate investments, in whatever form they are made and by whatever name they are called.”).

2 virtual currency5 used on the Ethereum Blockchain.6 As of the time the offering closed, the total ETH raised by The DAO was valued in U.S. Dollars (“USD”) at approximately $150 million.

The concept of a DAO Entity is memorialized in a document (the “White Paper”), authored by Christoph Jentzsch, the Chief Technology Officer of Slock.it, a “Blockchain and IoT [(internet-of-things)] solution company,” incorporated in Germany and co-founded by Christoph Jentzsch, Simon Jentzsch (Christoph Jentzsch’s brother), and Stephan Tual (“Tual”).7 The White Paper purports to describe “the first implementation of a [DAO Entity] code to automate organizational governance and decision making.”8 The White Paper posits that a DAO Entity “can be used by individuals working together collaboratively outside of a traditional corporate form. It can also be used by a registered corporate entity to automate formal governance rules contained in corporate bylaws or imposed by law.” The White Paper proposes an entity—a DAO Entity—that would use smart contracts to attempt to solve governance issues it described as inherent in traditional corporations.9 As described, a DAO Entity purportedly would supplant traditional mechanisms of corporate governance and management with a blockchain such that contractual terms are “formalized, automated and enforced using software.”10

5 The Financial Action Task Force defines “virtual currency” as: a digital representation of value that can be digitally traded and functions as: (1) a medium of exchange; and/or (2) a unit of account; and/or (3) a store of value, but does not have legal tender status (i.e., when tendered to a creditor, is a valid and legal offer of payment) in any jurisdiction. It is not issued or guaranteed by any jurisdiction, and fulfils the above functions only by agreement within the community of users of the virtual currency. Virtual currency is distinguished from fiat currency (a.k.a. “real currency,” “real money,” or “national currency”), which is the coin and paper money of a country that is designated as its legal tender; circulates; and is customarily used and accepted as a medium of exchange in the issuing country. It is distinct from e-money, which is a digital representation of fiat currency used to electronically transfer value denominated in fiat currency.

FATF Report, Virtual Currencies, Key Definitions and Potential AML/CFT Risks, FINANCIAL ACTION TASK FORCE (June 2014), http://www.fatf-gafi.org/media/fatf/documents/reports/Virtual-currency-key-definitions-and-potential- aml-cft-risks.pdf. 6 Ethereum, developed by the Ethereum Foundation, a Swiss nonprofit organization, is a decentralized platform that runs smart contracts on a blockchain known as the Ethereum Blockchain. 7 Christoph Jentzsch released the final draft of the White Paper on or around March 23, 2016. He introduced his concept of a DAO Entity as early as November 2015 at an Ethereum Developer Conference in London, as a medium to raise funds for Slock.it, a German start-up he co-founded in September 2015. Slock.it purports to create technology that embeds smart contracts that run on the Ethereum Blockchain into real-world devices and, as a result, for example, permits anyone to rent, sell or share physical objects in a decentralized way. See SLOCK.IT, https://slock.it/. 8 Christoph Jentzsch, Decentralized Autonomous Organization to Automate Governance Final Draft – Under Review, https://download.slock.it/public/DAO/WhitePaper.pdf. 9 Id. 10 Id. The White Paper contained the following statement: A word of caution, at the outset: the legal status of [DAO Entities] remains the subject of active and vigorous debate and discussion. Not everyone shares the same definition. Some have said that [DAO Entities] are autonomous code and can operate independently of legal systems; others

3 B. The DAO

“The DAO” is the “first generation” implementation of the White Paper concept of a DAO Entity, and it began as an effort to create a “crowdfunding contract” to raise “funds to grow [a] company in the crypto space.”11 In November 2015, at an Ethereum Developer Conference in London, Christoph Jentzsch described his proposal for The DAO as a “for-profit DAO [Entity],” where participants would send ETH (a virtual currency) to The DAO to purchase DAO Tokens, which would permit the participant to vote and entitle the participant to “rewards.”12 Christoph Jentzsch likened this to “buying shares in a company and getting … dividends.”13 The DAO was to be “decentralized” in that it would allow for voting by investors holding DAO Tokens.14 All funds raised were to be held at an Ethereum Blockchain “address” associated with The DAO and DAO Token holders were to vote on contract proposals, including proposals to The DAO to fund projects and distribute The DAO’s anticipated earnings from the projects it funded.15 The DAO was intended to be “autonomous” in that project proposals were in the form of smart contracts that exist on the Ethereum Blockchain and the votes were administered by the code of The DAO.16

have said that [DAO Entities] must be owned or operate[d] by humans or human created entities. There will be many use cases, and the DAO [Entity] code will develop over time. Ultimately, how a DAO [Entity] functions and its legal status will depend on many factors, including how DAO [Entity] code is used, where it is used, and who uses it. This paper does not speculate about the legal status of [DAO Entities] worldwide. This paper is not intended to offer legal advice or conclusions. Anyone who uses DAO [Entity] code will do so at their own risk. Id. 11 Christoph Jentzsch, The History of the DAO and Lessons Learned, SLOCK.IT BLOG (Aug. 24, 2016), https://blog.slock.it/the-history-of-the-dao-and-lessons-learned-d06740f8cfa5#.5o62zo8uv. Although The DAO has been described as a “crowdfunding contract,” The DAO would not have met the requirements of Regulation Crowdfunding, adopted under Title III of the Jumpstart Our Business Startups (JOBS) Act of 2012 (providing an exemption from registration for certain crowdfunding), because, among other things, it was not a broker-dealer or a funding portal registered with the SEC and the Financial Industry Regulatory Authority (“FINRA”). See Regulation Crowdfunding: A Small Entity Compliance Guide for Issuers, SEC (Apr. 5, 2017), https://www.sec.gov/info/smallbus/secg/rccomplianceguide-051316.htm; Updated Investor Bulletin: Crowdfunding for Investors, SEC (May 10, 2017), https://www.sec.gov/oiea/investor-alerts-bulletins/ib_crowdfunding-.html. 12 See Slockit, Slock.it DAO demo at Devcon1: IoT + Blockchain, YOUTUBE (Nov. 13, 2015), https://www.youtube.com/watch?v=49wHQoJxYPo. 13 Id. 14 See Jentzsch, supra note 8. 15 Id. In theory, there was no limitation on the type of project that could be proposed. For example, proposed “projects” could include, among other things, projects that would culminate in the creation of products or services that DAO Token holders could use or charge others for using. 16 Id.

4 On or about April 29, 2016, Slock.it deployed The DAO code on the Ethereum Blockchain, as a set of pre-programmed instructions.17 This code was to govern how The DAO was to operate.

To promote The DAO, Slock.it’s co-founders launched a website (“The DAO Website”). The DAO Website included a description of The DAO’s intended purpose: “To blaze a new path in business for the betterment of its members, existing simultaneously nowhere and everywhere and operating solely with the steadfast iron will of unstoppable code.”18 The DAO Website also described how The DAO operated, and included a link through which DAO Tokens could be purchased. The DAO Website also included a link to the White Paper, which provided detailed information about a DAO Entity’s structure and its source code and, together with The DAO Website, served as the primary source of promotional materials for The DAO. On The DAO Website and elsewhere, Slock.it represented that The DAO’s source code had been reviewed by “one of the world’s leading security audit companies” and “no stone was left unturned during those five whole days of security analysis.”19

Slock.it’s co-founders also promoted The DAO by soliciting media attention and by posting almost daily updates on The DAO’s status on The DAO and Slock.it websites and numerous online forums relating to blockchain technology. Slock.it’s co-founders used these posts to communicate to the public information about how to participate in The DAO, including: how to create and acquire DAO Tokens; the framework for submitting proposals for projects; and how to vote on proposals. Slock.it also created an online forum on The DAO Website, as well as administered “The DAO Slack” channel, an online messaging platform in which over 5,000 invited “team members” could discuss and exchange ideas about The DAO in real time.

1. DAO Tokens

In exchange for ETH, The DAO created DAO Tokens (proportional to the amount of ETH paid) that were then assigned to the Ethereum Blockchain address of the person or entity remitting the ETH. A DAO Token granted the DAO Token holder certain voting and ownership rights. According to promotional materials, The DAO would earn profits by funding projects

17 According to the White Paper, a DAO Entity is “activated by deployment on the Ethereum [B]lockchain. Once deployed, a [DAO Entity’s] code requires ‘ether’ [ETH] to engage in transactions on Ethereum. Ether is the digital fuel that powers the Ethereum Network.” The only way to update or alter The DAO’s code is to submit a new proposal for voting and achieve a majority consensus on that proposal. See Jentzsch, supra note 8. According to Slock.it’s website, Slock.it gave The DAO code to the Ethereum community, noting that: The DAO framework is [a] side project of Slock.it UG and a gift to the Ethereum community. It consisted of a definitive whitepaper, smart contract code audited by one of the best security companies in the world and soon, a complete frontend interface. All free and open source for anyone to re-use, it is our way to say ‘thank you’ to the community.

SLOCK.IT, https://slock.it. The DAO code is publicly-available on GitHub, a host of source code. See The Standard DAO Framework, Inc., Whitepaper, GITHUB, https://github.com/slockit/DAO. 18 The DAO Website was available at https://daohub.org. 19 Stephen Tual, Deja Vu DAO Smart Contracts Audit Results, SLOCK.IT BLOG (Apr. 5, 2016), https://blog.slock.it/deja-vu-dai-smart-contracts-audit-results-d26bc088e32e.

5 that would provide DAO Token holders a return on investment. The various promotional materials disseminated by Slock.it’s co-founders touted that DAO Token holders would receive “rewards,” which the White Paper defined as, “any [ETH] received by a DAO [Entity] generated from projects the DAO [Entity] funded.” DAO Token holders would then vote to either use the rewards to fund new projects or to distribute the ETH to DAO Token holders.

From April 30, 2016 through May 28, 2016 (the “Offering Period”), The DAO offered and sold DAO Tokens. Investments in The DAO were made “pseudonymously” (i.e., an individual’s or entity’s pseudonym was their Ethereum Blockchain address). To purchase a DAO Token offered for sale by The DAO, an individual or entity sent ETH from their Ethereum Blockchain address to an Ethereum Blockchain address associated with The DAO. All of the ETH raised in the offering as well as any future profits earned by The DAO were to be pooled and held in The DAO’s Ethereum Blockchain address. The token price fluctuated in a range of approximately 1 to 1.5 ETH per 100 DAO Tokens, depending on when the tokens were purchased during the Offering Period. Anyone was eligible to purchase DAO Tokens (as long as they paid ETH). There were no limitations placed on the number of DAO Tokens offered for sale, the number of purchasers of DAO Tokens, or the level of sophistication of such purchasers.

DAO Token holders were not restricted from re-selling DAO Tokens acquired in the offering, and DAO Token holders could sell their DAO Tokens in a variety of ways in the secondary market and thereby monetize their investment as discussed below. Prior to the Offering Period, Slock.it solicited at least one U.S. web-based platform to trade DAO Tokens on its system and, at the time of the offering, The DAO Website and other promotional materials disseminated by Slock.it included representations that DAO Tokens would be available for secondary market trading after the Offering Period via several platforms. During the Offering Period and afterwards, the Platforms posted notices on their own websites and on social media that each planned to support secondary market trading of DAO Tokens.20

In addition to secondary market trading on the Platforms, after the Offering Period, DAO Tokens were to be freely transferable on the Ethereum Blockchain. DAO Token holders would also be permitted to redeem their DAO Tokens for ETH through a complicated, multi-week (approximately 46-day) process referred to as a DAO Entity “split.”21

2. Participants in The DAO

According to the White Paper, in order for a project to be considered for funding with “a DAO [Entity]’s [ETH],” a “Contractor” first must submit a proposal to the DAO Entity. Specifically, DAO Token holders expected Contractors to submit proposals for projects that could provide DAO Token holders returns on their investments. Submitting a proposal to The DAO involved: (1) writing a smart contract, and then deploying and publishing it on the

20 The Platforms are registered with FinCEN as “Money Services Businesses” and provide systems whereby customers may exchange virtual currencies for other virtual currencies or fiat currencies. 21 According to the White Paper, the primary purpose of a split is to protect minority shareholders and prevent what is commonly referred to as a “51% Attack,” whereby an attacker holding 51% of a DAO Entity’s Tokens could create a proposal to send all of the DAO Entity’s funds to himself or herself.

6 Ethereum Blockchain; and (2) posting details about the proposal on The DAO Website, including the Ethereum Blockchain address of the deployed contract and a link to its source code. Proposals could be viewed on The DAO Website as well as other publicly-accessible websites. Per the White Paper, there were two prerequisites for submitting a proposal. An individual or entity must: (1) own at least one DAO Token; and (2) pay a deposit in the form of ETH that would be forfeited to the DAO Entity if the proposal was put up for a vote and failed to achieve a quorum of DAO Token holders. It was publicized that Slock.it would be the first to submit a proposal for funding.22

ETH raised by The DAO was to be distributed to a Contractor to fund a proposal only on a majority vote of DAO Token holders.23 DAO Token holders were to cast votes, which would be weighted by the number of tokens they controlled, for or against the funding of a specific proposal. The voting process, however, was publicly criticized in that it could incentivize distorted voting behavior and, as a result, would not accurately reflect the consensus of the majority of DAO Token holders. Specifically, as noted in a May 27, 2016 blog post by a group of computer security researchers, The DAO’s structure included a “strong positive bias to vote YES on proposals and to suppress NO votes as a side effect of the way in which it restricts users’ range of options following the casting of a vote.”24

Before any proposal was put to a vote by DAO Token holders, it was required to be reviewed by one or more of The DAO’s “Curators.” At the time of the formation of The DAO, the Curators were a group of individuals chosen by Slock.it.25 According to the White Paper, the Curators of a DAO Entity had “considerable power.” The Curators performed crucial security functions and maintained ultimate control over which proposals could be submitted to, voted on, and funded by The DAO. As stated on The DAO Website during the Offering Period, The DAO relied on its Curators for “failsafe protection” and for protecting The DAO from “malicous [sic] actors.” Specifically, per The DAO Website, a Curator was responsible for: (1) confirming that any proposal for funding originated from an identifiable person or organization; and (2)

22 It was stated on The DAO Website and elsewhere that Slock.it anticipated that it would be the first to submit a proposal for funding. In fact, a draft of Slock.it’s proposal for funding for an “Ethereum Computer and Universal Sharing Network” was publicly-available online during the Offering Period. 23 DAO Token holders could vote on proposals, either by direct interaction with the Ethereum Blockchain or by using an application that interfaces with the Ethereum Blockchain. It was generally acknowledged that DAO Token holders needed some technical knowledge in order to submit a vote, and The DAO Website included a link to a step- by-step tutorial describing how to vote on proposals. 24 By voting on a proposal, DAO Token holders would “tie up” their tokens until the end of the voting cycle. See Jentzsch, supra note 8 at 8 (“The tokens used to vote will be blocked, meaning they can not [sic] be transferred until the proposal is closed.”). If, however, a DAO Token holder abstained from voting, the DAO Token holder could avoid these restrictions; any DAO Tokens not submitted for a vote could be withdrawn or transferred at any time. As a result, DAO Token holders were incentivized either to vote yes or to abstain from voting. See Dino Mark et al., A Call for a Temporary Moratorium on The DAO, HACKING, DISTRIBUTED (May 27, 2016, 1:35 PM), http://hackingdistributed.com/2016/05/27/dao-call-for-moratorium/. 25 At the time of The DAO’s launch, The DAO Website identified eleven “high profile” individuals as holders of The DAO’s Curator “Multisig” (or “private key”). These individuals all appear to live outside of the United States. Many of them were associated with the Ethereum Foundation, and The DAO Website touted the qualifications and trustworthiness of these individuals.

7 confirming that smart contracts associated with any such proposal properly reflected the code the Contractor claims to have deployed on the Ethereum Blockchain. If a Curator determined that the proposal met these criteria, the Curator could add the proposal to the “whitelist,” which was a list of Ethereum Blockchain addresses that could receive ETH from The DAO if the majority of DAO Token holders voted for the proposal.

Curators of The DAO had ultimate discretion as to whether or not to submit a proposal for voting by DAO Token holders. Curators also determined the order and frequency of proposals, and could impose subjective criteria for whether the proposal should be whitelisted. One member of the group chosen by Slock.it to serve collectively as the Curator stated publicly that the Curator had “complete control over the whitelist … the order in which things get whitelisted, the duration for which [proposals] get whitelisted, when things get unwhitelisted … [and] clear ability to control the order and frequency of proposals,” noting that “curators have tremendous power.”26 Another Curator publicly announced his subjective criteria for determining whether to whitelist a proposal, which included his personal ethics.27 Per the White Paper, a Curator also had the power to reduce the voting quorum requirement by 50% every other week. Absent action by a Curator, the quorum could be reduced by 50% only if no proposal had reached the required quorum for 52 weeks.

3. Secondary Market Trading on the Platforms

During the period from May 28, 2016 through early September 2016, the Platforms became the preferred vehicle for DAO Token holders to buy and sell DAO Tokens in the secondary market using virtual or fiat currencies. Specifically, the Platforms used electronic systems that allowed their respective customers to post orders for DAO Tokens on an anonymous basis. For example, customers of each Platform could buy or sell DAO Tokens by entering a market order on the Platform’s system, which would then match with orders from other customers residing on the system. Each Platform’s system would automatically execute these orders based on pre-programmed order interaction protocols established by the Platform.

None of the Platforms received orders for DAO Tokens from non-Platform customers or routed its respective customers’ orders to any other trading destinations. The Platforms publicly displayed all their quotes, trades, and daily trading volume in DAO Tokens on their respective websites. During the period from May 28, 2016 through September 6, 2016, one such Platform executed more than 557,378 buy and sell transactions in DAO Tokens by more than 15,000 of its U.S. and foreign customers. During the period from May 28, 2016 through August 1, 2016, another such Platform executed more than 22,207 buy and sell transactions in DAO Tokens by more than 700 of its U.S. customers.

26 Epicenter, EB134 – Emin Gün Sirer And Vlad Zamfir: On A Rocky DAO, YOUTUBE (June 6, 2016), https://www.youtube.com/watch?v=ON5GhIQdFU8. 27 Andrew Quentson, Are the DAO Curators Masters or Janitors?, THE COIN TELEGRAPH (June 12, 2016), https://cointelegraph.com/news/are-the-dao-curators-masters-or-janitors.

8 4. Security Concerns, The “Attack” on The DAO, and The Hard Fork

In late May 2016, just prior to the expiration of the Offering Period, concerns about the safety and security of The DAO’s funds began to surface due to vulnerabilities in The DAO’s code. On May 26, 2016, in response to these concerns, Slock.it submitted a “DAO Security Proposal” that called for the development of certain updates to The DAO’s code and the appointment of a security expert.28 Further, on June 3, 2016, Christoph Jentzsch, on behalf of Slock.it, proposed a moratorium on all proposals until alterations to The DAO’s code to fix vulnerabilities in The DAO’s code had been implemented.29

On June 17, 2016, an unknown individual or group (the “Attacker”) began rapidly diverting ETH from The DAO, causing approximately 3.6 million ETH—1/3 of the total ETH raised by The DAO offering—to move from The DAO’s Ethereum Blockchain address to an Ethereum Blockchain address controlled by the Attacker (the “Attack”).30 Although the diverted ETH was then held in an address controlled by the Attacker, the Attacker was prevented by The DAO’s code from moving the ETH from that address for 27 days.31

In order to secure the diverted ETH and return it to DAO Token holders, Slock.it’s co- founders and others endorsed a “Hard Fork” to the Ethereum Blockchain. The “Hard Fork,” called for a change in the Ethereum protocol on a going forward basis that would restore the DAO Token holders’ investments as if the Attack had not occurred. On July 20, 2016, after a majority of the Ethereum network adopted the necessary software updates, the new, forked Ethereum Blockchain became active.32 The Hard Fork had the effect of transferring all of the funds raised (including those held by the Attacker) from The DAO to a recovery address, where DAO Token holders could exchange their DAO Tokens for ETH.33 All DAO Token holders

28 See Stephan Tual, Proposal #1-DAO Security, Redux, SLOCK.IT BLOG (May 26, 2016), https://blog.slock.it/both- our-proposals-are-now-out-voting-starts-saturday-morning-ba322d6d3aea. The unnamed security expert would “act as the first point of contact for security disclosures, and continually monitor, pre-empt and avert any potential attack vectors The DAO may face, including social, technical and economic attacks.” Id. Slock.it initially proposed a much broader security proposal that included the formation of a “DAO Security” group, the establishment of a “Bug Bounty Program,” and routine external audits of The DAO’s code. However, the cost of the proposal (125,000 ETH), which would be paid from The DAO’s funds, was immediately criticized as too high and Slock.it decided instead to submit the revised proposal described above. See Stephan Tual, DAO.Security, a Proposal to guarantee the integrity of The DAO, SLOCK.IT BLOG (May 25, 2016), https://blog.slock.it/dao-security-a-proposal-to- guarantee-the-integrity-of-the-dao-3473899ace9d. 29 See TheDAO Proposal_ID 5, ETHERSCAN, https://etherscan.io/token/thedao-proposal/5. 30 See Stephan Tual, DAO Security Advisory: live updates, SLOCK.IT BLOG (June 17, 2016), https://blog.slock.it/dao- security-advisory-live-updates-2a0a42a2d07b. 31 Id. 32 A minority group, however, elected not to adopt the new Ethereum Blockchain created by the Hard Fork because to do so would run counter to the concept that a blockchain is immutable. Instead they continued to use the former version of the blockchain, which is now known as “Ethereum Classic.” 33 See Christoph Jentzsch, What the ‘Fork’ Really Means, SLOCK.IT BLOG (July 18, 2016), https://blog.slock.it/what- the-fork-really-means-6fe573ac31dd.

9 who adopted the Hard Fork could exchange their DAO Tokens for ETH, and avoid any loss of the ETH they had invested.34

III. Discussion

The Commission is aware that virtual organizations and associated individuals and entities increasingly are using distributed ledger technology to offer and sell instruments such as DAO Tokens to raise capital. These offers and sales have been referred to, among other things, as “Initial Coin Offerings” or “Token Sales.” Accordingly, the Commission deems it appropriate and in the public interest to issue this Report in order to stress that the U.S. federal securities law may apply to various activities, including distributed ledger technology, depending on the particular facts and circumstances, without regard to the form of the organization or technology used to effectuate a particular offer or sale. In this Report, the Commission considers the particular facts and circumstances of the offer and sale of DAO Tokens to demonstrate the application of existing U.S. federal securities laws to this new paradigm.

A. Section 5 of the Securities Act

The registration provisions of the Securities Act contemplate that the offer or sale of securities to the public must be accompanied by the “full and fair disclosure” afforded by registration with the Commission and delivery of a statutory prospectus containing information necessary to enable prospective purchasers to make an informed investment decision. Registration entails disclosure of detailed “information about the issuer’s financial condition, the identity and background of management, and the price and amount of securities to be offered … .” SEC v. Cavanagh, 1 F. Supp. 2d 337, 360 (S.D.N.Y. 1998), aff’d, 155 F.3d 129 (2d Cir. 1998). “The registration statement is designed to assure public access to material facts bearing on the value of publicly traded securities and is central to the Act’s comprehensive scheme for protecting public investors.” SEC v. Aaron, 605 F.2d 612, 618 (2d Cir. 1979) (citing SEC v. Ralston Purina Co., 346 U.S. 119, 124 (1953)), vacated on other grounds, 446 U.S. 680 (1980). Section 5(a) of the Securities Act provides that, unless a registration statement is in effect as to a security, it is unlawful for any person, directly or indirectly, to engage in the offer or sale of securities in interstate commerce. Section 5(c) of the Securities Act provides a similar prohibition against offers to sell, or offers to buy, unless a registration statement has been filed. Thus, both Sections 5(a) and 5(c) of the Securities Act prohibit the unregistered offer or sale of securities in interstate commerce. 15 U.S.C. § 77e(a) and (c). Violations of Section 5 do not require scienter. SEC v. Universal Major Indus. Corp., 546 F.2d 1044, 1047 (2d Cir. 1976).

34 Id.

10 B. DAO Tokens Are Securities

1. Foundational Principles of the Securities Laws Apply to Virtual Organizations or Capital Raising Entities Making Use of Distributed Ledger Technology

Under Section 2(a)(1) of the Securities Act and Section 3(a)(10) of the Exchange Act, a security includes “an investment contract.” See 15 U.S.C. §§ 77b-77c. An investment contract is an investment of money in a common enterprise with a reasonable expectation of profits to be derived from the entrepreneurial or managerial efforts of others. See SEC v. Edwards, 540 U.S. 389, 393 (2004); SEC v. W.J. Howey Co., 328 U.S. 293, 301 (1946); see also United Housing Found., Inc. v. Forman, 421 U.S. 837, 852-53 (1975) (The “touchstone” of an investment contract “is the presence of an investment in a common venture premised on a reasonable expectation of profits to be derived from the entrepreneurial or managerial efforts of others.”). This definition embodies a “flexible rather than a static principle, one that is capable of adaptation to meet the countless and variable schemes devised by those who seek the use of the money of others on the promise of profits.” Howey, 328 U.S. at 299 (emphasis added). The test “permits the fulfillment of the statutory purpose of compelling full and fair disclosure relative to the issuance of ‘the many types of instruments that in our commercial world fall within the ordinary concept of a security.’” Id. In analyzing whether something is a security, “form should be disregarded for substance,” Tcherepnin v. Knight, 389 U.S. 332, 336 (1967), “and the emphasis should be on economic realities underlying a transaction, and not on the name appended thereto.” United Housing Found., 421 U.S. at 849.

2. Investors in The DAO Invested Money

In determining whether an investment contract exists, the investment of “money” need not take the form of cash. See, e.g., Uselton v. Comm. Lovelace Motor Freight, Inc., 940 F.2d 564, 574 (10th Cir. 1991) (“[I]n spite of Howey’s reference to an ‘investment of money,’ it is well established that cash is not the only form of contribution or investment that will create an investment contract.”).

Investors in The DAO used ETH to make their investments, and DAO Tokens were received in exchange for ETH. Such investment is the type of contribution of value that can create an investment contract under Howey. See SEC v. Shavers, No. 4:13-CV-416, 2014 WL 4652121, at *1 (E.D. Tex. Sept. 18, 2014) (holding that an investment of Bitcoin, a virtual currency, meets the first prong of Howey); Uselton, 940 F.2d at 574 (“[T]he ‘investment’ may take the form of ‘goods and services,’ or some other ‘exchange of value’.”) (citations omitted).

3. With a Reasonable Expectation of Profits

Investors who purchased DAO Tokens were investing in a common enterprise and reasonably expected to earn profits through that enterprise when they sent ETH to The DAO’s Ethereum Blockchain address in exchange for DAO Tokens. “[P]rofits” include “dividends, other periodic payments, or the increased value of the investment.” Edwards, 540 U.S. at 394. As described above, the various promotional materials disseminated by Slock.it and its co- founders informed investors that The DAO was a for-profit entity whose objective was to fund

11 projects in exchange for a return on investment.35 The ETH was pooled and available to The DAO to fund projects. The projects (or “contracts”) would be proposed by Contractors. If the proposed contracts were whitelisted by Curators, DAO Token holders could vote on whether The DAO should fund the proposed contracts. Depending on the terms of each particular contract, DAO Token holders stood to share in potential profits from the contracts. Thus, a reasonable investor would have been motivated, at least in part, by the prospect of profits on their investment of ETH in The DAO.

4. Derived from the Managerial Efforts of Others

a. The Efforts of Slock.it, Slock.it’s Co-Founders, and The DAO’s Curators Were Essential to the Enterprise

Investors’ profits were to be derived from the managerial efforts of others—specifically, Slock.it and its co-founders, and The DAO’s Curators. The central issue is “whether the efforts made by those other than the investor are the undeniably significant ones, those essential managerial efforts which affect the failure or success of the enterprise.” SEC v. Glenn W. Turner Enters., Inc., 474 F.2d 476, 482 (9th Cir. 1973). The DAO’s investors relied on the managerial and entrepreneurial efforts of Slock.it and its co-founders, and The DAO’s Curators, to manage The DAO and put forth project proposals that could generate profits for The DAO’s investors.

Investors’ expectations were primed by the marketing of The DAO and active engagement between Slock.it and its co-founders with The DAO and DAO Token holders. To market The DAO and DAO Tokens, Slock.it created The DAO Website on which it published the White Paper explaining how a DAO Entity would work and describing their vision for a DAO Entity. Slock.it also created and maintained other online forums that it used to provide information to DAO Token holders about how to vote and perform other tasks related to their investment. Slock.it appears to have closely monitored these forums, answering questions from DAO Token holders about a variety of topics, including the future of The DAO, security concerns, ground rules for how The DAO would work, and the anticipated role of DAO Token holders. The creators of The DAO held themselves out to investors as experts in Ethereum, the blockchain protocol on which The DAO operated, and told investors that they had selected persons to serve as Curators based on their expertise and credentials. Additionally, Slock.it told investors that it expected to put forth the first substantive profit-making contract proposal—a blockchain venture in its area of expertise. Through their conduct and marketing materials, Slock.it and its co-founders led investors to believe that they could be relied on to provide the significant managerial efforts required to make The DAO a success.

Investors in The DAO reasonably expected Slock.it and its co-founders, and The DAO’s Curators, to provide significant managerial efforts after The DAO’s launch. The expertise of The DAO’s creators and Curators was critical in monitoring the operation of The DAO, safeguarding investor funds, and determining whether proposed contracts should be put for a

35 That the “projects” could encompass services and the creation of goods for use by DAO Token holders does not change the core analysis that investors purchased DAO Tokens with the expectation of earning profits from the efforts of others.

12 vote. Investors had little choice but to rely on their expertise. At the time of the offering, The DAO’s protocols had already been pre-determined by Slock.it and its co-founders, including the control that could be exercised by the Curators. Slock.it and its co-founders chose the Curators, whose function it was to: (1) vet Contractors; (2) determine whether and when to submit proposals for votes; (3) determine the order and frequency of proposals that were submitted for a vote; and (4) determine whether to halve the default quorum necessary for a successful vote on certain proposals. Thus, the Curators exercised significant control over the order and frequency of proposals, and could impose their own subjective criteria for whether the proposal should be whitelisted for a vote by DAO Token holders. DAO Token holders’ votes were limited to proposals whitelisted by the Curators, and, although any DAO Token holder could put forth a proposal, each proposal would follow the same protocol, which included vetting and control by the current Curators. While DAO Token holders could put forth proposals to replace a Curator, such proposals were subject to control by the current Curators, including whitelisting and approval of the new address to which the tokens would be directed for such a proposal. In essence, Curators had the power to determine whether a proposal to remove a Curator was put to a vote.36

And, Slock.it and its co-founders did, in fact, actively oversee The DAO. They monitored The DAO closely and addressed issues as they arose, proposing a moratorium on all proposals until vulnerabilities in The DAO’s code had been addressed and a security expert to monitor potential attacks on The DAO had been appointed. When the Attacker exploited a weakness in the code and removed investor funds, Slock.it and its co-founders stepped in to help resolve the situation.

b. DAO Token Holders’ Voting Rights Were Limited

Although DAO Token holders were afforded voting rights, these voting rights were limited. DAO Token holders were substantially reliant on the managerial efforts of Slock.it, its co-founders, and the Curators.37 Even if an investor’s efforts help to make an enterprise profitable, those efforts do not necessarily equate with a promoter’s significant managerial efforts or control over the enterprise. See, e.g., Glenn W. Turner, 474 F.2d at 482 (finding that a multi-level marketing scheme was an investment contract and that investors relied on the promoter’s managerial efforts, despite the fact that investors put forth the majority of the labor that made the enterprise profitable, because the promoter dictated the terms and controlled the scheme itself); Long v. Shultz, 881 F.2d 129, 137 (5th Cir. 1989) (“An investor may authorize the assumption of particular risks that would create the possibility of greater profits or losses but still depend on a third party for all of the essential managerial efforts without which the risk could not

36 DAO Token holders could put forth a proposal to split from The DAO, which would result in the creation of a new DAO Entity with a new Curator. Other DAO Token holders would be allowed to join the new DAO Entity as long as they voted yes to the original “split” proposal. Unlike all other contract proposals, a proposal to split did not require a deposit or a quorum, and it required a seven-day debating period instead of the minimum two-week debating period required for other proposals. 37 Because, as described above, DAO Token holders were incentivized either to vote yes or to abstain from voting, the results of DAO Token holder voting would not necessarily reflect the actual view of a majority of DAO Token holders.

13 pay off.”). See also generally SEC v. Merchant Capital, LLC, 483 F.3d 747 (11th Cir. 2007) (finding an investment contract even where voting rights were provided to purported general partners, noting that the voting process provided limited information for investors to make informed decisions, and the purported general partners lacked control over the information in the ballots).

The voting rights afforded DAO Token holders did not provide them with meaningful control over the enterprise, because (1) DAO Token holders’ ability to vote for contracts was a largely perfunctory one; and (2) DAO Token holders were widely dispersed and limited in their ability to communicate with one another.

First, as discussed above, DAO Token holders could only vote on proposals that had been cleared by the Curators.38 And that clearance process did not include any mechanism to provide DAO Token holders with sufficient information to permit them to make informed voting decisions. Indeed, based on the particular facts concerning The DAO and the few draft proposals discussed in online forums, there are indications that contract proposals would not have necessarily provide enough information for investors to make an informed voting decision, affording them less meaningful control. For example, the sample contract proposal attached to the White Paper included little information concerning the terms of the contract. Also, the Slock.it co-founders put forth a draft of their own contract proposal and, in response to questions and requests to negotiate the terms of the proposal (posted to a DAO forum), a Slock.it founder explained that the proposal was intentionally vague and that it was, in essence, a take it or leave it proposition not subject to negotiation or feedback. See, e.g., SEC v. Shields, 744 F.3d 633, 643-45 (10th Cir. 2014) (in assessing whether agreements were investment contracts, court looked to whether “the investors actually had the type of control reserved under the agreements to obtain access to information necessary to protect, manage, and control their investments at the time they purchased their interests.”).

Second, the pseudonymity and dispersion of the DAO Token holders made it difficult for them to join together to effect change or to exercise meaningful control. Investments in The DAO were made pseudonymously (such that the real-world identities of investors are not apparent), and there was great dispersion among those individuals and/or entities who were invested in The DAO and thousands of individuals and/or entities that traded DAO Tokens in the secondary market—an arrangement that bears little resemblance to that of a genuine general partnership. Cf. Williamson v. Tucker, 645 F.2d 404, 422-24 (5th Cir. 1981) (“[O]ne would not expect partnership interests sold to large numbers of the general public to provide any real partnership control; at some point there would be so many [limited] partners that a partnership vote would be more like a corporate vote, each partner’s role having been diluted to the level of a single shareholder in a corporation.”).39 Slock.it did create and maintain online forums on which

38 Because, in part, The DAO never commenced its business operations funding projects, this Report does not analyze the question whether anyone associated with The DAO was an “[i]nvestment adviser” under Section 202(a)(11) of the Investment Advisers Act of 1940 (“Advisers Act”). See 15 U.S.C. § 80b-2(a)(11). Those who would use virtual organizations should consider their obligations under the Advisers Act.

39 The Fifth Circuit in Williamson stated that:

14 investors could submit posts regarding contract proposals, which were not limited to use by DAO Token holders (anyone was permitted to post). However, DAO Token holders were pseudonymous, as were their posts to the forums. Those facts, combined with the sheer number of DAO Token holders, potentially made the forums of limited use if investors hoped to consolidate their votes into blocs powerful enough to assert actual control. This was later demonstrated through the fact that DAO Token holders were unable to effectively address the Attack without the assistance of Slock.it and others. The DAO Token holders’ pseudonymity and dispersion diluted their control over The DAO. See Merchant Capital, 483 F.3d at 758 (finding geographic dispersion of investors weighing against investor control).

These facts diminished the ability of DAO Token holders to exercise meaningful control over the enterprise through the voting process, rendering the voting rights of DAO Token holders akin to those of a corporate shareholder. Steinhardt Group, Inc. v. Citicorp., 126 F.3d 144, 152 (3d Cir. 1997) (“It must be emphasized that the assignment of nominal or limited responsibilities to the participant does not negate the existence of an investment contract; where the duties assigned are so narrowly circumscribed as to involve little real choice of action … a security may be found to exist … . [The] emphasis must be placed on economic reality.”) (citing SEC v. Koscot Interplanetary, Inc., 497 F.2d 473, 483 n. 14 (5th Cir. 1974)).

By contract and in reality, DAO Token holders relied on the significant managerial efforts provided by Slock.it and its co-founders, and The DAO’s Curators, as described above. Their efforts, not those of DAO Token holders, were the “undeniably significant” ones, essential to the overall success and profitability of any investment into The DAO. See Glenn W. Turner, 474 F.2d at 482.

C. Issuers Must Register Offers and Sales of Securities Unless a Valid Exemption Applies

The definition of “issuer” is broadly defined to include “every person who issues or proposes to issue any security” and “person” includes “any unincorporated organization.” 15 U.S.C. § 77b(a)(4). The term “issuer” is flexibly construed in the Section 5 context “as issuers devise new ways to issue their securities and the definition of a security itself expands.” Doran v. Petroleum Mgmt. Corp., 545 F.2d 893, 909 (5th Cir. 1977); accord SEC v. Murphy, 626 F.2d 633, 644 (9th Cir. 1980) (“[W]hen a person [or entity] organizes or sponsors the organization of

A general partnership or joint venture interest can be designated a security if the investor can establish, for example, that (1) an agreement among the parties leaves so little power in the hands of the partner or venture that the arrangement in fact distributes power as would a limited partnership; or (2) the partner or venturer is so inexperienced and unknowledgeable in business affairs that he is incapable of intelligently exercising his partnership or venture powers; or (3) the partner or venturer is so dependent on some unique entrepreneurial or managerial ability of the promoter or manager that he cannot replace the manager of the enterprise or otherwise exercise meaningful partnership or venture powers. Williamson, 645 F.2d at 424 & n.15 (court also noting that, “this is not to say that other factors could not also give rise to such a dependence on the promoter or manager that the exercise of partnership powers would be effectively precluded.”).

15 limited partnerships and is primarily responsible for the success or failure of the venture for which the partnership is formed, he will be considered an issuer … .”).

The DAO, an unincorporated organization, was an issuer of securities, and information about The DAO was “crucial” to the DAO Token holders’ investment decision. See Murphy, 626 F.2d at 643 (“Here there is no company issuing stock, but instead, a group of individuals investing funds in an enterprise for profit, and receiving in return an entitlement to a percentage of the proceeds of the enterprise.”) (citation omitted). The DAO was “responsible for the success or failure of the enterprise,” and accordingly was the entity about which the investors needed information material to their investment decision. Id. at 643-44.

During the Offering Period, The DAO offered and sold DAO Tokens in exchange for ETH through The DAO Website, which was publicly-accessible, including to individuals in the United States. During the Offering Period, The DAO sold approximately 1.15 billion DAO Tokens in exchange for a total of approximately 12 million ETH, which was valued in USD, at the time, at approximately $150 million. Because DAO Tokens were securities, The DAO was required to register the offer and sale of DAO Tokens, unless a valid exemption from such registration applied.

Moreover, those who participate in an unregistered offer and sale of securities not subject to a valid exemption are liable for violating Section 5. See, e.g., Murphy, 626 F.2d at 650-51 (“[T]hose who ha[ve] a necessary role in the transaction are held liable as participants.”) (citing SEC v. North Am. Research & Dev. Corp., 424 F.2d 63, 81 (2d Cir. 1970); SEC v. Culpepper, 270 F.2d 241, 247 (2d Cir. 1959); SEC v. International Chem. Dev. Corp., 469 F.2d 20, 28 (10th Cir. 1972); Pennaluna & Co. v. SEC, 410 F.2d 861, 864 n.1, 868 (9th Cir. 1969)); SEC v. Softpoint, Inc., 958 F. Supp 846, 859-60 (S.D.N.Y. 1997) (“The prohibitions of Section 5 … sweep[] broadly to encompass ‘any person’ who participates in the offer or sale of an unregistered, non-exempt security.”); SEC v. Chinese Consol. Benevolent Ass’n., 120 F.2d 738, 740-41 (2d Cir. 1941) (defendant violated Section 5(a) “because it engaged in selling unregistered securities” issued by a third party “when it solicited offers to buy the securities ‘for value’”).

D. A System that Meets the Definition of an Exchange Must Register as a National Securities Exchange or Operate Pursuant to an Exemption from Such Registration

Section 5 of the Exchange Act makes it unlawful for any broker, dealer, or exchange, directly or indirectly, to effect any transaction in a security, or to report any such transaction, in interstate commerce, unless the exchange is registered as a national securities exchange under Section 6 of the Exchange Act, or is exempted from such registration. See 15 U.S.C. §78e. Section 3(a)(1) of the Exchange Act defines an “exchange” as “any organization, association, or group of persons, whether incorporated or unincorporated, which constitutes, maintains, or provides a market place or facilities for bringing together purchasers and sellers of securities or for otherwise performing with respect to securities the functions commonly performed by a stock exchange as that term is generally understood … .” 15 U.S.C. § 78c(a)(1).

Exchange Act Rule 3b-16(a) provides a functional test to assess whether a trading system meets the definition of exchange under Section 3(a)(1). Under Exchange Act Rule 3b-16(a), an

16 organization, association, or group of persons shall be considered to constitute, maintain, or provide “a marketplace or facilities for bringing together purchasers and sellers of securities or for otherwise performing with respect to securities the functions commonly performed by a stock exchange,” if such organization, association, or group of persons: (1) brings together the orders for securities of multiple buyers and sellers; and (2) uses established, non-discretionary methods (whether by providing a trading facility or by setting rules) under which such orders interact with each other, and the buyers and sellers entering such orders agree to the terms of the trade.40

A system that meets the criteria of Rule 3b-16(a), and is not excluded under Rule 3b- 16(b), must register as a national securities exchange pursuant to Sections 5 and 6 of the Exchange Act41 or operate pursuant to an appropriate exemption. One frequently used exemption is for alternative trading systems (“ATS”).42 Rule 3a1-1(a)(2) exempts from the definition of “exchange” under Section 3(a)(1) an ATS that complies with Regulation ATS,43 which includes, among other things, the requirement to register as a broker-dealer and file a Form ATS with the Commission to provide notice of the ATS’s operations. Therefore, an ATS that operates pursuant to the Rule 3a1-1(a)(2) exemption and complies with Regulation ATS would not be subject to the registration requirement of Section 5 of the Exchange Act.

The Platforms that traded DAO Tokens appear to have satisfied the criteria of Rule 3b- 16(a) and do not appear to have been excluded from Rule 3b-16(b). As described above, the Platforms provided users with an electronic system that matched orders from multiple parties to buy and sell DAO Tokens for execution based on non-discretionary methods.

IV. Conclusion and References for Additional Guidance

Whether or not a particular transaction involves the offer and sale of a security— regardless of the terminology used—will depend on the facts and circumstances, including the

40 See 17 C.F.R. § 240.3b-16(a). The Commission adopted Rule 3b-16(b) to exclude explicitly certain systems that the Commission believed did not meet the exchange definition. These systems include systems that merely route orders to other execution facilities and systems that allow persons to enter orders for execution against the bids and offers of a single dealer system. See Securities Exchange Act Rel. No. 40760 (Dec. 8, 1998), 63 FR 70844 (Dec. 22, 1998) (Regulation of Exchanges and Alternative Trading Systems) (“Regulation ATS”), 70852. 41 15 U.S.C. § 78e. A “national securities exchange” is an exchange registered as such under Section 6 of the Exchange Act. 15 U.S.C. § 78f. 42 Rule 300(a) of Regulation ATS promulgated under the Exchange Act provides that an ATS is: any organization, association, person, group of persons, or system: (1) [t]hat constitutes, maintains, or provides a market place or facilities for bringing together purchasers and sellers of securities or for otherwise performing with respect to securities the functions commonly performed by a stock exchange within the meaning of [Exchange Act Rule 3b-16]; and (2) [t]hat does not: (i) [s]et rules governing the conduct of subscribers other than the conduct of subscribers’ trading on such [ATS]; or (ii) [d]iscipline subscribers other than by exclusion from trading. Regulation ATS, supra note 40, Rule 300(a). 43 See 17 C.F.R. § 240.3a1-1(a)(2). Rule 3a1-1 also provides two other exemptions from the definition of “exchange” for any ATS operated by a national securities association, and any ATS not required to comply with Regulation ATS pursuant to Rule 301(a) of Regulation ATS. See 17 C.F.R. §§ 240.3a1-1(a)(1) and (3).

17 economic realities of the transaction. Those who offer and sell securities in the United States must comply with the federal securities laws, including the requirement to register with the Commission or to qualify for an exemption from the registration requirements of the federal securities laws. The registration requirements are designed to provide investors with procedural protections and material information necessary to make informed investment decisions. These requirements apply to those who offer and sell securities in the United States, regardless whether the issuing entity is a traditional company or a decentralized autonomous organization, regardless whether those securities are purchased using U.S. dollars or virtual currencies, and regardless whether they are distributed in certificated form or through distributed ledger technology. In addition, any entity or person engaging in the activities of an exchange, such as bringing together the orders for securities of multiple buyers and sellers using established non- discretionary methods under which such orders interact with each other and buyers and sellers entering such orders agree upon the terms of the trade, must register as a national securities exchange or operate pursuant to an exemption from such registration.

To learn more about registration requirements under the Securities Act, please visit the Commission’s website here. To learn more about the Commission’s registration requirements for investment companies, please visit the Commission’s website here. To learn more about the Commission’s registration requirements for national securities exchanges, please visit the Commission’s website here. To learn more about alternative trading systems, please see the Regulation ATS adopting release here.

For additional guidance, please see the following Commission enforcement actions involving virtual currencies:

• SEC v. Trendon T. Shavers and Bitcoin Savings and Trust, Civil Action No. 4:13- CV-416 (E.D. Tex., complaint filed July 23, 2013)

• In re Erik T. Voorhees, Rel. No. 33-9592 (June 3, 2014)

• In re BTC Trading, Corp. and Ethan Burnside, Rel. No. 33-9685 (Dec. 8, 2014)

• SEC v. Homero Joshua Garza, Gaw Miners, LLC, and ZenMiner, LLC (d/b/a Zen Cloud), Civil Action No. 3:15-CV-01760 (D. Conn., complaint filed Dec. 1, 2015)

• In re Bitcoin Investment Trust and SecondMarket, Inc., Rel. No. 34-78282 (July 11, 2016)

• In re Sunshine Capital, Inc., File No. 500-1 (Apr. 11, 2017)

And please see the following investor alerts:

• Bitcoin and Other Virtual Currency-Related Investments (May 7, 2014)

• Ponzi Schemes Using Virtual Currencies (July 2013)

By the Commission.

18 WISE CONTRACTS: SMART CONTRACTS THAT WORK FOR PEOPLE AND MACHINES

James Hazard / Helena Haapio

Founder, CommonAccord 40 Rue Lauriston, 75116 Paris, FR [email protected]; http://www.CommonAccord.org Associate Professor of Business Law, University of Vaasa/International Contract Counsel, Lexpert Ltd Pohjoisranta 20, 00170 Helsinki, FI [email protected]; http://www.lexpert.com Keywords: Automation, codification, open source, prose objects, Ricardian contracts, smart contracts, smart contract templates, visualization Abstract: Modern economies are held together by innumerable contracts. However, current contracts are neither machine-readable nor easily human-readable. The Ricardian Contract paradigm of parameters, prose and code posits a hybrid model of automation and conventional legal text. This paper connects recent work on design criteria for «Smart Contract Templates» with prose objects and prototype inheritance demonstrated at CommonAccord.org. Templates authored and shared as prose objects can become the basis for automation, codification, commentary, big data analysis and graphic presentations.

1. Introduction1 Modern economies are held together by innumerable contracts, as recognized by the 2016 Nobel Prize in Economics.2 Contracts are, however, difficult to understand and manage,3 and inherently incomplete.4 This paper argues that the problems of understanding, management and incompleteness can be greatly reduced by codification using the methods of open source collaboration, combining the benefits of «code is law»5 with codified law and contract visualization, leading to what we have chosen to call wise contracts: smart contracts6 that use and extend the wisdom of legal and other experts, iteratively learn from experience, and, echoing our title, work for people and machines. The «Ricardian Contract» paradigm posits three parts of contracts necessary for full automation and legal enforceability – parameters, code and prose.7 Parameters are the aspects that are specific to the particular

1 The authors wish to thank Christopher Clack and his co-authors for their valuable comments on an earlier version of this manuscript. Any errors are our own. 2 The Prize in Economic Sciences 2016. 3 See, e.g., IACCM 2015. 4 The theory of incomplete contracts has been pioneered by Oliver Hart and his collaborators. See, e.g., H & M 1988. The Nobel Prize in Economics 2016 was awarded to Oliver Hart and Bengt Holmström for their contribution to contract theory, including incomplete contracts. 5 See, generally, L 1999 and 2000. See also D F/H 2016. 6 We reference the work and vocabulary as developed by C  . 2016(a) and 2016(b). We argue – as those authors do – that it is important to ensure that the smart contract is also a legally enforceable contract, a smart legal contract. The authors define the term «smart contract» as an agreement whose execution is both automatable and enforceable (C  . 2016(a)), i.e., to include both smart legal contracts and smart contract code. Our use of «wise contracts» is intended to refer to the addition of «wisdom» about contracts’ business and legal objectives and how they can be reached. The term «wise contract» has a variety of other usages, including an application written to improve coordination among smart contracts (S 2017) and arbitration services relating to smart contracts (http://www.wisecontracts.com/). 7 Ricardian Contracts is a concept developed by Ian Grigg [G n.d.].

Electronic copy available at: https://ssrn.com/abstract=2925871 2

contract, for instance deal points such as prices, dates and quantities. A deal point is a fluid notion since any aspect of a contract can become a critical negotiation issue in a particular transaction, but the point is that any aspect of a contract can fit into at least one of these three categories. Smart contracts fulfil the code part and are the subject of a strong movement including Hyperledger8, Corda9, Ethereum10 and variants such as Interledger.11 The prose part, however, has, until now, not been handled efficiently. A number of approaches have been developed, many of which can be classified as document assembly. A recent paper in two parts on «Smart Contract Templates» by C, B and B (the «SCT Paper»)12 provides an excellent overview of the issues relating to the codification of prose. We extend the SCT Paper by providing some suggested solutions to the issues. By handling the prose of legal contracts using the same infrastructure and methods that are used for software code, it is possible to rapidly and universally codify contract prose.13 CommonAccord14 demonstrates a simple data model for codified prose that allows easy migration of conventional contracts to standards-based prose objects ready for automation via smart contracts. Codified prose also supports the full set of legal and social methods such as setting standards, commenting and rating.15 The codification can begin with a form proposed by a party, with a «standard» form or with modular materials from analytical or document assembly systems.16 The prose objects can optionally integrate presentation and visual elements, supporting the emerging demands for truly human-readable contracts.17 In recent years, in response to the growing complexity of contracts, new approaches such as simplification, visualization and user-centered design have been introduced, even to the world of commercial contracting.18 As uses accumulate, visualization can also provide guidance and feedback on uses.19 The combination of code, codified prose, visual presentation and big data promises a revolution in how contracts are made, managed, and presented. 2. Codifying Prose Picking up the conversation where the second part of the SCT Paper [C  . 2016(b)] begins, there are five broad requirements for smart contract templates. We pair each requirement with a short word that evokes the idea: 1. Editing: Methods to create and edit smart legal agreements, including contract prose and parameters. 2. Transmission: Standard formats for storage, retrieval and transmission of smart legal contracts. 3. Stamping20: Protocols for legally executing smart legal agreements (with or without signatures). 4. Binding: Methods to bind the parameters or deal points of a contract and its corresponding smart contract code to create a smart legal contract, i.e., a legally-enforceable smart contract.

8 https://www.hyperledger.org (all Internet sources accessed on 9 January 2017). 9 https://www.corda.net. 10 https://ethereum.org. 11 https://interledger.org. See also C  . 2016(a). 12 C  . 2016(a) and (b). The discussion that follows is mostly based on the latter part, C  . 2016(b). 13 The set of tools that we reference are very well known among software coders. They principally include plain text, HTML, key/values, file systems, git, and editing IDEs. 14 http://www.commonaccord.org/. 15 Standardization of terms is a long-standing and widely-practiced activity. 16 Analytical systems such as RAVN (https://www.ravn.co.uk), Seal Software (https://www.seal-software.com/), and KM Standards (https://kmstandards.com) generate modular materials from groups of conventional contracts. These modules can be formatted as prose objects. 17 See, e.g., H  . 2017, H 2013 and 2014. 18 See, e.g., P 2015, P  . 2016, W  . 2016, H/B 2017. 19 Systems such as RAVN (https://www.ravn.co.uk) have demonstrated the ability to graphically present aggregate information about groups of contracts. 20 «Stamping» is our term, the SCT Paper does not provide a one-word label for this principle.

Electronic copy available at: https://ssrn.com/abstract=2925871 3

5. Enforceability21: Methods to make smart legal contracts available in forms acceptable according to laws and regulations in the appropriate jurisdiction.

The SCT Paper carefully elaborates issues regarding these requirements. In the following, we suggest that there is a unified approach to achieving these requirements, based on tools and methods already well-established in software development. 2.1. Abstract Specification of a Prose Object Model The key to templating is what the authors of the SCT Paper refer to as an «abstract specification» for legal templates.22 Such a system would ideally be expressible in a number of «concrete» formats, such as JSON, XML, markdown, etc.23 CommonAccord concretely demonstrates such an «abstract» specification that is simple, extensible and unifying. Technically, the model can be described as records consisting of key/values, with links from one record to another that permit inheritance of other key/values based on «prototype» inheritance.24 This is a technical mouthful. – Operationally, it means that legal templates can be reduced to their constituent parts and assembled into desired forms very simply, as building blocks. The SCT Paper discusses various design options for storing the parameters – should they be in separate records, with the code or with the prose?25 We suggest that they will ordinarily be best presented as separate records – term sheets for transactions – but that they can also be stored as part of the prose or the code, and that different uses will call for a mix of these approaches.26 For instance, the prose forms can include default parameters or leave the parameters blank. In either case, an author of a contract can override it with a new statement of the parameter. Similarly, prose objects can reference or include code and vice-versa.27 In negotiation, a party can propose changes to an existing prose form by listing the proposed changes. This derivative record can become «the» contract. In practice, key/values that represent parameters, prose or code can all be expressed where it is most convenient. The abstract specification of key/values and prototype inheritance permits the development of both prose and code «objects» and «classes» that allow highly structured relationships and analysis. By being open-ended (the «prototype» part of inheritance), this model allows anyone – coders, non-coders, lawyers, non-lawyers, including the parties themselves – to rapidly add a preferred form or to adapt an existing one. 2.2. Editing Tools Returning to the SCT Paper’s principles, editing can be done with a variety of tools. In a practical system of transacting, most editing will consist of order-entry: filling in parameters or overriding specific spans of prose.

21 «Enforceability» is our term, the SCT Paper does not provide a one-word label for this principle, which could also be called «Legit- imacy» or «Localization». 22 C  . 2016(b), p. 3. 23 Id., p. 2. 24 On prototype inheritance generally, see https://en.wikipedia.org/wiki/Prototype-based_programming. The CommonAccord variant is described most succinctly at https://github.com/CommonAccord/Cmacc-Org/issues/18. Code that precisely implements the abstract model in a concrete form was done by Primavera De Filippi (Harvard Berkman-Klein, and French CNRS) and is available at https://github.com/CommonAccord/Cmacc-Org/tree/master/vendor/library. 25 C  . 2016(b), p. 7. 26 E.g., parameters that complete a prose object – a YCombinator form of investment note. http://source.commonaccord.org/index. php?action=source&file=F/Demo/Note_YC/Cap_Discount.md. The source is available at https://github.com/CommonAccord/ Cmacc-Source/blob/master/Doc/F/Demo/Note_YC/Cap_Discount.md. 27 E.g., a form of bank check that incorporates both the prose elements and quasi-code via hash links http://www.commonaccord.org/ index.php?action=doc&file=bqc/fr/bnpp/a5we/Account/Check/00001/06-Accept.md. Linking to code via hashes may facilitate the sharing of specific functions among actors. For instance, in the context of the European Payment Services Directive (Directive (EU) 2015/2366), banks will be required to expose payment APIs. They could collaborate on discrete, standardized functions used via hashed names. 4

This can be done in transaction systems, such as electronic payment systems and web interfaces. That does not preclude interfaces such as those mentioned by the authors of the SCT Paper, including MS Word and document assembly systems. For management of prose objects and extensive editing, we expect that the tools of software developers, such as IDEs,28 will be preferred. That is what the current authors of CommonAccord use, including Emacs, Visual Studio and Yarn. 2.3. Presentation and Markup After having been drafted mainly by lawyers for lawyers for years, contracts are now starting to communicate in new ways to new audiences.29 A visual turn has taken place in many contexts, and contracts have not remained untouched: contracts, too, are shifting from text-only contracts (which may or may not contain elements of document design adding clarity) to visualized contracts: contracts with embedded images seeking to supplement text and enhance contract readability and usability. In the next few years, prose objects and guided interviews may become the easiest way to generate contracts, whether text-only contracts, visualized contracts, smart or intelligent contracts, or hybrids of these. The following image, adapted from the work of H, P and  R,30 shows contracts along the continuum of the ease (or difficulty) of human / machine readability. Research and practice tell us that many people find contract text intimidating and barely human-readable. Smart Contract Templates can provide a graphical user interface to text-only contracts as well as to smart and other code-based contracts, thereby helping the preparation of truly human-readable contracts.

Figure 1. Ease of Human/Computer Readability: Visual-Text-Code Continuum31

Smart Contract Templates can also easily provide alternative displays and approaches such as layering.32 This means presenting information so that it can be read first at a summary level that gives an overall understanding, with additional information available if needed.33 Take the example of Creative Commons licenses.34 They rely on a three-layer design: first, there are simple, recognizable icons that can be clicked on to reveal a plain- language version of the relevant text. If additional information is required, the full text is available just one click away. The structure includes the so-called Legal Code layer (the «lawyer-readable» version, the full license), the Commons Deed (the «human readable» version summarizing the most important terms), and then a «machine readable» version: a summary of the key terms written into a format that software systems, search engines, and other kinds of technology can understand.35 Returning to the issues posed in the SCT Paper, the common convention for presentation elements should, we think, be HTML. HTML is the nearly universal text and graphics language of the web; it is widely understood

28 An IDE is a tool that developers use for doing their work. It can be compared to word processing and document management for legal work. There are many highly developed IDEs, many of them open source. They are very good at handling a large number of files at the same time, which is normally the case when using codified prose. See, generally, https://en.wikipedia.org/wiki/ Integrated_development_environment. 29 H  . 2017. 30 Id. 31 Id. Image used with the kind permission by the co-authors, Daniela Alina Plewe and Robert de Rooy. 32 See, e.g., W  . 2016. 33 See, e.g., H 2014 and W  . 2016. 34 See C C, http://creativecommons.org/licenses. 35 «Taken together, these three layers of licenses ensure that the spectrum of rights isn’t just a legal concept. It’s something that the creators of works can understand, their users can understand, and even the Web itself can understand.» See C C. 5

among developers and designers and subject to standards processes.36 HTML is fully capable of expressing legal documents and has a large set of more advanced graphics and presentation features. The inputs, for instance a list of choices, or a summary of the business terms, can be presented with graphic accompaniment and framing. The output – a full-text agreement – or list of transactions, or next steps – can also be presented with embedded icons and expressive formatting. A preference for HTML does not exclude markdown languages, but HTML is a common denominator.37 2.4. Transmission Transmission of smart contracts will be done in a variety of methods. Blockchains, including Bitcoin38, Ethere- um and Hyperledger, have attracted attention and development efforts for their fraud-reduction aspects. Corda has been used in connection with the SCT Paper work. Interledger is another open standard. Current systems of payment also provide secure pathways for transmission of parameters and other key/values. We note that git, the cryptographically-supported version control system developed by the Linux community, provides a medium of transmission that is very useful for collections of materials and particularly for the «legal» part of legal codification.39 2.5. Stamping and Signing Stamping is intended to refer to signature and its equivalents. Signature can be done by conventional methods, including by signing a full text or even a hash of the full text. It is, however, much more efficient and reliable to use the cryptographically-assured methods of Blockchains and payment systems. In these situations, prose objects depend on the code platform for signature. 2.6. Binding Binding refers to connecting the parameters with the smart contract’s prose and code. In a system based on templates, it will generally be possible for parties to adopt only the record that states the parameters, with a reference to the hash of the supporting prose and code. This is in fact very similar to the way that credit card transactions and many other forms of transacting are documented. They are a short statement of parameters that are understood in the context of a system of automation (code) and formal agreements (prose). There is, however, a difference in that a Ricardian model allows rapid iteration and generalization of the system. The record of the transaction will reference the object or objects that support it. If that reference is made using a hash of the referenced record (and all the links in the supporting object are also based on hashes) then there is a one-way inclusion of the full context. This permits rapid development and evolution of the context. It can also be privacy enhancing in case of a security breach; the record itself is reduced to merely the essentials and an opaque hash, while the full context can be proved by the parties, who each have a copy. 2.7. Ontologies, Enforceability and Localization – an Object Model of the Legal World Ontologies are the essence of a templating system. In computer science, an «ontology» refers to the formally defined concepts and relationships that describe a domain. They include such things as classes, attributes, relationships and rules.40 In law, these can be thought of as naming conventions and classifications. The inventory of «things» in a legal conception of the world is of course enormous, as law touches on nearly everything that is important to people. However, by focusing on «documents» as the expression of legal matters, it is possible to make a robust, extensible templating system from only a few «classes» of things. For

36 https://en.wikipedia.org/wiki/HTML. 37 Markdown refers to such syntaxes as those used in Wikipedia and on GitHub, https://en.wikipedia.org/wiki/Markdown. 38 See, e.g., https://en.wikipedia.org/wiki/Bitcoin. 39 Git was originated by Linus Torvalds and developed by the community. https://git-scm.com/. 40 For ontology as a computer science term, see, e.g., https://en.wikipedia.org/wiki/Ontology_(information_science). 6

contracting, the central class is contract agreements. To allow for the fact that contracts are written in different languages and under different laws and customs, we posit a core «contract agreement» object. It has only a few attributes – an abstract header, identification of parties, signature and the possibility of annexes, for example.41 This bare object can be extended by cladding it in text for a variety of jurisdictions and languages. The contract core can be configured for any number of parties. The provisions are organized in sections and subsections, which provide a ready-made taxonomy and structure, familiar to many parties and their counsel. Sections and subsections are composed of sentences, which consist of clauses, and may have dates, prices, quantities, maximums and other deal points. In addition to the provisions themselves, the defined terms may be parameterized, as may cross-references. By parameterizing all of these elements as key/values and orga- nizing them into records, it is possible to be extremely systematic in document organization and text reuse, while still allowing full flexibility to the parties.42 Legal codes, like good software code, tend to state each matter once and reference it rather than restate or rework it when needed again. Fixed formulations allow the aggregation of knowledge, including precedents. There are a few additional document-related classes in contracts. These may include subdocuments such as Statements of Work or Exhibits. These become part of contract agreements, but may also be independent documents. In the other direction, groups of documents may be necessary for a single operation – for instance a closing binder of documents for an acquisition in some jurisdictions. In those situations, a single set of parameters (deal points) informs the group of documents. These parameters resemble a term sheet or summary page of a closing binder. Of course, documents are merely one part of the picture. Legal documents connect and increment the relationships of the parties. They often reference properties and places. They are subject to jurisdictions. As with documents, there can be a core object for «persons.» This includes the notion of name, address, applicable pronouns and the like. Persons can be extended for natural persons (humans) and their varieties, including female and male, juvenile or adult, and for legal persons, in their vast variety. Each of these of course can be expressed in the range of languages, and jurisdictions. The same is true for places, where, for instance, a particular street address depends on the street, which is associated with one or more municipalities, counties, states, provinces, departments, etc., and nations and supra-national groupings.43 Properties are similar – a vehicle or patent right has identifying features, may be registered under a jurisdiction, etc. This ontology of prose objects can model the legal world, as expressed in legal documents. In a global economy, contracts frequently cross boundaries between different legal systems. Even the key legal elements necessary to create a contract vary. A critical part of the object model is localization for the jurisdiction. The contract’s choice of law will influence its substance, style and language. In the CommonAccord demonstration materials, jurisdiction has been chosen as the basis to organize contracts and other documents.44 2.8. Incremental Codification Prose objects can be easily and directly adapted from current document practice by the broad community of contracts and legal experts and practitioners. They provide a platform for conventional legal codification, and can advance at the speed of software development. They can be driven by first-movers and go viral, they do not depend on committees to bring everyone to agreement on everything. Codification can be extremely granular

41 http://source.commonaccord.org/index.php?action=doc&file=F/00/Agt/Base/Outline/0.md. 42 For instance, this presents an attempt to organize a complete system of legal documents for a variety of jurisdictions, based on a common core. http://source.commonaccord.org/index.php?action=list&file=F/Demo/. 43 A demonstration object model for geographic locations – http://source.commonaccord.org/index.php?action=list&file=U/at/. 44 http://source.commonaccord.org/index.php?action=list&file=F/Demo/. 7

– issue by issue, phrase by phrase – and multi-threaded – various solutions can be developed and adopted simultaneously. This is the dynamic by which open source software has come to codify most of computing. 2.9. Intelligence – Expert, Artificial and Natural The system of prose objects is not «intelligent.» Prose objects are static; they do not reason; they are nouns, not verbs. But these unintelligent prose objects provide anchors for many forms of intelligence. First is human intelligence, such as commercial or legal expertise. Prose objects are consistent with conventional codification efforts, model document projects, commentaries, and trade group efforts. The prose objects also fit with software code in the Ricardian paradigm, so coders can use smart contracts to automate interactions, without having to automate everything about a contract. Since the great majority of contract interactions seen from a legal point of view fall into definable patterns, most of contract interactions can be automated with code, while relying on the legal system to deal with the unusual, unexpected events that reflect, for example, the incompleteness of contracts. This is how most automated systems work, and the model can be generalized in the Ricardian paradigm.45 With respect to AI and big data intelligence, the prose objects provide structured expressions of the relationships. The patterns in contracting behaviour can be deduced from the relationships among the prose objects, their frequency and variations. By analyzing this data, some intelligent systems will come to offer the equivalent of self-driving bureaucracies. They will identify the pathways to achieving the goals of constituents, the costs and tradeoffs. This is already part of the goals of many AI systems. Extensive use of prose objects may allow the reasoning to be more easily understood and controlled by humans. 3. Conclusion This paper illustrates how prose objects can serve as the connection between automated systems and human systems. They can provide anchors for a number of forms of explanation and clarification, including layering, graphic representations, layout, style sheets, voice recognition, ratings, commentary and the like – all depending on the needs and expectations of the audience. The vision combines conventional contract drafting processes, web development and business process automation, transforming contracts into codified text and images, appropriate for the needs of different audiences. The goal is a public, open source collaboration for codified contracts that both people and machines can easily understand, improve, and act upon. 4. References C, C D./B, V A./B, L, Smart Contract Templates: foundations, design landscape and research directions. Version v2, 3 August 2016(a). https://arxiv.org/abs/1608.00771. C, C D./B, V A./B, L, Smart Contract Templates: essential requirements and design options. Version v2, 15 December 2016(b). https://arxiv.org/abs/1612.04496. C C, About The Licenses – Creative Commons, http://creativecommons.org/licenses. D F, P/H, S, Blockchain technology as a regulatory technology: From code is law to law is code, First Monday Volume 21, Number 12, 5 December 2016, http://firstmonday.org/ojs/index.php/fm/article/view/7113. G, I, The Ricardian Contract, no date, http://iang.org/papers/ricardian_contract.html. H, H, Designing Readable Contracts: Goodbye to Legal Writing – Welcome to Information Design and Visua- lization. In: Schweighofer, Erich/Kummer, Franz/Hötzendorfer, Walter (Eds.), Abstraction and Application. Proceedings

45 Merchant websites are largely automated, but have terms of use and complaint procedures. Stockmarkets are similarly configured. The system works well most of the time and occasionally a problem arises that is dealt with in conference rooms and courts. The parties learn and incrementally so does the system. The benefit of an open source, generalized approach, such as is offered by smart contracts and by prose objects, is that the learning can be widely and symmetrically shared. 8

of the 16th International Legal Informatics Symposium IRIS 2013, Österreichische Computer Gesellschaft OCG, Wien 2013, p. 445–452. H, H, Lawyers as Designers, Engineers and Innovators: Better Legal Documents through Information Design and Visualization. In: Schweighofer, Erich/Kummer, Franz/Hötzendorfer, Walter (Eds.), Transparency. Proceedings of the 17th International Legal Informatics Symposium IRIS 2014, Österreichische Computer Gesellschaft OCG, Wien 2014, p. 451–458. H, H/B, T D., Business-Friendly Contracting: How Simplification and Visualization Can Help Bring It to Practice. In: Jacob, Kai/Schindler, Dierk/Strathausen, Roger (Eds.), Liquid Legal – Transforming Legal into a Business Savvy, Information Enabled and Performance Driven Industry, Springer International Publishing 2017, p. 371– 396. DOI: 10.1007/978-3-319-45868-7_24. H, H/P, D A/ R, R, Contract Continuum: From Text to Images, Comics and Code. In: Proceedings of IRIS 2017. H, O/M, J, Incomplete Contracts and Renegotiation, Econometrica, Vol. 56, No. 4, 1988, p. 755–785. IACCM, Commercial Excellence: Ten Pitfalls To Avoid In Contracting. [Booklet] International Association for Contract and Commercial Management 2015, https://www2.iaccm.com/resources/?id=8451. L, L, Code and Other Laws of Cyberspace, Basic Books, Inc., New York, NY, 1999. L, L, Code Is Law: On Liberty in Cyberspace, Harvard Magazine, 1 January 2000, http://harvardmagazine.com/2000/01/code-is-law-html. P, S, Beyond the Wall of Text: How Information Design Can Make Contracts User-Friendly. In: Marcus, Aaron (Ed.), Design, User Experience, and Usability: Users and Interactions, Springer International Publishing 2015, p. 341–352. DOI: 10.1007/978-3-319-20898-5_33. P, S/S, A/L, M, Exploring contract visualization: Clarification and framing strategies to shape collaborative business relationships, Journal of Strategic Contracting and Negotiation, Vol. 2, Issue 1–2, March/June 2016, p. 69–100. DOI: 10.1177/2055563616669739. The Prize in Economic Sciences 2016. Nobelprize.org. Nobel Media AB 2014. http://www.nobelprize.org/nobel_prizes/ economic-sciences/laureates/2016/. S, P, Upgrading «Smart Contracts» to «Wise Contracts», 15 January 2017, http://bravenewcoin.com/news/ upgrading-smart-contracts-to-wise-contracts/. W, R/W, J/H, H/C, G/M, S, Cooperation Through Clarity: De- signing Simplified Contracts, Journal of Strategic Contracting and Negotiation, Vol. 2, Issue 1–2, March/June 2016, p. 48– 68. DOI: 10.1177/2055563616668893. First Monday, Volume 2, Number 9 - 1 September 1997

Read related articles on Internet economics and Security

Abstract Smart contracts combine protocols with user interfaces to formalize and secure relationships over computer networks. Objectives and principles for the design of these systems are derived from legal principles, economic theory, and theories of reliable and secure protocols. Similarities and differences between smart contracts and traditional business procedures based on written contracts, controls, and static forms are discussed. By using cryptographic and other security mechanisms, we can secure many algorithmically specifiable relationships from breach by principals, and from eavesdropping or malicious interference by third parties, up to considerations of time, user interface, and completeness of the algorithmic specification. This article discusses protocols with application in important contracting areas, including credit, content rights management, payment systems, and contracts with bearer.

Contents Introduction Contracts Em bedded in the World Contemporary Practice Accounting Controls Electronic Data Interchange Automata as Authority Dimensions of Contract Design Mental and Computational Tr ansaction Costs The Economics Of Security Proactive vs. Reactive Security Online Enforceability Observability by Principals Verifiability by Adjudicators Privity: Protection from Third Parties Contracting Phases Trading off Contract Design Objectives Auditing Intermediaries Building Blocks of Smart Contract Protocols Protocols Attacks against Smart Contracts Public and Secret Key Cryptography Mutually Confidential Computation Privy Authentication Post-unforgeable Transaction Logs Mixes Quora Protection of Keys Capabilities Contracts with Bearer Bearer Certificates Unlinkable Transfer Conserved Objects Digital Cash Credentials Content Rights Management Watermarks Controlled CPUs Reputation Systems Credit Sec ured Credit Ripped Instruments Credit Cards Interval Instruments Known Borrowers of Unknown Amounts Pseudonymous Credit Ratings Conclusion

Introduction

The contract, a set of promises agreed to in a "meeting of the minds", is the traditional way to formalize a relationship. The contract is the basic building block of a market economy. Over many centuries of cultural evolution has emerged both the concept of contract and principles related to it, encoded into common law. Such evolved structures are often prohibitively costly to rederive. If we started from scratch, using reason and experience, it could take many centuries to redevelop sophisticated ideas like contract law and property rights that make the modern market work. But the digital revolution challenges us to develop new institutions in a much shorter period of time. By extracting from our current laws, procedures, and theories those principles which remain applicable in cyberspace, we can retain much of this deep tradition, and greatly shorten the time needed to develop useful digital institutions.

Computers make possible the running of algorithms heretofore prohibitively costly, and networks the quicker transmission of larger and more sophisticated messages. Furthermore, computer scientists and cryptographers have recently discovered many new and quite interesting algorithms. Combining these messages and algorithms makes possible a wide variety of new protocols. These protocols, running on public networks such as the Internet, both challenge and enable us to formalize and secure new kinds of relationships in this new environment, just as contract law, business forms, and accounting controls have long formalized and secured business relationships in the paper-based world.

In electronic commerce so far, the design criteria important for automating contract execution have come from disparate fields like economics and cryptography, with little cross-communication: little awareness of the technology on the one hand, and little awareness of its best business uses other. These efforts are striving after common objectives, and converge on the concept of smart contracts [ 1 ].

Smart contracts reduce mental and computational transaction costs imposed by either principals, third parties, or their tools. The contractual phases of search, negotiation, commitment, performance, and adjudication constitute the realm of smart contracts. This article covers all phases, with an emphasis on performance. Smart contracts utilize protocols and user interfaces to facilitate all steps of the contracting process. This gives us new ways to formalize and secure digital relationships which are far more functional than their inanimate paper-based ancestors.

Contracts Embedded in the World

The basic idea behind smart contracts is that many kinds of contractual clauses (such as collateral, bonding, delineation of property rights, etc.) can be embedded in the hardware and software we deal with, in such a way as to make breach of contract expensive (if desired, sometimes prohibitively so) for the breacher. A canonical real-life example, which we might consider to be the primitive ancestor of smart contracts, is the humble vending machine. Within a limited amount of potential loss (the amount in the till should be less than the cost of breaching the mechanism), the machine takes in coins, and via a simple mechanism, which makes a freshman computer science problem in design with finite automata, dispense change and product according to the displayed price. The vending machine is a contract with bearer: anybody with coins can participate in an exchange with the vendor. The lockbox and other security mechanisms protect the stored coins and contents from attackers, sufficiently to allow profitable deployment of vending machines in a wide variety of areas.

Smart contracts go beyond the vending machine in proposing to embed contracts in all sorts of property that is valuable and controlled by digital means. Smart contracts reference that property in a dynamic, often proactively enforced form, and provide much better observation and verification where proactive measures must fall short.

As another example, consider a hypothetical digital security system for automobiles. The smart contract design strategy suggests that we successively refine security protocols to more fully embed in a property the contractual terms which deal with it. These protocols would give control of the cryptographic keys for operating the property to the person who rightfully owns that property, based on the terms of the contract. In the most straightforward implementation, the car can be rendered inoperable unless the proper challenge- response protocol is completed with its rightful owner, preventing theft. But if the car is being used to secure credit, strong security implemented in this traditional way would create a headache for the creditor - the repo man would no longer be able to confiscate a deadbeat's car. To redress this problem, we can create a smart lien protocol: if the owner fails to make payments, the smart contract invokes the lien protocol, which returns control of the car keys to the bank. This protocol might be much cheaper and more effective than a repo man. A further reification would provably remove the lien when the loan has been paid off, as well as account for hardship and operational exceptions. For example, it would be rude to revoke operation of the car while it's doing 75 down the freeway.

In this process of successive refinement we've gone from a crude security system to a reified contract:

(1) A lock to selectively let in the owner and

exlude third parties;

(2) A back door to let in the creditor;

(3a) Creditor back door switched on only upon nonpayment

for a certain period of time; and

(3b) The final electronic payment permanently switches

off the back door.

Mature security systems will be undertaking different behavior for different contracts. To continue with our example, if the automobile contract were a lease, the final payment would switch off leasee access; for purchase on credit, it would switch off creditor access. A security system, by successive redesign, increasingly approaches the logic of the contract which governs the rights and obligations covering the object, information, or computation being secured. Qualitatively different contractual terms, as well as technological differences in the property, give rise to the need for different protocols.

Contemporary Practice

Accounting Controls Outside of the financial cryptography community, and long predating it, there is a deep tradition of protocols used in the course of performing contracts. These protocols consist of a flow of forms ("data flow", canonically displayed in data flow diagrams), along with checks and procedures called "controls". Controls serve many of the same functions as cryptographic protocols: integrity, authorization, and so on. This article uses "control protocols" or simply "controls" to refer to this combination of data flow and controls.

Control protocols, and the professions of auditing and accounting [ 2 ] based on them, play a critical but ill- analyzed role in our economy. Economists lump them, along with other costs of negotiating and ensuring the performance of contracts, under their catch-all rubric of "transaction costs". But without controls, large corporations and the economies of scale they create would not be possible. Controls allow a quarrelsome species ill-suited to organizations larger than small tribes to work together on vast projects like manufacturing jumbo jets and running hospitals. These control protocols are the result of many centuries of business experience and have a long future ahead of them, but the digital revolution will soon cause these paper-era techniques to be dramatically augmented by, and eventually integrate into, smart contracts.

Controls enable auditing of contract performances, allowing more precise inference of the behavior of an agent. Auditing is costly, so it is undertaken by random sampling. Economists study the substitutability between the probability of verifying a breach and the magnitude of legal fines, where physical enforcement is used. Conceivably, one could substitute increasingly high penalties for increasingly rarer and less expensive auditing. However, this is not robust to real-world conditions of imperfect information.

Since controls primarily address the implicit contracts between employees and employer, there is little mapping from contract to control. A secondary function of controls to to monitor contracts with other organizations. Here there is some mapping, but it is confounded by the integration of the two functions in most controls. Rather than based on contractual terms, controls are typically based on managerial authorization.

Controls are typically based around amounts of money and quantities of goods. A canonical control is double entry bookkeeping, where two books are kept, and there must be arithmetic reconciliation between the books. To conceal an irregularity, necessary to omit from both sides, or to record entries offsetting the irregularity. Notice that there is a problem distinguishing error from fraud. This problem crops up in many areas in both auditing and smart contracts. To illustrate, here are two common control techniques:

Imprest: this is a family of controls involving the receipt or disbursement of bearer certificates (usually notes and coins). One example is the protocol used at most movie theaters. Entry is segregated from payment by introducing tickets and establishing two employee roles, the ticket seller in a booth, and the ticket stub salesman at the entrance. Periodically, a bookkeeper reconciles the number of tickets with the total paid. Discrepancy again indicates fraud or error.

Customer audit: Techniques to get the customer to generate initial documentation of a transaction. For example, pricing goods at $.99 forces the employee to open the cash register to make change, generating a receipt.

A complete control protocol typically features the generation of initial documentation, segregation of duties, and arithmetic reconciliation of quantities of goods, standard service events, and money.

Of these, the segregation of duties deserves special comment.

It has long been recognized that an intermediary is more trustworthy when it is distributed. In a large business, transactions are divided up so that no single person can commit fraud. Segregation of duties is an instance of the principle of required conspiracy. For example, the functions of warehouse/delivery, sales, and receipt of payments are each performed by different parties, with a policy that each party reports every transaction to a fourth function, accounting. Any singular reported activity (e.g., delivery without receipt of payment) indicates potential fraud (e.g., a delivery was made to a customer and the payment pocketed instead of being put into the corporate treasury). Segregation of duties is the auditor's favorite tool. Where it is absent the auditor cries "foul", just as a good engineer would react to a single point of failure. Many cryptographic systems have rightfully gone down to commercial failure because they ground down to trust in a single entity rather than segregating functions so as to require conspiracy.

There are least three significant differences between the scope and emphasis of smart contracts and controls. Controls are paper-era protocols designed around static forms, place little emphasis on confidentiality, and are based on management authorizations rather than one-to-one relationships.

Smart contracts can be based on a wide variety of interactive protocols and user interfaces, and can be involved in a wide variety of kinds of contractual performance. Control protocols, developed in the era of paper, are based on static forms passed as messages and processed in tables and spreadsheets. Controls focus on money and counts of standardized goods and service events, easily recorded by numbers and manipulated by arithmetic, while mostly ignoring other kinds or aspects of contractual performance. Checksums on numbers, the basis of reconciliation, are crude and forgeable compared to cryptographic hashes. Electronic Data Interchange (EDI) keeps these static forms and maintains reliance on controls. It uses cryptographic hashes for nothing more sophisticated than integrity checks on individual messages.

Controls place little emphasis on confidentiality, at least in the modern accounting literature. The emphasis on confidentiality in paper-era protocols is lacking because violation of often implicit confidences, via replication of data, was much more difficult with paper. Furthermore, technologies for protecting confidentiality while auditing were not feasible. Businesses traditionally trusted accounting firms with confidences, a trust that has eroded over the last century, and will erode still further as accounting firms start taking advantage of the vast amounts of inside and marketing information they are collecting from their customers' databases during audits. Using paper-based protocols in a digital world, there are few effective controls against the auditors themselves. Post-unforgeable transaction logs and multiparty secure computation, discussed below, indicate the possibility of cryptographic protocols to implement less relavatory but more effective auditing trails and controls; their use may be able to ameliorate the growing problems with data mining and breach of confidentiality.

Auditors place quite a bit of trust in management to authorize transactions in a secure and productive manner. Objecting to this dual trust in management and distrust of employees inherent in the accounting tradition, there has been a trend in the last two decades towards a loosening of controls as a part of hierarchy flattening and empowerment of professional employees. Unfortunately, loose controls have led to several recent scandals in the banking and investment trade. The most recent view is that there must be a learned tradeoff between controls and empowerment. The smart contract view is that we need smarter controls, originating at the ownership of the company, and entailing less asymmetry between management and other professional employees. This means converting many implicit employee contracts to more explicit smart contracts based on more direct relationships between owners (or at least their directors) and employees, and symmetric formalizations between employees.

Although most of these differences are biased against controls, these traditional protocols have a long future ahead of them, simply because they have a long past. They are highly evolved, hundreds of years old (double-entry bookkeeping, for example, predates the Renaissance). Smart contracts will incorporate many techniques and strategies from control protocols, such as generation of an initial record, segregation of duties, and reconciliation. It will not be long, however, before smart contracts start augmenting and transforming traditional business procedures, making a wide variety of new business structures possible and in the long run replacing traditional controls.

Electronic Data Interchange Electronic Data Interchange (EDI) is the computer-to-computer communication of standardized business transactions between organizations, in a standard format that permits the receiver to perform the intended transaction. It renders traditional static business forms in cyberspace, and maintains the dependence on traditional controls. Beyond simple encryption and integrity checks, EDI does not take advantage of algorithms and protocols to add security and "smarts" to business relationships. It enables more rapid execution of traditional negotiation and performance monitoring procedures.

EDI loses some security features provided by physical paper (such as difficulty of copying) while not gaining advantages from the wide variety of protocols possible beyond simple message-passing of static forms. This article examples a much richer set of protocols.

EDI contracts tend to be merely reiterations of existing terms and conditions, with only some timing expectations changed for the electronic environment. By redesigning our business relationships to take advantage of a richer set of protocols, smart contracts can take us far beyond the paper-based paradigm of shipping around forms in a secure manner.

The following classification, derived from Sokol [3 ], illustrates the variety of business forms that have been rendered in electronic form:

Administrative

Product code and price catalogs

Catalog updates

Forecasts and plans

Deals and promotions

Statements

Prepurchasing

Requests for quote (&response)

Inventory inquiry/advice

Purchasing

Purchase order & acknowledgment

Purchase order change & acknowledgment of change

Material release

Point of sale/inventory on hand

Shipping and Receiving

Shipment status inquiry & response

Advance shipment notification

Bill of Lading

Freight bill

Warehouse

Inventory inquiry & status

Shipping notice

Receipt confirmation

Shipment order

Shipment confirmation

Customs

Declaration

Release

Billing and Paying

Invoice

Payment remittance

Credit and debit memos

Receipts

Automata as Authority Focal (or Schelling) points are often designed and submitted into negotiations by one side or another, both to bias the negotiations and to reduce their cost. The fixed price at the supermarket (instead of haggling), the prewritten contract the appliance salesman presents you, etc. are examples of hard focal points. They are simply agreed to right away; they serve as the end as well as the beginning of negotiations, because haggling over whether the nearest neighbor focal point is better is too expensive for both parties.

There are many weak enforcement mechanisms which also serve a similar purpose, like the little arms in parking garages that prevent you from leaving without paying, the sawhorses and tape around construction sites, most fences, etc. Civilization is filled with contracts embedded in the world.

More subtle examples include taxi meters, cash register readouts, computer displays, and so on. As with hard focal points, the cost of haggling can often be reduced by invoking technology as authority. "I'm sorry, but that's what the computer says", argue clerks around the world. "I know I estimated $50 to get to Manhattan, but the meter reads $75", says the taxi driver.

Dimensions of Contract Design Economists stress two properties important to good contract design: observability by principals and verifiability by third parties such as auditors and adjudicators. From the traditions behind contract law and the objectives of data security, we derive a third objective, privity. We flesh out the dimensions of contract design by disentangling mental from computational transaction costs, classifying the kinds of enforceability, characterizing the temporal phases of contracting, and discussing the nature of tradeoffs between the three design objectives. Mental and Computational Transaction Costs The costs that smart contracts address are lumped by economists under the catch-all rubric of "transaction costs". We can divide these into mental and computational transaction costs.

One major category of costs include the cost of anticipating, agreeing to, and clearly writing down the various eventualities. These are largely mental transaction costs, although online research tools, for example, may bring more information about eventualities.

Most contractual dispute involves an unforeseen or unspecified eventuality. A common example of an unspecified eventuality is that the parties behind a pseudonym might change: corporate change of officers, sales of brand names, and so on. Dye [ 4 ] suggests that we estimate the cost of writing down a function of the quality of input q traded a function of price: q = f(p). The cost he suggests is the number of different values q can take on as p varies: the number of discrete consequences of making the contract at p. Hart suggests that we should take into account the simplicity of the function. This leads us to the Minimum Description Length of Rissanen and Wallace, an approximation for the universal description length of a function.

An even more sophisticated model would account for the computational costs of foreseeing these eventualities, some of which may be uncomputable (and therefore of infinite cost). Where eventualities remain unspecified, contracts remain incomplete.

Where counterparties lack focal points, they lack a meeting of minds. Negotiation addresses this gap; the farther apart the focal points (in terms of value), the more expensive the negotiations. There are a variety of institutions of negotiation, which economists study under the rubric of "mechanisms". These range from simple haggling to sophisticated auctions and exchanges.

Securing the contractual phases, especially performance, against third parties can be costly; this is one of the major transaction costs which smart contracts address. This is discussed under "Attacks Against Smart Contracts" below.

One example where we must untangle mental from computational transaction costs is in examining the idea that lower computational costs make micropayments possible.

The function of prices, from the point of view of a shopper, is to let the shopper map his personal resources (budget) to his personal values (unique and not directly observable). This mental process requires comparison of the purchase price of a good to its personal value. This entails a significant mental cost, which sets the most basic lower bounds on transaction costs. For example, comparing the personal value of a large, diverse set of low-priced goods might require a mental expenditure greater than the prices of those goods (where mental expenditure may be measurable as the opportunity costs of not engaging in mental labor for wages, or of not shopping for a fewer number of more comparable goods with lower mental accounting costs). In this case it makes sense to put the goods together into bundles with a higher price and an initutive synergy, until the mental accounting costs of shoppers are sufficiently low.

These mental accounting costs, not the physical or computational or amortized R&D costs of payment or billing method, set the main lower bound on price granularity. Judging from pricing granularity trends such as the trend towards flat rates in online services, online pricing granularity is far above suggested micropayment levels of a few cents or even fractions of a cent. The mental accounting costs for a typical on-line consumer seem to be somewhat higher than those in more familiar areas of commerce. These mental costs often dwarf the computational costs; reductions in the per transaction computational costs of smart contracts may often be economically insignificant. Other transaction costs, such as fraud, theft, and unforeseeability, are usually more important objectives for cost reduction by smart contracts.

Contracting Phases For the temporal phases of contracting we use the following schema, classified according to the two-phase model used in economics:

Ex-Ante

Negotiation

Commitment

Ex-Post

Performance

Adjudication

Smart contracts often involve trusted third parties, exemplified by an intermediary, who is involved in the performance, and an adjudicator, who is invoked to resolve disputes arising out of performance (or lack thereof). Intermediaries can operate during search, negotiation, commitment, and/or performance. Hidden knowledge, or adverse selection, occurs ex-ante; hidden actions (moral hazards) occur ex-post.

Here are some examples of contemporary electronic commerce activities and the phases of contracting they deal with:

EDI commitment, performance

Contract drafting negotiations

Web surfing search

Payment performance

Online exchange search, negotiation, commitment

"I agree" button commitment

This article covers all phases, with a particular emphasis on performance. Observability, Hidden Knowledge, and Hidden Actions

The first objective of smart contract design is observability, the ability of the principals to observe each others' performance of the contract, or to prove their performance to other principals. The field of accounting is, roughly speaking, primarily concerned with making contracts an organization is involved in more observable.

Economists discuss "hidden knowledge", also known as "adverse selection", which can occur due to lack of ability to observe potential counterparties during the search and negotiation phases. Another major problem is "hidden actions", also known as "moral hazard", which can occur due to the lack of observability and ability to drop out of contract during the performance phase of a contract.

One important task of smart contracts, that has been largely overlooked by traditional EDI, is critical to "the meeting of the minds" that is at the heart of a contract: communicating the semantics of the protocols to the parties involved. There is ample opportunity in smart contracts for "smart fine print": actions taken by the software hidden from a party to the transaction. For example, grocery store POS machines don't tell customers whether or not their names are being linked to their purchases in a database. The clerks don't even know, and they've processed thousands of such transactions under their noses. Thus, via hidden action of the software, the customer is giving away information they might consider valuable or confidential, but the contract has been drafted, and transaction has been designed, in such a way as to hide those important parts of that transaction from the customer.

Without user interfaces smart contracts are largely invisible, like the electronics in newer car engines. This is both a blessing - counterparties don't have to feel like they're dealing with user-hostile computers - and a curse - the "smart fine print" problem of hidden actions.

Here's a little example of smart fine print:

if (x == true) {

printf("x is false");

}

To properly communicate transaction semantics, we need good visual metaphors for the elements of the contract. These would hide the details of the protocol without surrendering control over the knowledge and execution of contract terms. A primitive but good example was provided by the SecureMosaic Web browser from CommerceNet. Encryption was shown by putting the document in an envelope, and a digital signature by affixing a seal onto the document or envelope. On the other hand, most Web servers log connections, and sometimes even transactions, without warning users - classic hidden actions.

Online Enforceability

Amid all the hype about "information warfare", lost in the noise is the fact that it is impossible to commit an act of physical violence over the Net. That includes not only all physical crimes of coercion, but also arrest, incarceration, and other traditional methods of law enforcement. Because of this fact, and the jurisdictional swamp that is the Internet, this article concentrates on means of protecting against breach and third parties that do not rely on law enforcement.

We can categorize the security measures against breach, eavesdropping, and interference in the following manner:

Proactive

- breaching actions rendered impossible

- either side can drop out with minimal loss upon counterparty

breach

Reactive

Deterrence

- reputation

- physical enforcement

third parties: tort law

Damage Recovery

- secured transaction

- reputation

- physical enforcement

principals: contract law

third parties: tort law

Currently, the most prevalent forms of security software are not proactive cryptography, but reactive and panoptic methods like virus scanning software, filtering firewalls, traceroutes of attackers, etc. Once modern cryptographic protocols are more widely deployed, the balance may shift towards preventative security.

Verifiability by Adjudicators Reactive measures rely upon two areas: verifiability and penalties. As discussed in the section on accounting controls, under ideal economic conditions, the statistical distribution of verification failures is known, so that verification costs and penalties are can be traded off neatly. But with imperfect information, the jurisdictional swamp, and lack of collateral or other security, collection of damage awards is even more severely limited than in contracts confined to traditional geographic jurisdictions. Reputation costs may be the only practical source of penalties in many cases. For reactive measures to work, high verifiability is critical.

So our second objective is verifiability, the ability of a principal to prove to an adjudicator that a contract has been performed or breached, or the ability of the adjudicator to find this out by other means. The disciplines of auditing and investigation roughly correspond with verification of contract performance.

Privity: Protection from Third Parties

Our third objective of smart contract design is privity, the principle that knowledge and control over the contents and performance of a contract should be distributed among parties only as much as is necessary for the performance of that contract. This is a generalization of the common law principle of contract privity, which states that third parties, other than the designated adjudicators and intermediaries, should have no say in the enforcement of a contract. Generalized privity goes beyond this to formalize the common claim, "it's none of your business". Attacks against privity are epitomized by third parties Eve the eavesdropper, a passive observer of contents or performance, and malicious Mallet, who actively interferes with performance or steals service. Under this model privacy and confidentiality, or protecting the value of information about a contract, its parties, and its performance from Eve, is subsumed under privity, as are property rights. The field of security (especially, for smart contracts, computer and network security), roughly corresponds to the goal of privity.

Our generalization derives, not only from analyzing the objectives of computer security, but also from examining the ancient usage of "privity". To recover privity, we use hermeneutical techniques. A sliver of the original idea of privity has remained in English contract law. Here is a typical definition:

PRIVITY OF CONTRACT. The relation which subsists between two contracting parties [ 5 ].

Here being "in privity" to a contract is simply defined as being a party to the contract. We can get more insight by looking into the requirements for becoming such a party, by forming such a contract. The chief requirement is a "meeting of the minds": a state of mutual agreement.

We have to go back more than a century to find significant usage of the word beyond its parched modern usage in English law. In English literature prior to the 20th century, "privity" appears in contexts which indicate two connotations. The first, most linguistically obvious connotation, is that one has "privity" to an event if one has knowledge of it that is shared by few others. In this interpretation it means being privy to an event. The second connotation is that one assents to that event, or to its consequences. The event might have been called to the attention of others; it or its consequences might have been prevented or avoided. "Privity" thus often carries the connotation of moral or legal responsibility. The event is usually, furthermore, some human action; what contract law refers to as "performance" when such action has been promised. Much of this knowledge is what Michael Polanyi describes as "tacit knowledge" [ 6 ], knowledge which cannot be articulated but must remain subjective. Furthermore, even explicit knowledge of special circumstances is widely dispersed [ 7 ]. The basis of privity is the distribution of knowledge, both articulable and implicit.

The modern legal principle of "privity" [ 8 ] has been modified in many jurisdictions by the doctrine foreseeability. The fixed, clear boundary of foreseeability around a contract provided by privity is erased, in an attempt to define the scope of responsibility as "foreseeability" in particular cases. Now the courts have to draw new clarified boundaries, lest the law remain a muddle.

One has "privacy" with respect to some information against those with whom one is not in privity, in the early "privy to" sense. In contract law, "privity" refers only implicitly to some relative lack of third party knowledge, but refers directly to third party _control_ at law. In reconstructing privity for our own uses, we can generalize the concept to refer to lack of both third party knowledge _and_ control.

This brings us to an important and fascinating parallel which shows the utility of this revitalized concept of privity in the information age. Our definition of privity now corresponds to the passive and active attacks against a data security system. Passive attacks against privacy are epitomized by Eve, the eavesdropper. Active attacks against performance are epitomized by Mallet, a malicious interferer [ 9 ].

Since "meeting of the minds", one connotation of "privity", comes under the rubric of observability, we will use "privity" to refer to protection from third parties. Thus privity is the protection of the contents and activitities of a relationship - or, specifically, the terms, performance, and adjudication of a contract - from third parties.

To maintain knowledge and control, performance must be encapsulated: protected from outside influences, especially sophisticated attacks. This is the idea behind both the legal doctrine of privity, which restricts redress to the parties to a contract, and the idea of property rights.

Our generalized privity thus encompasses property rights as stable objects linked to particular contracts (and thereby the parties in privity to such contracts, the "owners"). Privity creates a clear boundary within which operate a coherent set of rights, responsibilities, and the knowledge with which to carry out those responsibilities and protect those rights. Clarified boundaries also allow accountability. Protection from extraneous interference allows us to focus responsibility for the consequences of contract-related activity onto the parties to the contract.

Trading Off Contract Design Objectives

Privity says that we want to minimize vulnerability to third parties. Verifiability and observability often require that we invoke them. An intermediary must be trusted with some of the contents and/or performance of the contract. An adjudicator must be trusted with some of the contents, and some of the history of performance, and to resolve disputes and invoke penalties fairly. In smart contract design we want to get the most out of intermediaries and adjudicator, while minimizing exposure to them. One common outcome is that confidentiality is violated only in case of dispute.

Many kinds of specific performance are often entrusted to intermediaries. We must be able to trust the intermediary (credit agency, anti-virus software vendor, certificate intermediary, digital cash mint, etc.) with their particular claims (about creditworthiness, dangerous byte patterns, identity, conservation of the money supply, etc.) As Ronald Reagan remarked in a slightly different context, "trust but verify". To deserve our trust, intermediaries must convince us that their claims are true. We need to be able to "ping" their veracity, verifying that certain claimed transactions in fact occurred. An entire profession exists in market economies to perform this function: auditing.

Ideally, observability and verifiability can also include the ability to differentiate between intentional violations of the contract and good faith errors, but this is difficult in practice, since the difference is often largely one of subjective, unrevealed intent.

Building Blocks of Smart Contract Protocols

Protocols A protocol [ 9 ] in computer science is a sequence of messages between at least two computers. At a higher level of abstraction, a protocol consists of algorithms communicating via messages. These programs act as proxies, or agents, for human users, who communicate their preferences via users interfaces. We distinguish protocol endpoints by names such as "Alice" and "Bob", but it should be kept in mind that the end points are really computer processing units, which may or may not be under the control of, or taking actions contrary to the intent of, the human user. Human users typically do not have full knowledge of the protocol in question, but rather a metaphorical understanding obtained via user interface, manuals, and so on. Unlike most real- world contracts, protocols must be unambiguous and complete.

Protocols come in three basic types. I have modified the terminology of Schneier [ 5 ] to match more closely to the corresponding business terminology:

self-enforcing: Alice <--> Bob, mediated: Alice <--> intermediary <--> Bob adjudicated: (Alice <--> Bob> --> [evidence] --> adjudicator

The corresponding smart contracts elaborate on "Alice" to distinguish between the software (in two components, the endpoint of protocol and the user interface), and Alice herself. Cryptographic and other computer security mechanisms give us a kit of tools and parts from which we can build protocols, which form the basis of smart contracts.

Cryptographic Protocols

A family of protocols, called cryptographic protocols because their first application was computerized "secret writing", provide many of the basic building blocks that implement the improved tradeoffs between observability, verifiability, privity, and enforceability in smart contracts. Contrary to the common wisdom, obscurity is often critical to security. Cryptographic protocols are built around foci of obscurity called keys. A key's immense unknown randomness allows the rest of the system to be simple and public. The obscurity of a large random number, so vast that a lucky guess is astronomically unlikely, is the foundation upon which cryptographic protocols, and smart contracts based on them, are built. Two significant cautions are in order when thinking about how cryptographic protocols can be used in online relationships. The first is that protocols usually provide security "up to" some assumption. This assumption is a remaining weak point which a complete working system must address in some reasonable manner. One common endpoint is is assumptions about trusted third parties. Often the degree or function of the trust is not well specified, and it is up to the real-world systems analyst to characterize and ameliorate these exposures. The best mediated protocols only trust the intermediary or counterparty with a well limited function.

Even without trusted third parties, cryptographic protocols often ground out in trust of the counterparty. For example, encryption of a message provides confidentiality up to the actions of parties with decrypting keys. Encryption does not stop key holders from posting plain text to Usenet. We cannot just say that encryption provides "confidentiality" and leave our concern for confidentiality at that.

The second caution is that much of the terminology used in the cryptographic literature to name protocols ("signatures", "cash", etc.) is misleading. Sometimes the terminology falls short on substantial matters: a "digital signature", for example, is not biometric and is based on a key that can easily be copied if not protecting by another mechanism. Often cryptographic protocols can be generalized to much wider purposes than implied by the label. For example, "digital cash" is a very general protocol which can implement a wide variety of bearer certificates and conservation wrappers for distributed objects.

Attacks against Smart Contracts

Protocols for smart contracts should be structured in such a way as to make their contracts

(a) robust against naive vandalism, and

(b) robust against sophisticated, incentive compatible (rational) breach

A vandal can be a strategy or sub-strategy of a game whose utility is at least partially a function of one's own negative utility; or it can be a mistake by a contracting party to the same effect. "Naive" simply refers to both lack of forethought as to the consequences of a breach, as well as the relatively low amount of resources expended to enable that breach. Naive vandalism is common enough that it must be taken into consideration. A third category, (c) sophisticated vandalism (where the vandals can and are willing to sacrifice substantial resources), for example a military attack by third parties, is of a special and difficult kind that doesn't often arise in typical contracting, so that we can place it in a separate category and ignore it here. The distinction between naive and sophisticated strategies has been computationally formalized in algorithmic information theory

The expected loss due to third party attack is called the exposure. The cost of third parties to breach the security mechanism is the breach cost. If the breach cost is greater than the expected benefit, we can expect an incentive compatible attacker to breach the security.

Public and Secret Key Cryptography

A wide variety of new cryptographic protocols have emerged in recent years. The most traditional kind of cryptography is secret key cryptography, in which Alice and Bob (our exemplar parties to a smart contract) use a single shared, prearranged key to encrypt messages between them. A fundamental problem we will see throughout these protocols is the need to keep keys secret, and public key cryptography helps solve this. In this technique, Alice generates two keys, called the private and public keys. She keeps the private key secret and well protected, and publishes the public key. When Bob wishes to send a message to Alice, he encrypts a message with her public key, sends the encrypted message, and she decrypts the message with her private key. The private key provides a "trapdoor" that allows Alice to compute an easy inverse of the encryption function that used the public key. The public key provides no clue as to what the private key is, even though they are mathematically related. The RSA algorithm is the most widely used method of public key cryptography.

Public Authentication

Public key cryptography also makes possible a wide variety of digital signatures. These proves that a piece of data (hereafter referred to as just an "object") was in active contact with the private key corresponding to the signature: the object was actively "signed" with that key. There are two steps to an authentication protocol: signing and verification. These may occur synchronously, or, in many public protocols, a signature may be verified at some distant time in the future. The digital signature probably should have been called a "digital stamp" or "digital seal" since its function resembles more those methods than an autograph. In particular, it is not biometric like an autograph, although incorporation of a typed-in password as part of the private key used to sign can sometimes substitute for an autograph. In many Asian countries, a hand-carved wooden block, called a "chop", is often used instead of autographs. Every chop is unique, and because of the unique carving and wood grain cannot be copied. A digital signature is similar to the chop, since every newly generated key is unique, but it is trivial to copy the key if obtained from the holder. A digital signature relies on the assumption that the holder will keep the private key secret.

A blind signature publically authenticates privy information (but can we use non-privy signatures blindly as well?)/ This is a digital signature and secret-key encryption protocol that together have the mathematical property of commutativity, so that they can be stripped in reverse of the order they were applied. It's like stamping an unknown document through carbon paper (without having to worry about smudging). The effect is that Bob "signs" an object, for which he can verify its general form, but cannot see its specific content. Typically the key of the signature defines the meaning of the signed object, rather than the contents of the object signed, so that Bob doesn't sign a blank check. Blind signatures used in digital bearer certificates, where Bob is the clearing agent, and in Chaumian credentials , where Bob is the credential issuer.

Privy Authentication The blind signature is one example of the many "magic ink signatures" cryptographers have invented. Another class of these protocols are used to limit the parties allowed to either verify the signature or to learn the identity of the signer. The most privy are the zero-knowledge proofs, where only the counterparty can authenticate the prover. Designated confirmer signatures allow the signer to designate particular counterparties as verifiers. For example, a business could give particular auditors, investigators, or adjudicators the authority to verify signed objects, while other third parties, such as competitors, can learn nothing from the signature. Group signatures allow members to sign as an authentic member of a group, without revealing which member made the signature. Protection of Keys

So far, we've assumed parties like Alice and Bob are monolithic. But in the world of smart contracts, they will use computer-based software agents and smart cards to do their electronic bidding. Keys are not necessarily tied to identities, and the task of doing such binding turns out to be more difficult than at first glance. Once keys are bound, they need to be well protected, but wide area network connections are notoriously vulnerable to hacking.

If we assume that the attacker has the ability to intercept and redirect any messages in the network protocol, as is the case on wide area networks such as the Internet, then we must also assume, for practical all commercial operating systems, that they would also be able to invade client if not merchant computers and find any keys lying on the disk.

There's no completely satisfactory solution to end point operations security from network-based attacks, but here's a strategy for practically defanging this problem for public-key based systems:

All public key operation can be performed inside an unreadable hardware board or smart card on a machine with a very narrow serial-line connection (ie, it carries only a simple single-use protocol with well-verified security) to a dedicated firewall. This is economical for high traffic servers, but may be less practical for individual users. Besides better security, it has the added advantage that hardware speeds up the public key computations.

If Mallet's capability is to physically seize the machine, a weaker form of key protection will suffice. The trick is to hold the keys in volatile memory. This makes the PC proof from physical attacks - all that needed to destroy the keys is to turn off the PC. If the key backups can be hidden in a different, secure physical location, this allows the user of this PC to encrypt large amounts of data both on the PC itself and on public computer networks, without fear that physical attack against the PC will compromise that data. The data is still vulnerable to a "rubber hose attack" where the owner is coerced into revealing the hidden keys.

Capabilities Object-oriented, or capability, security is a deep and promising area, but beyond the scope of this article. Capabilities can potentially simplify the design of many distributed security protocols. Instead of developing a new or modified cryptographic protocol for each contracting problem, capabilities may allow us to design a rich variety of distributed security protocols over a common cryptographic framework.

For more information see Introduction to Capability Based Security

Mixes Mixing is a general technique of confidentiality used in many protocols. Three examples of mixing discussed in this paper are anonymous remailers, bearer certificates, and the Dai/Finney anonymous loan protocol. In this section we discuss remailers.

Information about who is talking to whom, such as can be found on telephone bills, can be quite valuable even without records of the actual content. Confidential messsaging is necessary for the some of the privity features of Chaumian credentials and bearer certificates to be strongly implemented on an actual network. To provide this traffic confidentiality, a digital mix can allow parties to communicate across a network without revealing their partners to network providers or the outside world. In a mix, traffic analysis by Eve is prevented by the Russian-doll encryption of the message by the sender with the public keys of each mix operator in the chain, and the mixing of messages by each operator, so that panoptic wiretapper Eve loses track of the messages. For the sender/recipient pair to remain confidential, only 1 out of N of the operators needs to be trusted with their local traffic information, although Eve can sometimes gather statistics over large numbers of messages between the same partners to eventually guess who is talking to whom. The communicating parties can also be mutually anonymous, and with normal encryption need trust no other parties with the content of messages. The "Mixmaster" remailer implements most of the features of a digital mix [ 10 ].

Quora

Quorum distribution of performance or control over resources can be based on the secret sharing of keys needed to perform or control a resource. These are also known as threshold techniques. These are methods of splitting a key (and thus control over any object encrypted with that key) into N parts, of which only M are needed to recreate the key, but less than M of the parts provide no information about the key. Secret sharing is a potent tool for distributing control over objects between principals.

Markus Jacobsson has designed a quorum of mints for signing digital coins, for example. Quorum establishes a "required conspiracy" of M out of N to perform a function, providing an option for stronger protection than the typical 2 out of N used in segregation of duties, and greater confidence in the security underlying the segregation.

Post-Unforgeable Transaction Logs

Traditionally, auditors have contacted counterparties in order to verify that a transaction actually took place (The "principle of required conspiracy" at work again). With post-unforgeable logs, via a hierarchical system of one-way hash functions, a party can publically commit to transactions as they are completed by publishing signed cumulative hashes of the transaction stream. The confidentiality of the transaction is fully maintained until an auditor "pings" the transaction to determine its actual nature. The counterparty identity can remain confidential, because it is not required to establish the other facts of the transaction. The only attack is to forge transactions in real time, as the transaction itself takes place, which in most practical cases will be unfeasible. Most accounting fraud involves analyzing sets of completed transactions and then forging them to make them compute to a desired counterfactual result.

Mutually Confidential Computation Cryptographers have developed protocols which create virtual machines between two or more parties. Multiparty secure computation allows any number of parties to share a computation, each learning only what can be inferred from their own inputs and the output of the computation. These virtual machines have the exciting property that each party's input is strongly confidential from the other parties. The program and the output are shared by the parties. So, for example, we could run a spreadsheet across the Internet on this virtual computer. We would agree on a set of formulas, set up the virtual computer with these formulas, and each input our own private data. We could only learn only as much about the other participants' inputs as we could infer from our own inputs and the output.

There are two major complications. The first is that this virtual computer is very slow: one machine instruction per network message. The second is that some parties learn the results before others. Several papers have disussed the fraction of parties one must trust in order to be assured of learning the correct output. The mechanism must be constructed so that a sufficient number of parties have an incentive to pass on the correct result, or reputation, side contracts, etc. used to the same effect.

With these caveats, any algorithmic intermediary can, in principle, be replaced by a trustworthy virtual computer. In practice, because of the two complications, we usually construct more limited protocols out of more efficient elements.

Multiparty secure computer theory, by making possible privy virtual intermediation, has major implications for all phases of contracting. This can be seen most clearly in the area of negotiations. A "mechanism" in economics is an abstract model of an institution which communicates with its participants via messages, and whose rules can be specified algorithmically. These institutions can be auctions, exchanges, voting, and so on. They typically implement some kind of negotiation or decision making process.

Economists assume a trusted intermediary operates the mechanism. Here's a simple example of using this virtual computer for a mechanism. Alice can submit a bid price, and Bob an ask price, to their shared virtual computer which has one instruction, "A greater than B?". The computer then returns "true" if Alice's bid is greater than Bob's offer. A slightly more sophisticated computer may then decide the settlement price according to a number of different algorithms (Alice's bid, Bob's ask, split the difference, etc.) This implements the mechanism "blind bargaining" with no trusted intermediary.

In principle, since any computable problem can be solved on this virtual computer (they are "Turing complete"), any computable economic mechanism can be implemented without a trusted intermediary. In practice, these secure virtual computers run very slowly (one virtual machine instruction per network message), and the order in which participants learn results often matters. But the existence proof, that any economic mechanism can be run without a trusted intermediary, up to temporal issues, is very exciting. This means that, in principle, any contract which can be negotiated through a trusted third party (such as an auction or exchange) can be negotiated directly. So, in some abstract sense, the only remaining "hard" problems in smart contract negotiations are (a) problems considered hard even with a trusted intermediary (for the standard economic reasons), (b) nonsimultaneity problems in learning the decision, and (c) the task of algorithmically specifying the negotiating rules and output contract terms (This includes cases where an intermediary adds knowledge unavailable to the participants, such as a lawyer giving advice on how to draft a contract).

Applying this kind of analysis to the performance phase of contracts is less straightforward. For starters, economic theories of the performance phase are not as well developed or simple as the mechanism theory of negotiations. Indeed, most economic theory simply assumes that all contracts can be perfectly and costlessly enforced. Some of the "transaction cost" literature has started to move beyond this assumption, but there are few compelling results or consensus theories in the area of techniques and costs of contract enforcement.

Performance phase analysis with multiparty secure computer theory would seem to apply only to those contracts which can be performed inside the virtual computer. But the use of post-unforgeable auditing logs, combined with running auditing protocols inside the shared virtual computer, allows a wide variety of performances outside the virtual computer to at least be observed and verified by selected arbitrators, albeit not proactively self-enforced.

The participants in this mutually confidential auditing protocol can verify that the books match the details of transactions stored in a previously committed transaction log, and that the numbers add up correctly. The participants can compute summary statistics on their confidentially shared transaction logs, including cross- checking of the logs against counterparties to a transaction, without revealing those logs. They only learn what can be inferred from the statistics, can't see the details of the transactions. Another intriguing possibility is that the virtual computer can keep state over long periods of time, allowing sophisticated forms of privy and self-enforcing secured credit.

With mutually confidential auditing we will be able to gain high confidence in the factuality of counterparties' claims and reports without revealing identifying and other detailed information from the transactions underlying those reports. These provide the basis for solid reputation systems, and other trusted third party systems, that maintain integrity across time, communications, and summarization, and preserve confidentiality for transaction participants. Knowing that mutually confidential auditing can be accomplished in principle may lead us to practical solutions. Eric Hughes' "encrypted open books" was one attempt.

Contracts with Bearer

Bearer Certificates

Bearer certificates implement transferable rights on standardized contracts. Each kind of contract (for example, each denomination of "coin" in digital cash) corresponds to a digital signature, just as each issue of Federal Reserve Notes or stock certificates corresponds to a particular plate.

In the most straightforward bearer certificate protocol, the issuer and transfer agent (the same entity, for our purposes, though they can easily be unbundled) create a serial number (really a large unguessable random number, rather than a sequence), and add it to a list of issued certificates. The transfer agent clears a transfer by checking the signature to identify and nature of the bearer contract and verify that it was made, then looking on that contract's issued list to make sure the serial number is there, then removing the serial number. Alternatively, the issuer can let the issuee make up the serial number, then, when cleared, check the signature and put the number on the list of cleared certificates. The signature provides the assurance that the certificate is indeed the the particular kind of contract with bearer, while the serial number assures that the same instance of that contract is not cleared or redeemed more than once. In these simple versions, the transfer agent can link the transferee to the transferor for all transfers. To implement the privacy characteristics of coins and physical bearer certificates, we need to add unlinkability features.

Unlinkable Transfers Unlinkability can be provided by combining the second variation above, a list of cleared certificates, with blind signatures and a mixing effect. Enough instances of a standardized contract are issued over a period of time to create a mix. Between the issuing and clearing of a certificate, many other certificates with the same signature will be cleared, making it highly improbable that a particular clearing can be linked to a particular issue via the signature. There is a tradeoff between the mixing effect and the exposure to the theft of a "plate" for a particular issue: the smaller the issue, the smaller the exposure but the greater the linkability; a larger issue has both greater exposure and greater confidentiality.

Blind signatures can be used to make certificate transfers unlinkable via serial number. Privacy from the transfer agent can take the form of transferee-unlinkability, transferor-unlinkability, or "double blinded" where both transferor and transferee are unlinkable by the transfer agent or a collusion of a transfer agent and counterparty.

Bearer certificates come in an "online" variety, cleared during every transfer, and thus both verifiable and observable, and an "offline" variety, which can be transferred without being cleared, but is only verifiable when finally cleared, by revealing any the clearing name of any intermediate holder who transferred the object multiple times (a breach of contract).

This unlinkability is often called "anonymity", but the issue of whether accounts are issued to real names or pseudonyms, and whether transferor and transferee identify themselves to each other, is orthogonal to unlinkability by the transfer agent in the online model. In the off-line model, account identification (or at least a highly reputable and/or secured pseudonym) is required: passing an offline certificate a second time reveals this identity. Furthermore, communications channels can allow Eve to link transferor and transferee, unless they take the precaution of using an anonymous remailer. Online clearing does make lack of identification a reasonable option for many kinds of transactions, although common credit and warrantee situations often benefit from or even require identification.

When confronting an attempted clearing of a cleared serial number, we face an error-or-fraud dilemma similar to the one we encountered above in double entry bookkeeping. The ecash(tm) protocol from DigiCash actually takes advantage of this ambiguity, second-transferring certificates on purpose to recover from a network failure. When certificates are lost over the net it is not clear to the transferor whether they have been received and cleared by the transferee or not. Second-transferring directly with the transfer agent resolves the ambiguity. This only works with the online protocol. The issue of distinguishing error from fraud is urgent in the offline protocol, but there is as yet no highly satisfactory solution. This problem is often intractable due to the subjectivity of intent.

Conserved Objects Issuance and cleared transfer of references to a distributed object conserves the usage of that object. This object becomes "scarce" in economic terms, just as use of physical objects is finite. Conserved objects provide the basis for a software economics that more closely resembles economics of scarce physical objects. Conserved objects can be used to selectively exclude not only scarce physical resources (such as CPU time, network bandwidth and response time, etc.), but also fruits of intellectual labor - as long as one is willing to pay the price to interact with that information over the network rather than locally (cf. content rights management). Conservation immunizes objects and the resources they encapsulate to denial of service attacks. Bearer certificate protocols can be used to transfer references to a particular instance or set of instances of an object, just as they can be used to transfer other kinds of standardized rights.

Digital Cash

Digital cash is the premier example of a digital bearer certificate. The issue and transfer agent is called a "mint". Bearer certificate protocols enable online payment while honoring the characteristics desired of bearer notes, especially unforgeability (via the clearing mechanism) and transfer confidentiality (via mixing and blinding).

To implement a full transaction of payment for services, we often need need more than just the digital cash protocol; we need a protocol that guarantees that service will be rendered if payment is made, and vice versa. Current commercial systems use a wide variety of techniques to accomplish this, such as certified mail, face to face exchange, reliance on credit history and collection agencies to extend credit, etc. Potential smart contract protocols in this area are discussed under Credit.

Credentials

A credential is a claim made by one party about another. A positive credential is one the second party would prefer to reveal, such as a degree from a prestigious school, while that party would prefer not to reveal a negative credential such as a bad credit rating.

A Chaumian credential is a cryptographic protocol for proving that one's pseudonym (for example, the identification number one uses in a health care system) possesses credentials issued to one's other pseudonyms, without revealing linkages between these pseudonyms or between pseudonym and true name. It's based around the is-a-person credential the true name credential, used to prove, without revealing, the linkage between pseudonyms, and to prevent the transfer of pseudonyms between parties.

Content Rights Management Content protection contracts are valuable in that they incentive publishers to allow users to view content directly, rather than indirectly and partially via queries to remote servers. Content protection of software distributed online would allow it to be run locally rather than remotely, while enforcing the contract rights and copyrights of the publisher against the user. This local usage billing of software often goes under the rubric of "superdistribution" [ 11 ]. Watermarks

Watermark schemes work by altering less significant bits of content - usually a picture; sound works less well and text is difficult. These altered bits typically contain the identities of the publisher and viewer, and perhaps other information related to the contract. The idea is that, when investigators scan released content, the watermark will finger the breacher of the contract (or violator of copyright law).

Watermark investigation can be assisted by a quite inexpensive technique, Web spiders. These spiders look for redistributed watermarked material on the Web. The customer originating the copy can then be fingered.

One attack against watermarks is to overwrite likely watermark bits with other patterns legitimate to viewing software. The entanglement of watermark bits with bits important to the picture can be made rather obscure, but not strongly so by the standards of cryptography. Another attack is to steal content from a customer and distribute it as is. The watermark will finger the victim, rather than the thief.

All watermark schemes can be defeated with sufficient effort. These schemes can then be distributed as software worldwide. Once the initial effort is put into breaking a scheme, the marginal cost of breaking it is minimal. Furthermore, once the watermark is removed, the content can be distributed and even published [ 12 ] with secure anonymity.

In sum, watermark schemes can add significant risk to the copying of of low value or ephemeral information. This will be sufficient for many kinds of content, such as news or product updates. It won't stop, for long, the redistribution of high-value content. Since watermarks require traceable identification, they reduce customer privacy and require the inconvenience of registration and authentication, adding to the transaction costs of content purchase.

Controlled CPUs Contrary to the hype, there is no strong content protection software. Watermarks are as close as we've come, and they fall far short of the standards of computer security. Large sums have gone into attempts to develop such technology, resulting in hundreds of patents but no substantial results.

As a result, some publishers have begun putting their research dollars into a radical alternative, innocuously dubbed the "secure CPU" (SPU) [ 13 ]. This is a CPU that is "secure" against the owner of the computer! To enforce copyright or content contracts, the SPU monitors all content-related activity. Some marketing literature even lists, alongside the traditional copyright, a new "right" of publishers to monitor the usage of their content. Remarkably enough, these panoptic non-personal computers are the focus of major R&D efforts.

The radical SPU projects demonstrate both the high value of content contracts to publishers and the high price we have to pay to maintain the paper-era intellectual property model online. Strong content protection would be valuable in going beyond indirect and partial viewing of content on servers, to viewing content directly and locally. The price is the loss of control over our own computers, and loss of privacy over our activities on those computers.

The online content market is squeezed from above and below. From above, by the ease of redistributing high- value content. From below, by the mental transaction costs of charging for low value content - costs to which the requirements of registration and traceable identification add substantially. The size of the market in between is an open question. "Information wants to be free", but authors and publishers want to be paid for it. The current content market for more difficult to copy media, such as books, films, CD-ROM, and so forth is large, in the hundreds of billions of dollars per year. But on the Internet, free content dominates. Distributing ephemeral content in the form of service subscriptions is in most cases a more viable way to go. It remains to be seen how large the Internet content market will become, and to what extent customers will tolerate impositions on privacy and control of their computers in order to obtain legal content.

Reputation Systems

Reputation relies on intermediaries to convey information. For example, credit rating agencies are used to minimize adverse selection (hidden knowledge) problems in credit.

Reputation can be viewed as the amount of trust an agent has created for himself [ 14 ]. Reputation systems ultimately need to be based on fact rather than mere opinion or faith to be effective. For example, if we are to have a good credit rating system, we need to be confident that the credit record assembled by the agency is sufficiently accurate. Reputation information is typical gathered and distributed by intermediaries trusted to perform this task.

An important and general problem seems to be that of tagging a negative behavior source for future recognition. The tag might be used for negative information shared publically (e.g., credit ratings) or kept private (e.g., kill files). The behavior source might be non-human (e.g., recognizing virus patterns for the purposes of virus scanning). Where the behavior source is adaptable and self-interested, it has an incentive to spoof the tagging: a debtor to change names to avoid paying his debt, a virus to scramble its pattern to avoid scanning, and so on. If the tag carries a greater positive reputation (where zero is the reputation of a newcomer) this incentive is lost and the negative side of the reputation must be borne.

Can digital credentialling systems facilitate such negative reputation handling?

Service-specific, or local, name reputation may not be able to accomplish such tracking of negative reputation. If a local name accumulates more negative than positive credentials, it can simply be replaced by a newcomer local name for this service, without harming the positive reputation capital of the other behavior source local names. Hostile sources can continuously spoof innocent newcomers. Counterparties lose the ability to determine a history of previous hostile behavior - kill files, virus scanning, credit ratings, and so on fail.

Chaumian credentials also give the credential holder control over the transfer of credentials between his local names, creating an incentive to show positive credentials and hide negative ones. To remedy this, counterparties can demand "non-negative credentials" (in a form such as, "Alice in many transactions recorded by me in area X has never done bad things x,y,z"), Non-negative credentials are limited to areas that can be well-tracked. One such may be credit ratings, as long as one is doing the bulk of one's credit transactions through is-a-person linked local names.

Where Chaumian credentials are inapplicable, we might raise the cost of entry to be greater than that of a newcomer. This gives us two clearly defined reputation points to compare on an otherwise rather subjective scale: participation threshold and newcomer reputation. Both are subjective in the eye of the party choosing whether or not to participate in an activity with the name.

A participation threshold greater than newcomer reputation clashes with the desirable goal, that one be able to make a fresh start. For that matter, unless previous names and their positive reputations are linked to their new names, the pioneers cannot make a start, so that the institution itself cannot be started. Ditto for for institutional growth.

Tags that bundle the results of a wide variety of transactions - global names, or universal IDs, or "True Names" - seem to provide the most incentive for parties to carry their negative credentials. Most people have accumulated enough positive reputation is some areas that it is well-nigh impossible for them to start over their entire lives as newcomers.

A big problem arises with negative credentials when they are used, not merely to avoid engaging in a particular activity with a party, but for retribution against that party. Retribution may take some nonviolent online form, such as slander, denial of service attack, and so on, but the most worrisome form of retribution is a violent physical attack. Could we have digital tags that, while tracking negative behavior sources through the digital world, remain strictly unlinked to any kind of physical location data? Alas, we have several important systems, such as cellular phones, shipping addresses, etc. that provide such linkage.

Another problem for negative reputations is that "negative" is subjective. What is perfectly reasonable in one culture may bring a death sentence in another. However, there are some important, well-defined transactions where there is a widely agreed use of historical information. For example, for those who extend credit (and keep in mind, credit is implicit in most contracts), borrowers who have not paid their bills in the past are universally a negative. Being on the receiving end of a computer virus is practically always a negative.

The question may become one of deciding what of these three dimensions are most important, and how they can be traded off:

The gains to be had from tracking and thereby avoiding negative behavior sources The gains to be had from a nonviolent digital world (i.e., a virtual realm within which any digital action can have no physically violent consequences). The inconvenience (and perhaps impracticality) of partitioning the physical and digital worlds into different ID systems (more realistically, some "pure" subset of the digital world completely partitioned from location devices, physical shipping information, etc.)

Keep in mind too, that in practice these are evaluated primarily by a market evolving from its current state, rather than by abstract ethical philosophies.

Robin Hanson [ 15 ] has observed that in a world of global names, the use of a local name may signal the hiding of negative credentials, so that the use of global names is in equilibrium. A further problem with local names is that our relationships are often not neatly compartmentalizable into standard service types, and even where they are we might like to expand them into new areas. I suggest that, at minimum, we will want to reveal progressively more local names to our counterparties as our relationships with them become closer and more co-exposed. While the global name equilibrium may hold for many of our relationships, there may be plenty of areas where the privity benefits of localizing names outweigh the costs of being less or unable to differentiate newcomers from hostiles. (By "privity" I refer the entire general task of protecting relationships from hostile third parties; confidentiality and protection of property from theft are two examples of privity). For example, the preference-tracking service at www.firefly.com increases participation via the use of pseudonyms, and suffers little exposure from hostiles. On the other hand, credit transactions typically demand identifying information, because the contractual exposure typically outweighs benefits of privity.

Global name public keys, which have many drawbacks in terms of privity, may be the best way to track negative reputation, but they are no panacea. There is an important conundrum in an ID-based key system: the conflict between the ability to get a new key when the old one is or could be abused by another (key revocation), and the ability of another to be sure they are dealing with the same person again. This may also provide an opportunity for parties to selectively reveal positive credentials and hide negative ones. For example, a person with a bad credit rating could revoke the key under which that rating is distributed and create a new one, while selectively updating their positive credentials to the new key (e.g., have their alma mater create a new diploma). Key revocation authorities might combine forces with credit rating agencies to avoid such erasure of negative history, but this gives them even more centralized control - not merely over IDs but over important elements of reputation associated with those IDs. This further violates the principles of separation of powers and segregation of duties, providing added opportunity for fraudulent issue or revocation of IDs along with fraudulent communication of reputation information.

The current universal (non-cryptographic) key in the U.S., the social security number (SSN), is very difficult to revoke; it's much easier to change your name. This policy is probably no accident, since the biggest economic win of global name identification is the tracking of negative reputations, which revocation can defeat. As long as the SSN is a shared database key, not used for the purpose of securely identifying a faceless transaction, there is little need for revocation beyond the undesired erasure of negative history. Combining a secret authentication key, which must be revocable, with a public universal ID is quite problematic.

Credit One of the basic outstanding problems in smart contracts is the ensurement of credit. This comes up not only in loans, but in any other contract which involves a temporal lag between performance and reciprocal performance of the contractual terms.

In current practice, there are several partially effective processes for ensuring future performance:

* Reputation (especially credit reports): often effective, but only to a point, as it is often hard for the debtor to accurately judge the future reputational effects of an action (e.g., failure to pay a bill, taking out too large a loan, etc.) that has clear, local, beneficial effects today. There is more imbalance in knowledge between current and distant consequences among individual consumers, but even among large organizations with high credit ratings it is not an irrelevant factor.

* Secured transactions: liens, escrow, etc.

* Garnishment of future income

* Law enforcement, especially to enforce transfer of control over liened assets, garnishment, etc.

These processes have a fundamental property in common - they violate the privity of credit transactions - in other words, they bring in third parties to track reputations or enforce repayment. Do credit transactions entail a fundamental imbalance in incentives that can only be redressed by bringing in third parties, or can the security protocols be discovered which allow credit with minimal or no third party involvement?

Pseudonymous Credit Ratings Wei Dai [ 16 ] proposes three important variables for reputation economics:

operating value: expected future profits, given the reputation throw-away value: profit from cheating, which ruins reputation replacement cost: cost of recreating reputation

In turn, Peter Swire [ 17 ] describes two problems facing inadequately secured or unsecured loans to "credit names":

Adverse selection: Prior deadbeats can start fresh by signing up for the new service. Going in, it will be biased in favor of deadbeats. This problem may be addressed by using Chaumian credentials. These allow the established positive reputations of previous names to be carried over to the credit name, without allowing anyone to link the two names. Entrants without positive reputations can be rejected. The endgame problem: A credit name can establish a good credit rating over time. When the limit is high enough, the borrower can quickly spend it all. A malicious borrower, with a good rating established under a previous name, can systematically profit at the expense of the lender, if the throw-away value is greater than the replacement cost. To address this problem, creditors will have to charge higher rates to new credit names and raise credit limits more slowly than for traceable names. Honest borrowers will subsidize the dishonest, to an even greater extent than they do in the current credit card system.

Secured Credit

Secured credit need not violate privity if the physical control over the securing property can be shared. So that, for example, automobile credit can be secured as long as repossession is possible, as described in the example above.

A standard mechanism of secured credit applicable online is the escrow. An escrow is an intermediary trusted to hold messages until messages from both sides are received, and, optionally, their contents verified - to extent the content is verifiable, and at the expense of some privity. The escrow then sends the messages off to their recipients, along with receipts. Messages can contain any sort of data: content, a bearer certificate, etc.

Ripped Instruments

Alice wants a New York City cab ride for which she's willing to pay $100, but she doesn't trust Bob the taxi driver to get her there on time if she pays up front. Bob in turn doesn't trust Alice to pay at the end of the trip. Commerce can be consummated by Alice tearing a $100 bill and giving half to Bob. After the trip she gives the other half to Bob, which he can then reassemble into a negotiable $100 bill. Alice loses her incentive to not pay. Bob gains incentive to get her there on time as promised. Both have made what economists call a "credible commitment" to perform their respective parts of the contract. Markus Jacobsson has digitized this idea, coming up with a protocol for ripped digital cash. As with many other aspects of digital cash, the idea can be generalized to rip bearer certificates of any kind. If the transfer is double-blinded the transfer agent has no knowledge of the participants and therefore no bias to favor one over the other. The transfer agent must, however, be able to assess proof of performance, and the protocol is only workable where such proof (in the form of proof of receipt of a message, for example) is available.

The ripped bill is similar to using the transfer agent as an escrow agent. An advantage over using an escrow agent is that the need for extra anonymous channels between the parties and the escrow is avoided. A disadvantage is that the transfer agent now has taken on the major additional job of acting as an adjudicator, assessing proofs of performance (or at the very least, must be responsible for subcontracting out this job and implementing the adjudicator's judgement).

Credit Cards

Credit cards provide relatively little protection from third parties, especially in the area of privacy, but they do have an interesting contractual feature worth noting, the chargeback. With chargebacks customers can get refunds on allegedly unwanted merchandise. The issuer tracks the number of chargebacks both for customers and merchants; too many chargebacks can get you booted out of the system. This provides an efficient mechanism for refunds without resorting to expensive tort proceedings. Many customers who read the fine print or otherwise learn about chargeback limits often do chargebacks despite receiving and enjoying the merchandise; there is no practical way for the issuer to detect such fraud, and so it can only be pruned by limiting the number of chargebacks per customer. Some merchants complain vociferously about such customer "theft", and it seems to make possible coordinated attacks to put merchants out of business, but nevertheless merchants sign up for credit cards, because that's what their customers have signed up for. The chargeback feature makes customers more comfortable purchasing goods of unknown quality, especially mail-order and over the Internet. Chargeback provides a crude but effective partial solution to the information asymmetry problem between retailers and consumers.

Interval Instruments

Tim May [ 18 ] has proposed a "time release" form of money that becomes good only after a certain date. "Interval money"; that would expire after a certain date has also been proposed. These can be implemented by a digital mint expiring or activating special issues of digital cash, or by a third party issuing escrowed keys at specific times. Since these keys are encrypted against the escrow agent, and that agent doesn't know what they will be used for, the escrow agent has no incentive to cheat. A generalization of this is that transfer and redeemability are each associated with interval sets, or validity periods when each can and cannot be performed. This is analogous to clipping coupons on bonds.

Known Borrowers of Unknown Amounts

Wei Dai and Hal Finney [ 19 ] have proposed a loan mix, to unlink borrowers from amount borrowed. The identity of the potential borrowers is still public, as well as the system for enforcing payment, but the actual amount loaned or borrowed remains unknown. The system starts with participants putting unknown amounts into a pot and getting receipts (bearer bonds) for these amount. All participants then borrow a standard amount. Whether a participant is a net borrower or a net creditor, and of what amount, remains private. When the loan is due all participants repay the standard amount, and the creditors reclaim the amounts on their bearer bonds. The amount actually borrowed (or, if negative, loaned) is the public amount borrowed minus the amount put into the pot. One consequence is that while negative reputations can still be accumulated when participants fail to pay back the standard amount, positive reputations are minimal, since participants who borrow and loan are indistinguishable. If future creditors put stock in positive participation, one could gain a credit rating by perpetually participating as a net borrower of zero, by loaning and borrowing the same amounts.

Conclusion

Smart contracts combine protocols, users interfaces, and promises expressed via those interfaces, to formalize and secure relationships over public networks. This gives us new ways to formalize the digital relationships which are far more functional than their inanimate paper-based ancestors. Smart contracts reduce mental and computational transaction costs, imposed by either principals, third parties, or their tools.

Mark Miller [ 20 ] foresees that the law of the Internet, and the devices attached to it, will be provided by a grand merger of law and computer security. If so, smart contracts will be a major force behind this merger.

The Author Nick Szabo is a Computer Science graduate of University of Washington. He has worked with the Jet Propulsion Laboratory, IBM, Sequent, DigiCash, Agorics, and Entegrity Solutions, in the systems software, Internet commerce, and enterprise security areas.

Spam-defiant e-mail address: szabo AT best DOT com.

Notes 1. The author has been refining this idea since the early 1990's. A variety of earlier articles on this topic can be found here.

2. George H. Bodnar and William S. Hopwood, 1987.Accounting Information Systems. 3rd ed. Boston: Allyn and Bacon.

3. Phyllis K. Sokol, 1995. From EDI to Electronic Commerce: a business initiative. New York: McGraw-Hill.

4. Oliver Hart, 1989. "Incomplete Contracts," In: John Eatwell, Murray Milgate, and Peter Newman (eds.), The New Palgrave: Allocation, Information, and Markets. New York: Norton.

5. John Bouvier, 1856. A Law Dictionary: Adapted to the Constitution and Laws of the United States of American and of the Several States of the American Union. Rev. 6th ed.

6. Michael Polanyi, Personal knowledge: Towards a post-critical philosophy. Chicago: University of Chicago Press.

7. The economics of distributed knowledge is studied by the Austrian school; in particular see Friedrich Hayek, "On the Use of Knowledge in Society."

8. Vernon V. Palmer, 1992. The Paths to Privity: The History of Third-Party Beneficiary Contracts at English Law. San Francisco: Austin and Winfield.

9. Bruce Schneier,1996. Applied Cryptography. 2nd ed. New York: Wiley.

10. Lance Cotrell, 1995. "Mixmaster & Remailer Attacks."

11. Brad Cox, 1995. Superdistribution:: Objects as Property on the Electronic Frontier. Reading, Mass.: Addison-Wesley.

12. Ian Goldberg and David Wagner, 1997. "Enabling Anonymous Publishing on the World Wide Web."

13. Olin Silbert, David Bernstein, and David Van Wie, 1996. "Securing the Content, Not the Wire for Information Commerce."

14. Joseph M. Reagle Jr., 1996. "Trust in Electronic Markets," First Monday, Volume 2, number 2 (August). http://dx.doi.org/10.5210%2Ffm.v1i2.475

15. Robin Hanson, personal communication. 16. Wei Dai, personal communication.

17. Peter Swire, 1997. "The Uses and Limits of Financial Cryptography: A Law Professor's Perspective."

18. Tim May, 1994. "The Cyphernomicon."

19. Wei Dai and Hal Finney, 1997. "Anonymous Credit" posts.

20. Mark Miller, 1997. "The Future of Law," paper delivered at the Extro 3 Conference (August 9).

Smart Contracts: Formalizing and Securing Relationships on Public Networks By NICK SZABO. First Monday, Volume 2, Number 9 - 1 September 1997 http://ojphi.org/ojs/index.php/fm/rt/printerFriendly/548 /469 ethereum / wiki

White Paper dongsamb edited this page on Sep 17 · 92 revisions

A Next-Generation Smart Contract and Decentralized Application Platform Pages 156

Satoshi Nakamoto's development of Bitcoin in 2008[1a][1b]–2009[1c][1d] has often been hailed as a radical development in money and currency, being the first example of a digital asset which Basics simultaneously has no backing or intrinsic value[2] and no centralized issuer or controller. However, another, arguably more important, part of the Bitcoin experiment is the underlying blockchain Home technology as a tool of distributed consensus, and attention is rapidly starting to shift to this other Ethereum Whitepaper aspect of Bitcoin. Commonly cited alternative applications of blockchain technology include using Design Rationale on-blockchain digital assets to represent custom currencies and financial instruments (colored Ethereum Yellow Paper FAQ coins),[3] the ownership of an underlying physical device (smart property),[4] non-fungible assets such as domain names (Namecoin),[5] as well as more complex applications involving having digital Ethereum Clients assets being directly controlled by a piece of code implementing arbitrary rules known as smart contracts[6] or even blockchain-based decentralized autonomous organizations (DAOs).[7] What cpp-ethereum (C++) Ethereum intends to provide is a blockchain with a built-in fully fledged Turing-complete ethereumj (Java) programming language that can be used to create "contracts" that can be used to encode arbitrary Geth (Go) Parity (Rust) state transition functions, allowing users to create any of the systems described above, as well as pyethapp (Python) many others that we have not yet imagined, simply by writing up the logic in a few lines of code.

ÐApp Development Table of Contents Safety Introduction to Bitcoin and Existing Concepts ÐApp Developer Resources History JavaScript API Bitcoin As A State Transition System JSON RPC API Solidity Mining Solidity Features Merkle Trees Solidity Collections Alternative Blockchain Applications Useful Ðapp Patterns Standardized Contract APIs Scripting ÐApp using Meteor Ethereum Ethereum development tutorial Ethereum Accounts Mix Tutorial Messages and Transactions Mix Features Ethereum State Transition Function Viper Serpent Code Execution LLL Blockchain and Mining Mutan Applications Token Systems Infrastructure

Financial derivatives Chain Spec Format Identity and Reputation Systems Inter-exchange Client Address Protocol Decentralized File Storage URL Hint Protocol Decentralized Autonomous Organizations NatSpec Determination Further Applications Network Status Miscellanea And Concerns Raspberry Pi Exchange Integration Modified GHOST Implementation Mining Fees Licensing Computation And Turing-Completeness Consortium Chain Currency And Issuance Development Mining Centralization Research

Scalability Proof of Stake FAQ Conclusion Sharding FAQ Notes, References and Further Reading ÐΞV Technologies Introduction to Bitcoin and Existing Concepts RLP Encoding Node Discovery Protocol ÐΞVp2p Wire Protocol History ÐΞVp2p Whitepaper (WiP) Web3 Secret Storage The concept of decentralized digital currency, as well as alternative applications like property registries, has been around for decades. The anonymous e-cash protocols of the 1980s and the Ethereum Technologies 1990s were mostly reliant on a cryptographic primitive known as Chaumian Blinding.[8] Chaumian Patricia Tree Blinding provided these new currencies with high degrees of privacy, but their underlying protocols Wire protocol largely failed to gain traction because of their reliance on a centralized intermediary. In 1998, Wei Light client protocol Dai's b-money[9] became the first proposal to introduce the idea of creating money through Subtleties solving computational puzzles as well as decentralized consensus, but the proposal was scant on Solidity Documentation details as to how decentralized consensus could actually be implemented. In 2005, Hal Finney NatSpec Format [10] introduced a concept of reusable proofs of work, a system which uses ideas from b-money Contract ABI [11] together with Adam Back's computationally difficult Hashcash puzzles to create a concept for a Bad Block Reporting cryptocurrency, but once again fell short of the ideal by relying on trusted computing as a Bad Chain Canary backend. In 2009, a decentralized currency was for the first time implemented in practice by Satoshi Nakamoto,[1c][1d] combining established primitives for managing ownership through public Ethash/Dashimoto key cryptography with a consensus algorithm for keeping track of who owns coins, known as Ethash "proof of work." Ethash C API Ethash DAG The mechanism behind proof of work was a breakthrough because it simultaneously solved two problems. First, it provided a simple and moderately effective consensus algorithm, allowing nodes Whisper in the network to collectively agree on a set of updates to the state of the Bitcoin ledger. Second, it Whisper Proposal provided a mechanism for allowing free entry into the consensus process, solving the political Whisper Overview problem of deciding who gets to influence the consensus, while simultaneously preventing Sybil PoC-1 Wire protocol attacks.[12] It does this by substituting a formal barrier to participation, such as the requirement to PoC-2 Wire protocol be registered as a unique entity on a particular list, with an economic barrier - the weight of a PoC-2 Whitepaper single node in the consensus voting process is directly proportional to the computing power that the node brings. Since then, an alternative approach has been proposed called proof of stake, Misc calculating the weight of a node as being proportional to its currency holdings and not its Hard Problems of computational resources. The discussion concerning the relative merits of the two approaches is Cryptocurrency beyond the scope of this paper but it should be noted that both approaches can be used to serve Chain Fibers as the backbone of a cryptocurrency. Glossary

Bitcoin As A State Transition System Clone this wiki locally

https://github.com/ethereum

Clone in Desktop From a technical standpoint, the ledger of a cryptocurrency such as Bitcoin can be thought of as a state transition system, where there is a "state" consisting of the ownership status of all existing bitcoins and a "state transition function" that takes a state and a transaction and outputs a new state which is the result. In a standard banking system, for example, the state is a balance sheet, a transaction is a request to move $X from A to B, and the state transition function reduces the value of A's account by $X and increases the value of B's account by $X. If A's account has less than $X in the first place, the state transition function returns an error. Hence, one can formally define:

APPLY(S,TX) -> S' or ERROR

In the banking system defined above:

APPLY({ Alice: $50, Bob: $50 },"send $20 from Alice to Bob") = { Alice: $30, Bob: $70 }

But:

APPLY({ Alice: $50, Bob: $50 },"send $70 from Alice to Bob") = ERROR

The "state" in Bitcoin is the collection of all coins (technically, "unspent transaction outputs" or UTXO) that have been mined and not yet spent, with each UTXO having a denomination and an owner (defined by a 20-byte address which is essentially a cryptographic public key[Note 1]). A transaction contains one or more inputs, with each input containing a reference to an existing UTXO and a cryptographic signature produced by the private key associated with the owner's address, and one or more outputs, with each output containing a new UTXO for addition to the state.

The state transition function APPLY(S,TX) -> S' can be defined roughly as follows:

1. For each input in TX : If the referenced UTXO is not in S , return an error. If the provided signature does not match the owner of the UTXO, return an error. 2. If the sum of the denominations of all input UTXO is less than the sum of the denominations of all output UTXO, return an error. 3. Return S' with all input UTXO removed and all output UTXO added.

The first half of the first step prevents transaction senders from spending coins that do not exist, the second half of the first step prevents transaction senders from spending other people's coins, and the second step enforces conservation of value. In order to use this for payment, the protocol is as follows. Suppose Alice wants to send 11.7 BTC to Bob. First, Alice will look for a set of available UTXO that she owns that totals up to at least 11.7 BTC. Realistically, Alice will not be able to get exactly 11.7 BTC; say that the smallest she can get is 6+4+2=12. She then creates a transaction with those three inputs and two outputs. The first output will be 11.7 BTC with Bob's address as its owner, and the second output will be the remaining 0.3 BTC "change". If Alice does not claim this change by sending it to an address owned by herself, the miner will be able to claim it.

Mining If we had access to a trustworthy centralized service, this system would be trivial to implement; it could be coded exactly as described, using a centralized server's hard drive to keep track of the state. However, with Bitcoin we are trying to build a decentralized currency system, so we will need to combine the state transition system with a consensus system in order to ensure that everyone agrees on the order of transactions. Bitcoin's decentralized consensus process requires nodes in the network to continuously attempt to produce packages of transactions called "blocks". The network is intended to create one block approximately every ten minutes, with each block containing a timestamp, a nonce, a reference to (i.e., hash of) the previous block and a list of all of the transactions that have taken place since the previous block. Over time, this creates a persistent, ever-growing, "blockchain" that continually updates to represent the latest state of the Bitcoin ledger.

The algorithm for checking if a block is valid, expressed in this paradigm, is as follows:

1. Check if the previous block referenced by the block exists and is valid. 2. Check that the timestamp of the block is greater than that of the previous block[Note 2] and less than 2 hours into the future 3. Check that the proof of work on the block is valid. 4. Let S[0] be the state at the end of the previous block. 5. Suppose TX is the block's transaction list with n transactions. For all i in 0...n-1 , set S[i+1] = APPLY(S[i],TX[i]) If any application returns an error, exit and return false. 6. Return true, and register S[n] as the state at the end of this block.

Essentially, each transaction in the block must provide a valid state transition from what was the canonical state before the transaction was executed to some new state. Note that the state is not encoded in the block in any way; it is purely an abstraction to be remembered by the validating node and can only be (securely) computed for any block by starting from the genesis state and sequentially applying every transaction in every block. Additionally, note that the order in which the miner includes transactions into the block matters; if there are two transactions A and B in a block such that B spends a UTXO created by A, then the block will be valid if A comes before B but not otherwise.

The one validity condition present in the above list that is not found in other systems is the requirement for "proof of work". The precise condition is that the double-SHA256 hash[13] of every block, treated as a 256-bit number, must be less than a dynamically adjusted target, which as of the time of this writing is approximately 2187. The purpose of this is to make block creation computationally "hard", thereby preventing Sybil attackers[12] from remaking the entire blockchain in their favor. Because SHA256 is designed to be a completely unpredictable pseudorandom function, the only way to create a valid block is simply trial and error, repeatedly incrementing the nonce and seeing if the new hash matches. At the time of writing, for a target of ~2187, the network must make an average of ~269 tries before a valid block is found; in general, the target is recalibrated by the network every 2016 blocks so that on average a new block is produced by some node in the network every ten minutes. In order to compensate miners for this computational work, the miner of every block is entitled to include a transaction giving themselves 12.5 BTC out of nowhere. Additionally, if any transaction has a higher total denomination in its inputs than in its outputs, the difference also goes to the miner as a "transaction fee". Incidentally, this is also the only mechanism by which BTC are issued; the genesis state contained no coins at all.

In order to better understand the purpose of mining, let us examine what happens in the event of a malicious attacker. Since Bitcoin's underlying cryptography is known to be secure, the attacker will target the one part of the Bitcoin system that is not protected by cryptography directly: the order of transactions. The attacker's strategy is simple:

1. Send 100 BTC to a merchant in exchange for some product (preferably a rapid-delivery digital good). 2. Wait for the delivery of the product. 3. Produce another transaction sending the same 100 BTC to himself. 4. Try to convince the network that his transaction to himself was the one that came first.

Once step (1) has taken place, after a few minutes some miner will include the transaction in a block, say block number 270,000. After about one hour, five more blocks will have been added to the chain after that block, with each of those blocks indirectly pointing to the transaction and thus "confirming" it. At this point, the merchant will accept the payment as finalized and deliver the product; since we are assuming this is a digital good, delivery is instant. Now, the attacker creates another transaction sending the 100 BTC to himself. If the attacker simply releases it into the wild, the transaction will not be processed; miners will attempt to run APPLY(S,TX) and notice that TX consumes a UTXO which is no longer in the state. So instead, the attacker creates a "fork" of the bitcoin blockchain, starting by mining another version of block 270,000 pointing to the same block 269,999 as a parent but with the new transaction in place of the old one. Because the block data is different, this requires redoing the proof of work for the concerned block. Furthermore, the attacker's new version of block 270,000 has a different hash, so the original blocks 270,001 to 270,005 do not "point" to it; thus, the original chain and the attacker's new chain are completely separate. The rule is that in a fork the longest blockchain is taken to be the truth, and so legitimate miners will work on the 270005 chain while the attacker alone is working on the 270,000 chain. In order for the attacker to make his blockchain the longest, he would need to have more computational power than the rest of the network combined in order to catch up (hence, "51% attack"). Bitcoin blocks depend on the hash of all previous blocks. An attacker with immense computing power can redo the proof of work (PoW) for a considerate amount of blocks and can eventually gain a lot of bitcoins but as described in Satoshi's paper,[1a] the reward to mine a valid block is much more than to disrupt the network. But in light of falling mining rewards the same does not hold true.

Merkle Trees 01: it suffices to present only a small number of nodes in a Merkle tree to give a proof of the validity of a branch. 02: any attempt to change any part of the Merkle tree will eventually lead to an inconsistency somewhere up the chain.

An important scalability feature of Bitcoin is that the block is stored in a multi-level data structure. The "hash" of a block is actually only the hash of the block header, a roughly 200-byte piece of data that contains the timestamp, nonce, previous block hash and the root hash of a data structure called the Merkle tree storing all transactions in the block. A Merkle tree is a type of binary tree, composed of a set of nodes with a large number of leaf nodes at the bottom of the tree containing the underlying data, a set of intermediate nodes where each node is the hash of its two children, and finally a single root node, also formed from the hash of its two children, representing the "top" of the tree. The purpose of the Merkle tree is to allow the data in a block to be delivered piecemeal: a node can download only the header of a block from one source, the small part of the tree relevant to them from another source, and still be assured that all of the data is correct. The reason why this works is that hashes propagate upward: if a malicious user attempts to swap in a fake transaction into the bottom of a Merkle tree, this change will cause a change in the node above, and then a change in the node above that, finally changing the root of the tree and therefore the hash of the block, causing the protocol to register it as a completely different block (almost certainly with an invalid proof of work). The Merkle tree protocol is arguably essential to long-term sustainability. A "full node" in the Bitcoin network, one that stores and processes the entirety of every block, takes up about 15 GB of disk space in the Bitcoin network as of April 2014, and is growing by over a gigabyte per month. Currently, this is viable for some desktop computers and not phones, and later on in the future only businesses and hobbyists will be able to participate. A protocol known as "simplified payment verification" (SPV) allows for another class of nodes to exist, called "light nodes", which download the block headers, verify the proof of work on the block headers, and then download only the "branches" associated with transactions that are relevant to them. This allows light nodes to determine with a strong guarantee of security what the status of any Bitcoin transaction, and their current balance, is while downloading only a very small portion of the entire blockchain.

Alternative Blockchain Applications

The idea of taking the underlying blockchain idea and applying it to other concepts also has a long history. In 2005, Nick Szabo came out with the concept of secure property titles with owner authority,[14] a document describing how "new advances in replicated database technology" will allow for a blockchain-based system for storing a registry of who owns what land, creating an elaborate framework including concepts such as homesteading, adverse possession and Georgian land tax. However, there was unfortunately no effective replicated database system available at the time, and so the protocol was never implemented in practice. After 2009, however, once Bitcoin's decentralized consensus was developed a number of alternative applications rapidly began to emerge.

Namecoin - created in 2010, Namecoin[5] is best described as a decentralized name registration database. In decentralized protocols like Tor, Bitcoin and BitMessage, there needs to be some way of identifying accounts so that other people can interact with them, but in all existing solutions the only kind of identifier available is a pseudorandom hash like 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy . Ideally, one would like to be able to have an account with a name like "george". However, the problem is that if one person can create an account named "george" then someone else can use the same process to register "george" for themselves as well and impersonate them. The only solution is a first-to-file paradigm, where the first registerer/registrar succeeds and the second fails - a problem perfectly suited for the Bitcoin consensus protocol. Namecoin is the oldest, and most successful, implementation of a name registration system using such an idea. Colored coins - the purpose of colored coins[3] is to serve as a protocol to allow people to create their own digital currencies - or, in the important trivial case of a currency with one unit, digital tokens, on the Bitcoin blockchain. In the colored coins protocol, one "issues" a new currency by publicly assigning a color to a specific Bitcoin UTXO, and the protocol recursively defines the color of other UTXO to be the same as the color of the inputs that the transaction creating them spent (some special rules apply in the case of mixed-color inputs). This allows users to maintain wallets containing only UTXO of a specific color and send them around much like regular bitcoins, backtracking through the blockchain to determine the color of any UTXO that they receive. Metacoins - the idea behind a metacoin is to have a protocol that lives on top of Bitcoin, using Bitcoin transactions to store metacoin transactions but having a different state transition function, APPLY' . Because the metacoin protocol cannot prevent invalid metacoin transactions from appearing in the Bitcoin blockchain, a rule is added that if APPLY'(S,TX) returns an error, the protocol defaults to APPLY'(S,TX) = S . This provides an easy mechanism for creating an arbitrary cryptocurrency protocol, potentially with advanced features that cannot be implemented inside of Bitcoin itself, but with a very low development cost since the complexities of mining and networking are already handled by the Bitcoin protocol. Metacoins have been used to implement some classes of financial contracts, name registration and decentralized exchange. Thus, in general, there are two approaches toward building a consensus protocol: building an independent network, and building a protocol on top of Bitcoin. The former approach, while reasonably successful in the case of applications like Namecoin, is difficult to implement; each individual implementation needs to bootstrap an independent blockchain, as well as building and testing all of the necessary state transition and networking code. Additionally, we predict that the set of applications for decentralized consensus technology will follow a power law distribution where the vast majority of applications would be too small to warrant their own blockchain, and we note that there exist large classes of decentralized applications, particularly decentralized autonomous organizations, that need to interact with each other.

The Bitcoin-based approach, on the other hand, has the flaw that it does not inherit the simplified payment verification features of Bitcoin. SPV works for Bitcoin because it can use blockchain depth as a proxy for validity; at some point, once the ancestors of a transaction go far enough back, it is safe to say that they were legitimately part of the state. Blockchain-based meta-protocols, on the other hand, cannot force the blockchain not to include transactions that are not valid within the context of their own protocols. Hence, a fully secure SPV meta-protocol implementation would need to backward scan all the way to the beginning of the Bitcoin blockchain to determine whether or not certain transactions are valid. Currently, all "light" implementations of Bitcoin-based meta- protocols rely on a trusted server to provide the data, arguably a highly suboptimal result especially when one of the primary purposes of a cryptocurrency is to eliminate the need for trust.

Scripting

Even without any extensions, the Bitcoin protocol actually does facilitate a weak version of a concept of "smart contracts". UTXO in Bitcoin can be owned not just by a public key, but also by a more complicated script expressed in a simple stack-based programming language. In this paradigm, a transaction spending that UTXO must provide data that satisfies the script. Indeed, even the basic public key ownership mechanism is implemented via a script: the script takes an elliptic curve signature[15] as input, verifies it against the transaction and the address that owns the UTXO, and returns 1 if the verification is successful and 0 otherwise. Other, more complicated, scripts exist for various additional use cases. For example, one can construct a script that requires signatures from two out of a given three private keys to validate ("multisig"), a setup useful for corporate accounts, secure savings accounts and some merchant escrow situations. Scripts can also be used to pay bounties for solutions to computational problems, and one can even construct a script that says something like "this Bitcoin UTXO is yours if you can provide an SPV proof that you sent a Dogecoin[16] transaction of this denomination to me", essentially allowing decentralized cross-cryptocurrency exchange.

However, the scripting language as implemented in Bitcoin has several important limitations:

Lack of Turing-completeness - that is to say, while there is a large subset of computation that the Bitcoin scripting language supports, it does not nearly support everything. The main category that is missing is loops. This is done to avoid infinite loops during transaction verification; theoretically it is a surmountable obstacle for script programmers, since any loop can be simulated by simply repeating the underlying code many times with an if statement, but it does lead to scripts that are very space-inefficient. For example, implementing an alternative elliptic curve signature algorithm[15] would likely require 256 repeated multiplication rounds all individually included in the code. Value-blindness - there is no way for a UTXO script to provide fine-grained control over the amount that can be withdrawn. For example, one powerful use case of an oracle contract would be a hedging contract, where A and B put in $1000 worth of BTC and after 30 days the script sends $1,000 worth of BTC to A and the rest to B. This would require an oracle to determine the value of 1 BTC in USD[Note 3], but even then it is a massive improvement in terms of trust and infrastructure requirement over the fully centralized solutions that are available now. However, because UTXO are all-or-nothing, the only way to achieve this is through the very inefficient hack of having many UTXO of varying denominations (eg. one UTXO of 2k for every k up to 30) and having O pick which UTXO to send to A and which to B. Lack of state - UTXO can either be spent or unspent; there is no opportunity for multi-stage contracts or scripts which keep any other internal state beyond that. This makes it hard to make multi-stage options contracts, decentralized exchange offers or two-stage cryptographic commitment protocols (necessary for secure computational bounties). It also means that UTXO can only be used to build simple, one-off contracts and not more complex "stateful" contracts such as decentralized organizations, and makes meta-protocols difficult to implement. Binary state combined with value-blindness also mean that another important application, withdrawal limits, is impossible. Blockchain-blindness - UTXO are blind to certain blockchain data such as the nonce and previous block hash. This severely limits applications in gambling, and several other categories, by depriving the scripting language of a potentially valuable source of randomness.

Thus, we see three approaches to building advanced applications on top of cryptocurrency: building a new blockchain, using scripting on top of Bitcoin, and building a meta-protocol on top of Bitcoin. Building a new blockchain allows for unlimited freedom in building a feature set, but at the cost of development time, bootstrapping effort and security. Using scripting is easy to implement and standardize, but is very limited in its capabilities, and meta-protocols, while easy, suffer from faults in scalability. With Ethereum, we intend to build an alternative framework that provides even larger gains in ease of development as well as even stronger light client properties, while at the same time allowing applications to share an economic environment and blockchain security.

Ethereum

The intent of Ethereum is to create an alternative protocol for building decentralized applications, providing a different set of tradeoffs that we believe will be very useful for a large class of decentralized applications, with particular emphasis on situations where rapid development time, security for small and rarely used applications, and the ability of different applications to very efficiently interact, are important. Ethereum does this by building what is essentially the ultimate abstract foundational layer: a blockchain with a built-in Turing-complete programming language, allowing anyone to write smart contracts and decentralized applications where they can create their own arbitrary rules for ownership, transaction formats and state transition functions. A bare- bones version of Namecoin can be written in two lines of code, and other protocols like currencies and reputation systems can be built in under twenty. Smart contracts, cryptographic "boxes" that contain value and only unlock it if certain conditions are met, can also be built on top of the platform, with vastly more power than that offered by Bitcoin scripting because of the added powers of Turing-completeness, value-awareness, blockchain-awareness and state.

Ethereum Accounts

In Ethereum, the state is made up of objects called "accounts", with each account having a 20-byte address and state transitions being direct transfers of value and information between accounts. An Ethereum account contains four fields:

The nonce, a counter used to make sure each transaction can only be processed once The account's current ether balance The account's contract code, if present The account's storage (empty by default)

"Ether" is the main internal crypto-fuel of Ethereum, and is used to pay transaction fees. In general, there are two types of accounts: externally owned accounts, controlled by private keys, and contract accounts, controlled by their contract code. An externally owned account has no code, and one can send messages from an externally owned account by creating and signing a transaction. In a contract account, every time the contract account receives a message its code activates, allowing it to read and write to internal storage and send other messages or create contracts in turn. Note that "contracts" in Ethereum should not be seen as something that should be "fulfilled" or "complied with"; rather, they are more like "autonomous agents" that live inside of the Ethereum execution environment, always executing a specific piece of code when "poked" by a message or transaction, and having direct control over their own ether balance and their own key/value store to keep track of persistent variables.

Messages and Transactions

The term "transaction" is used in Ethereum to refer to the signed data package that stores a message to be sent from an externally owned account. Transactions contain:

the recipient of the message; a signature identifying the sender; the amount of ether to transfer from the sender to the recipient; an optional data field; a STARTGAS value, representing the maximum number of computational steps the transaction execution is allowed to take; and a GASPRICE value, representing the fee the sender pays per computational step.

The first three are standard fields expected in any cryptocurrency. The data field has no function by default, but the virtual machine has an opcode with which a contract can access the data. As an example use case, if a contract is functioning as an on-blockchain domain registration service, then it may wish to interpret the data being passed to it as containing two "fields", the first field being a domain to register and the second field being the IP address to register it to. The contract would read these values from the message data and appropriately place them in storage.

The STARTGAS and GASPRICE fields are crucial for Ethereum's anti-denial-of-service model.[17] In order to prevent accidental or hostile infinite loops or other computational wastage in code, each transaction is required to set a limit to how many computational steps of code execution it can use. The fundamental unit of computation is "gas"; usually, a computational step costs 1 gas, but some operations cost higher amounts of gas because they are more computationally expensive, or increase the amount of data that must be stored as part of the state. There is also a fee of 5 gas for every byte in the transaction data. The intent of the fee system is to require an attacker to pay proportionately for every resource that they consume, including computation, bandwidth and storage; hence, any transaction that leads to the network consuming a greater amount of any of these resources must have a gas fee roughly proportional to the increment.

Messages

Contracts have the ability to send "messages" to other contracts. Messages are virtual objects that are never serialized and exist only in the Ethereum execution environment. A message contains:

the sender of the message (implicit); the recipient of the message; the amount of ether to transfer alongside the message; an optional data field; and a STARTGAS value.

Essentially, a message is like a transaction, except it is produced by a contract and not an external actor. A message is produced when a contract currently executing code executes the CALL opcode, which produces and executes a message. Like a transaction, a message leads to the recipient account running its code. Thus, contracts can have relationships with other contracts in exactly the same way that external actors can. Note that the gas allowance assigned by a transaction or contract applies to the total gas consumed by that transaction and all sub-executions. For example, if an external actor A sends a transaction to B with 1,000 gas; B consumes 600 gas before sending a message to C; and the internal execution of C consumes 300 gas before returning; then B can spend another 100 gas before running out of gas.

Ethereum State Transition Function

The Ethereum state transition function, APPLY(S,TX) -> S' can be defined as follows:

1. Check if the transaction is well-formed (ie. has the right number of values), the signature is valid, and the nonce matches the nonce in the sender's account. If not, return an error. 2. Calculate the transaction fee as STARTGAS * GASPRICE , and determine the sending address from the signature. Subtract the fee from the sender's account balance and increment the sender's nonce. If there is not enough balance to spend, return an error. 3. Initialize GAS = STARTGAS , and take off a certain quantity of gas per byte to pay for the bytes in the transaction. 4. Transfer the transaction value from the sender's account to the receiving account. If the receiving account does not yet exist, create it. If the receiving account is a contract, run the contract's code either to completion or until the execution runs out of gas. 5. If the value transfer failed because the sender did not have enough money, or the code execution ran out of gas, revert all state changes except the payment of the fees, and add the fees to the miner's account. 6. Otherwise, refund the fees for all remaining gas to the sender, and send the fees paid for gas consumed to the miner.

For example, suppose that the contract's code is:

if !self.storage[calldataload(0)]: self.storage[calldataload(0)] = calldataload(32)

Note that in reality the contract code is written in the low-level EVM code; this example is written in Serpent, one of our high-level languages, for clarity, and can be compiled down to EVM code. Suppose that the contract's storage starts off empty, and a transaction is sent with 10 ether value, 2000 gas, 0.001 ether gasprice, and 64 bytes of data, with bytes 0-31 representing the number 2 and bytes 32-63 representing the string CHARLIE .[Note 4] The process for the state transition function in this case is as follows:

1. Check that the transaction is valid and well formed. 2. Check that the transaction sender has at least 2000 * 0.001 = 2 ether. If they do, then subtract 2 ether from the sender's account. 3. Initialize gas = 2000; assuming the transaction is 170 bytes long and the byte-fee is 5, subtract 850 so that there is 1150 gas left. 4. Subtract 10 more ether from the sender's account, and add it to the contract's account. 5. Run the code. In this case, this is simple: it checks if the contract's storage at index 2 is used[Note 5], notices that it is not, and so it sets the storage at index 2 to the value CHARLIE . Suppose this takes 187 gas, so the remaining amount of gas is 1150 - 187 = 963. 6. Add 963 * 0.001 = 0.963 ether back to the sender's account, and return the resulting state.

If there was no contract at the receiving end of the transaction, then the total transaction fee would simply be equal to the provided GASPRICE multiplied by the length of the transaction in bytes, and the data sent alongside the transaction would be irrelevant.

Note that messages work equivalently to transactions in terms of reverts: if a message execution runs out of gas, then that message's execution, and all other executions triggered by that execution, revert, but parent executions do not need to revert. This means that it is "safe" for a contract to call another contract, as if A calls B with G gas then A's execution is guaranteed to lose at most G gas. Finally, note that there is an opcode, CREATE , that creates a contract; its execution mechanics are generally similar to CALL , with the exception that the output of the execution determines the code of a newly created contract.

Code Execution

The code in Ethereum contracts is written in a low-level, stack-based bytecode language, referred to as "Ethereum virtual machine code" or "EVM code". The code consists of a series of bytes, where each byte represents an operation. In general, code execution is an infinite loop that consists of repeatedly carrying out the operation at the current program counter (which begins at zero) and then incrementing the program counter by one, until the end of the code is reached or an error or STOP or RETURN instruction is detected. The operations have access to three types of space in which to store data:

The stack, a last-in-first-out container to which values can be pushed and popped Memory, an infinitely expandable byte array The contract's long-term storage, a key/value store. Unlike stack and memory, which reset after computation ends, storage persists for the long term.

The code can also access the value, sender and data of the incoming message, as well as block header data, and the code can also return a byte array of data as an output.

The formal execution model of EVM code is surprisingly simple. While the Ethereum virtual machine is running, its full computational state can be defined by the tuple (block_state, transaction, message, code, memory, stack, pc, gas) , where block_state is the global state containing all accounts and includes balances and storage. At the start of every round of execution, the current instruction is found by taking the pc th (Program Counter) byte of code (or 0 if pc >= len(code) ), and each instruction has its own definition in terms of how it affects the tuple. For example, ADD pops two items off the stack and pushes their sum, reduces gas by 1 and increments pc by 1, and SSTORE pops the top two items off the stack and inserts the second item into the contract's storage at the index specified by the first item. Although there are many ways to optimize Ethereum virtual machine execution via just-in-time compilation, a basic implementation of Ethereum can be done in a few hundred lines of code.

Blockchain and Mining The Ethereum blockchain is in many ways similar to the Bitcoin blockchain, although it does have some differences. The main difference between Ethereum and Bitcoin with regard to the blockchain architecture is that, unlike Bitcoin, Ethereum blocks contain a copy of both the transaction list and the most recent state. Aside from that, two other values, the block number and the difficulty, are also stored in the block. The basic block validation algorithm in Ethereum is as follows:

1. Check if the previous block referenced exists and is valid. 2. Check that the timestamp of the block is greater than that of the referenced previous block and less than 15 minutes into the future 3. Check that the block number, difficulty, transaction root, uncle root and gas limit (various low- level Ethereum-specific concepts) are valid. 4. Check that the proof of work on the block is valid. 5. Let S[0] be the state at the end of the previous block. 6. Let TX be the block's transaction list, with n transactions. For all i in 0...n-1 , set S[i+1] = APPLY(S[i],TX[i]) . If any application returns an error, or if the total gas consumed in the block up until this point exceeds the GASLIMIT , return an error. 7. Let S_FINAL be S[n] , but adding the block reward paid to the miner. 8. Check if the Merkle tree root of the state S_FINAL is equal to the final state root provided in the block header. If it is, the block is valid; otherwise, it is not valid.

The approach may seem highly inefficient at first glance, because it needs to store the entire state with each block, but in reality efficiency should be comparable to that of Bitcoin. The reason is that the state is stored in the tree structure, and after every block only a small part of the tree needs to be changed. Thus, in general, between two adjacent blocks the vast majority of the tree should be the same, and therefore the data can be stored once and referenced twice using pointers (ie. hashes of subtrees). A special kind of tree known as a "Patricia tree" is used to accomplish this, including a modification to the Merkle tree concept that allows for nodes to be inserted and deleted, and not just changed, efficiently. Additionally, because all of the state information is part of the last block, there is no need to store the entire blockchain history - a strategy which, if it could be applied to Bitcoin, can be calculated to provide 5-20x savings in space.

A commonly asked question is "where" contract code is executed, in terms of physical hardware. This has a simple answer: the process of executing contract code is part of the definition of the state transition function, which is part of the block validation algorithm, so if a transaction is added into block B the code execution spawned by that transaction will be executed by all nodes, now and in the future, that download and validate block B .

Applications

In general, there are three types of applications on top of Ethereum. The first category is financial applications, providing users with more powerful ways of managing and entering into contracts using their money. This includes sub-currencies, financial derivatives, hedging contracts, savings wallets, wills, and ultimately even some classes of full-scale employment contracts. The second category is semi-financial applications, where money is involved but there is also a heavy non- monetary side to what is being done; a perfect example is self-enforcing bounties for solutions to computational problems. Finally, there are applications such as online voting and decentralized governance that are not financial at all. Token Systems

On-blockchain token systems have many applications ranging from sub-currencies representing assets such as USD or gold to company stocks, individual tokens representing smart property, secure unforgeable coupons, and even token systems with no ties to conventional value at all, used as point systems for incentivization. Token systems are surprisingly easy to implement in Ethereum. The key point to understand is that a currency, or token system, is just a database with one operation: subtract X units from A and give X units to B, with the proviso that (i) A had at least X units before the transaction and (ii) the transaction is approved by A. All that it takes to implement a token system is to implement this logic into a contract.

The basic code for implementing a token system in Serpent looks as follows:

def send(to, value): if self.storage[msg.sender] >= value: self.storage[msg.sender] = self.storage[msg.sender] - value self.storage[to] = self.storage[to] + value

This is essentially a literal implementation of the "banking system" state transition function described further above in this document. A few extra lines of code need to be added to provide for the initial step of distributing the currency units in the first place and a few other edge cases, and ideally a function would be added to let other contracts query for the balance of an address. But that's all there is to it. Theoretically, Ethereum-based token systems acting as sub-currencies can potentially include another important feature that on-chain Bitcoin-based meta-currencies lack: the ability to pay transaction fees directly in that currency. The way this would be implemented is that the contract would maintain an ether balance with which it would refund ether used to pay fees to the sender, and it would refill this balance by collecting the internal currency units that it takes in fees and reselling them in a constant running auction. Users would thus need to "activate" their accounts with ether, but once the ether is there it would be reusable because the contract would refund it each time.

Financial derivatives and Stable-Value Currencies

Financial derivatives are the most common application of a "smart contract", and one of the simplest to implement in code. The main challenge in implementing financial contracts is that the majority of them require reference to an external price ticker; for example, a very desirable application is a smart contract that hedges against the volatility of ether (or another cryptocurrency) with respect to the US dollar, but doing this requires the contract to know what the value of ETH/USD is. The simplest way to do this is through a "data feed" contract maintained by a specific party (eg. NASDAQ) designed so that that party has the ability to update the contract as needed, and providing an interface that allows other contracts to send a message to that contract and get back a response that provides the price.

Given that critical ingredient, the hedging contract would look as follows:

1. Wait for party A to input 1000 ether. 2. Wait for party B to input 1000 ether. 3. Record the USD value of 1000 ether, calculated by querying the data feed contract, in storage, say this is $x. 4. After 30 days, allow A or B to "reactivate" the contract in order to send $x worth of ether (calculated by querying the data feed contract again to get the new price) to A and the rest to B. Such a contract would have significant potential in crypto-commerce. One of the main problems cited about cryptocurrency is the fact that it's volatile; although many users and merchants may want the security and convenience of dealing with cryptographic assets, they may not wish to face that prospect of losing 23% of the value of their funds in a single day. Up until now, the most commonly proposed solution has been issuer-backed assets; the idea is that an issuer creates a sub-currency in which they have the right to issue and revoke units, and provide one unit of the currency to anyone who provides them (offline) with one unit of a specified underlying asset (eg. gold, USD). The issuer then promises to provide one unit of the underlying asset to anyone who sends back one unit of the crypto-asset. This mechanism allows any non-cryptographic asset to be "uplifted" into a cryptographic asset, provided that the issuer can be trusted.

In practice, however, issuers are not always trustworthy, and in some cases the banking infrastructure is too weak, or too hostile, for such services to exist. Financial derivatives provide an alternative. Here, instead of a single issuer providing the funds to back up an asset, a decentralized market of speculators, betting that the price of a cryptographic reference asset (eg. ETH) will go up, plays that role. Unlike issuers, speculators have no option to default on their side of the bargain because the hedging contract holds their funds in escrow. Note that this approach is not fully decentralized, because a trusted source is still needed to provide the price ticker, although arguably even still this is a massive improvement in terms of reducing infrastructure requirements (unlike being an issuer, issuing a price feed requires no licenses and can likely be categorized as free speech) and reducing the potential for fraud.

Identity and Reputation Systems

The earliest alternative cryptocurrency of all, Namecoin, attempted to use a Bitcoin-like blockchain to provide a name registration system, where users can register their names in a public database alongside other data. The major cited use case is for a DNS system, mapping domain names like "bitcoin.org" (or, in Namecoin's case, "bitcoin.bit") to an IP address. Other use cases include email authentication and potentially more advanced reputation systems. Here is the basic contract to provide a Namecoin-like name registration system on Ethereum:

def register(name, value): if !self.storage[name]: self.storage[name] = value

The contract is very simple; all it is is a database inside the Ethereum network that can be added to, but not modified or removed from. Anyone can register a name with some value, and that registration then sticks forever. A more sophisticated name registration contract will also have a "function clause" allowing other contracts to query it, as well as a mechanism for the "owner" (ie. the first registerer) of a name to change the data or transfer ownership. One can even add reputation and web-of-trust functionality on top.

Decentralized File Storage

Over the past few years, there have emerged a number of popular online file storage startups, the most prominent being Dropbox, seeking to allow users to upload a backup of their hard drive and have the service store the backup and allow the user to access it in exchange for a monthly fee. However, at this point the file storage market is at times relatively inefficient; a cursory look at various existing solutions shows that, particularly at the "uncanny valley" 20-200 GB level at which neither free quotas nor enterprise-level discounts kick in, monthly prices for mainstream file storage costs are such that you are paying for more than the cost of the entire hard drive in a single month. Ethereum contracts can allow for the development of a decentralized file storage ecosystem, where individual users can earn small quantities of money by renting out their own hard drives and unused space can be used to further drive down the costs of file storage. The key underpinning piece of such a device would be what we have termed the "decentralized Dropbox contract". This contract works as follows. First, one splits the desired data up into blocks, encrypting each block for privacy, and builds a Merkle tree out of it. One then makes a contract with the rule that, every N blocks, the contract would pick a random index in the Merkle tree (using the previous block hash, accessible from contract code, as a source of randomness), and give X ether to the first entity to supply a transaction with a simplified payment verification-like proof of ownership of the block at that particular index in the tree. When a user wants to re-download their file, they can use a micropayment channel protocol (eg. pay 1 szabo per 32 kilobytes) to recover the file; the most fee-efficient approach is for the payer not to publish the transaction until the end, instead replacing the transaction with a slightly more lucrative one with the same nonce after every 32 kilobytes.

An important feature of the protocol is that, although it may seem like one is trusting many random nodes not to decide to forget the file, one can reduce that risk down to near-zero by splitting the file into many pieces via secret sharing, and watching the contracts to see if each piece is still in some node's possession. If a contract is still paying out money, that provides a cryptographic proof that someone out there is still storing the file.

Decentralized Autonomous Organizations

The general concept of a "decentralized autonomous organization" is that of a virtual entity that has a certain set of members or shareholders which, perhaps with a 67% majority, have the right to spend the entity's funds and modify its code. The members would collectively decide on how the organization should allocate its funds. Methods for allocating a DAO's funds could range from bounties, salaries to even more exotic mechanisms such as an internal currency to reward work. This essentially replicates the legal trappings of a traditional company or nonprofit but using only cryptographic blockchain technology for enforcement. So far much of the talk around DAOs has been around the "capitalist" model of a "decentralized autonomous corporation" (DAC) with dividend-receiving shareholders and tradable shares; an alternative, perhaps described as a "decentralized autonomous community", would have all members have an equal share in the decision making and require 67% of existing members to agree to add or remove a member. The requirement that one person can only have one membership would then need to be enforced collectively by the group.

A general outline for how to code a DAO is as follows. The simplest design is simply a piece of self- modifying code that changes if two thirds of members agree on a change. Although code is theoretically immutable, one can easily get around this and have de-facto mutability by having chunks of the code in separate contracts, and having the address of which contracts to call stored in the modifiable storage. In a simple implementation of such a DAO contract, there would be three transaction types, distinguished by the data provided in the transaction:

[0,i,K,V] to register a proposal with index i to change the address at storage index K to value V [1,i] to register a vote in favor of proposal i [2,i] to finalize proposal i if enough votes have been made

The contract would then have clauses for each of these. It would maintain a record of all open storage changes, along with a list of who voted for them. It would also have a list of all members. When any storage change gets to two thirds of members voting for it, a finalizing transaction could execute the change. A more sophisticated skeleton would also have built-in voting ability for features like sending a transaction, adding members and removing members, and may even provide for Liquid Democracy-style vote delegation (ie. anyone can assign someone to vote for them, and assignment is transitive so if A assigns B and B assigns C then C determines A's vote). This design would allow the DAO to grow organically as a decentralized community, allowing people to eventually delegate the task of filtering out who is a member to specialists, although unlike in the "current system" specialists can easily pop in and out of existence over time as individual community members change their alignments. An alternative model is for a decentralized corporation, where any account can have zero or more shares, and two thirds of the shares are required to make a decision. A complete skeleton would involve asset management functionality, the ability to make an offer to buy or sell shares, and the ability to accept offers (preferably with an order-matching mechanism inside the contract). Delegation would also exist Liquid Democracy-style, generalizing the concept of a "board of directors".

Further Applications

1. Savings wallets. Suppose that Alice wants to keep her funds safe, but is worried that she will lose or someone will hack her private key. She puts ether into a contract with Bob, a bank, as follows:

Alice alone can withdraw a maximum of 1% of the funds per day. Bob alone can withdraw a maximum of 1% of the funds per day, but Alice has the ability to make a transaction with her key shutting off this ability. Alice and Bob together can withdraw anything.

Normally, 1% per day is enough for Alice, and if Alice wants to withdraw more she can contact Bob for help. If Alice's key gets hacked, she runs to Bob to move the funds to a new contract. If she loses her key, Bob will get the funds out eventually. If Bob turns out to be malicious, then she can turn off his ability to withdraw.

2. Crop insurance. One can easily make a financial derivatives contract but using a data feed of the weather instead of any price index. If a farmer in Iowa purchases a derivative that pays out inversely based on the precipitation in Iowa, then if there is a drought, the farmer will automatically receive money and if there is enough rain the farmer will be happy because their crops would do well. This can be expanded to natural disaster insurance generally.

3. A decentralized data feed. For financial contracts for difference, it may actually be possible to decentralize the data feed via a protocol called "SchellingCoin". SchellingCoin basically works as follows: N parties all put into the system the value of a given datum (eg. the ETH/USD price), the values are sorted, and everyone between the 25th and 75th percentile gets one token as a reward. Everyone has the incentive to provide the answer that everyone else will provide, and the only value that a large number of players can realistically agree on is the obvious default: the truth. This creates a decentralized protocol that can theoretically provide any number of values, including the ETH/USD price, the temperature in Berlin or even the result of a particular hard computation.

4. Smart multisignature escrow. Bitcoin allows multisignature transaction contracts where, for example, three out of a given five keys can spend the funds. Ethereum allows for more granularity; for example, four out of five can spend everything, three out of five can spend up to 10% per day, and two out of five can spend up to 0.5% per day. Additionally, Ethereum multisig is asynchronous - two parties can register their signatures on the blockchain at different times and the last signature will automatically send the transaction.

5. Cloud computing. The EVM technology can also be used to create a verifiable computing environment, allowing users to ask others to carry out computations and then optionally ask for proofs that computations at certain randomly selected checkpoints were done correctly. This allows for the creation of a cloud computing market where any user can participate with their desktop, laptop or specialized server, and spot-checking together with security deposits can be used to ensure that the system is trustworthy (ie. nodes cannot profitably cheat). Although such a system may not be suitable for all tasks; tasks that require a high level of inter-process communication, for example, cannot easily be done on a large cloud of nodes. Other tasks, however, are much easier to parallelize; projects like SETI@home, folding@home and genetic algorithms can easily be implemented on top of such a platform. 6. Peer-to-peer gambling. Any number of peer-to-peer gambling protocols, such as Frank Stajano and Richard Clayton's Cyberdice, can be implemented on the Ethereum blockchain. The simplest gambling protocol is actually simply a contract for difference on the next block hash, and more advanced protocols can be built up from there, creating gambling services with near-zero fees that have no ability to cheat.

7. Prediction markets. Provided an oracle or SchellingCoin, prediction markets are also easy to implement, and prediction markets together with SchellingCoin may prove to be the first mainstream application of futarchy as a governance protocol for decentralized organizations.

8. On-chain decentralized marketplaces, using the identity and reputation system as a base.

Miscellanea And Concerns

Modified GHOST Implementation

The "Greedy Heaviest Observed Subtree" (GHOST) protocol is an innovation first introduced by Yonatan Sompolinsky and Aviv Zohar in December 2013. The motivation behind GHOST is that blockchains with fast confirmation times currently suffer from reduced security due to a high stale rate - because blocks take a certain time to propagate through the network, if miner A mines a block and then miner B happens to mine another block before miner A's block propagates to B, miner B's block will end up wasted and will not contribute to network security. Furthermore, there is a centralization issue: if miner A is a mining pool with 30% hashpower and B has 10% hashpower, A will have a risk of producing a stale block 70% of the time (since the other 30% of the time A produced the last block and so will get mining data immediately) whereas B will have a risk of producing a stale block 90% of the time. Thus, if the block interval is short enough for the stale rate to be high, A will be substantially more efficient simply by virtue of its size. With these two effects combined, blockchains which produce blocks quickly are very likely to lead to one mining pool having a large enough percentage of the network hashpower to have de facto control over the mining process.

As described by Sompolinsky and Zohar, GHOST solves the first issue of network security loss by including stale blocks in the calculation of which chain is the "longest"; that is to say, not just the parent and further ancestors of a block, but also the stale descendants of the block's ancestor (in Ethereum jargon, "uncles") are added to the calculation of which block has the largest total proof of work backing it. To solve the second issue of centralization bias, we go beyond the protocol described by Sompolinsky and Zohar, and also provide block rewards to stales: a stale block receives 87.5% of its base reward, and the nephew that includes the stale block receives the remaining 12.5%. Transaction fees, however, are not awarded to uncles.

Ethereum implements a simplified version of GHOST which only goes down seven levels. Specifically, it is defined as follows:

A block must specify a parent, and it must specify 0 or more uncles An uncle included in block B must have the following properties: It must be a direct child of the kth generation ancestor of B, where 2 <= k <= 7. It cannot be an ancestor of B An uncle must be a valid block header, but does not need to be a previously verified or even valid block An uncle must be different from all uncles included in previous blocks and all other uncles included in the same block (non-double-inclusion) For every uncle U in block B, the miner of B gets an additional 3.125% added to its coinbase reward and the miner of U gets 93.75% of a standard coinbase reward. This limited version of GHOST, with uncles includable only up to 7 generations, was used for two reasons. First, unlimited GHOST would include too many complications into the calculation of which uncles for a given block are valid. Second, unlimited GHOST with compensation as used in Ethereum removes the incentive for a miner to mine on the main chain and not the chain of a public attacker.

Fees

Because every transaction published into the blockchain imposes on the network the cost of needing to download and verify it, there is a need for some regulatory mechanism, typically involving transaction fees, to prevent abuse. The default approach, used in Bitcoin, is to have purely voluntary fees, relying on miners to act as the gatekeepers and set dynamic minimums. This approach has been received very favorably in the Bitcoin community particularly because it is "market-based", allowing supply and demand between miners and transaction senders determine the price. The problem with this line of reasoning is, however, that transaction processing is not a market; although it is intuitively attractive to construe transaction processing as a service that the miner is offering to the sender, in reality every transaction that a miner includes will need to be processed by every node in the network, so the vast majority of the cost of transaction processing is borne by third parties and not the miner that is making the decision of whether or not to include it. Hence, tragedy-of-the-commons problems are very likely to occur.

However, as it turns out this flaw in the market-based mechanism, when given a particular inaccurate simplifying assumption, magically cancels itself out. The argument is as follows. Suppose that:

1. A transaction leads to k operations, offering the reward kR to any miner that includes it where R is set by the sender and k and R are (roughly) visible to the miner beforehand. 2. An operation has a processing cost of C to any node (ie. all nodes have equal efficiency) 3. There are N mining nodes, each with exactly equal processing power (ie. 1/N of total) 4. No non-mining full nodes exist.

A miner would be willing to process a transaction if the expected reward is greater than the cost. Thus, the expected reward is kR/N since the miner has a 1/N chance of processing the next block, and the processing cost for the miner is simply kC . Hence, miners will include transactions where kR/N > kC , or R > NC . Note that R is the per-operation fee provided by the sender, and is thus a lower bound on the benefit that the sender derives from the transaction, and NC is the cost to the entire network together of processing an operation. Hence, miners have the incentive to include only those transactions for which the total utilitarian benefit exceeds the cost.

However, there are several important deviations from those assumptions in reality:

1. The miner does pay a higher cost to process the transaction than the other verifying nodes, since the extra verification time delays block propagation and thus increases the chance the block will become a stale. 2. There do exist non-mining full nodes. 3. The mining power distribution may end up radically inegalitarian in practice. 4. Speculators, political enemies and crazies whose utility function includes causing harm to the network do exist, and they can cleverly set up contracts where their cost is much lower than the cost paid by other verifying nodes.

(1) provides a tendency for the miner to include fewer transactions, and (2) increases NC ; hence, these two effects at least partially cancel each other out.Clarification needed (3) and (4) are the major issue; to solve them we simply institute a floating cap: no block can have more operations than BLK_LIMIT_FACTOR times the long-term exponential moving average. Specifically:

blk.oplimit = floor((blk.parent.oplimit * (EMA_FACTOR - 1) + floor(parent.opcount * BLK_LIMIT_FACTOR)) / EMA_FACTOR) BLK_LIMIT_FACTOR and EMA_FACTOR are constants that will be set to 65536 and 1.5 for the time being, but will likely be changed after further analysis.

There is another factor disincentivizing large block sizes in Bitcoin: blocks that are large will take longer to propagate, and thus have a higher probability of becoming stales. In Ethereum, highly gas-consuming blocks can also take longer to propagate both because they are physically larger and because they take longer to process the transaction state transitions to validate. This delay disincentive is a significant consideration in Bitcoin, but less so in Ethereum because of the GHOST protocol; hence, relying on regulated block limits provides a more stable baseline.

Computation And Turing-Completeness

An important note is that the Ethereum virtual machine is Turing-complete; this means that EVM code can encode any computation that can be conceivably carried out, including infinite loops. EVM code allows looping in two ways. First, there is a JUMP instruction that allows the program to jump back to a previous spot in the code, and a JUMPI instruction to do conditional jumping, allowing for statements like while x < 27: x = x * 2 . Second, contracts can call other contracts, potentially allowing for looping through recursion. This naturally leads to a problem: can malicious users essentially shut miners and full nodes down by forcing them to enter into an infinite loop? The issue arises because of a problem in computer science known as the halting problem: there is no way to tell, in the general case, whether or not a given program will ever halt.

As described in the state transition section, our solution works by requiring a transaction to set a maximum number of computational steps that it is allowed to take, and if execution takes longer computation is reverted but fees are still paid. Messages work in the same way. To show the motivation behind our solution, consider the following examples:

An attacker creates a contract which runs an infinite loop, and then sends a transaction activating that loop to the miner. The miner will process the transaction, running the infinite loop, and wait for it to run out of gas. Even though the execution runs out of gas and stops halfway through, the transaction is still valid and the miner still claims the fee from the attacker for each computational step. An attacker creates a very long infinite loop with the intent of forcing the miner to keep computing for such a long time that by the time computation finishes a few more blocks will have come out and it will not be possible for the miner to include the transaction to claim the fee. However, the attacker will be required to submit a value for STARTGAS limiting the number of computational steps that execution can take, so the miner will know ahead of time that the computation will take an excessively large number of steps. An attacker sees a contract with code of some form like send(A,contract.storage[A]); contract.storage[A] = 0 , and sends a transaction with just enough gas to run the first step but not the second (ie. making a withdrawal but not letting the balance go down). The contract author does not need to worry about protecting against such attacks, because if execution stops halfway through the changes get reverted. A financial contract works by taking the median of nine proprietary data feeds in order to minimize risk. An attacker takes over one of the data feeds, which is designed to be modifiable via the variable-address-call mechanism described in the section on DAOs, and converts it to run an infinite loop, thereby attempting to force any attempts to claim funds from the financial contract to run out of gas. However, the financial contract can set a gas limit on the message to prevent this problem. The alternative to Turing-completeness is Turing-incompleteness, where JUMP and JUMPI do not exist and only one copy of each contract is allowed to exist in the call stack at any given time. With this system, the fee system described and the uncertainties around the effectiveness of our solution might not be necessary, as the cost of executing a contract would be bounded above by its size. Additionally, Turing-incompleteness is not even that big a limitation; out of all the contract examples we have conceived internally, so far only one required a loop, and even that loop could be removed by making 26 repetitions of a one-line piece of code. Given the serious implications of Turing-completeness, and the limited benefit, why not simply have a Turing-incomplete language? In reality, however, Turing-incompleteness is far from a neat solution to the problem. To see why, consider the following contracts:

C0: call(C1); call(C1); C1: call(C2); call(C2); C2: call(C3); call(C3); ... C49: call(C50); call(C50); C50: (run one step of a program and record the change in storage)

Now, send a transaction to A. Thus, in 51 transactions, we have a contract that takes up 250 computational steps. Miners could try to detect such logic bombs ahead of time by maintaining a value alongside each contract specifying the maximum number of computational steps that it can take, and calculating this for contracts calling other contracts recursively, but that would require miners to forbid contracts that create other contracts (since the creation and execution of all 26 contracts above could easily be rolled into a single contract). Another problematic point is that the address field of a message is a variable, so in general it may not even be possible to tell which other contracts a given contract will call ahead of time. Hence, all in all, we have a surprising conclusion: Turing-completeness is surprisingly easy to manage, and the lack of Turing- completeness is equally surprisingly difficult to manage unless the exact same controls are in place - but in that case why not just let the protocol be Turing-complete?

Currency And Issuance

The Ethereum network includes its own built-in currency, ether, which serves the dual purpose of providing a primary liquidity layer to allow for efficient exchange between various types of digital assets and, more importantly, of providing a mechanism for paying transaction fees. For convenience and to avoid future argument (see the current mBTC/uBTC/satoshi debate in Bitcoin), the denominations will be pre-labeled:

1: wei 1012: szabo 1015: finney 1018: ether

This should be taken as an expanded version of the concept of "dollars" and "cents" or "BTC" and "satoshi". In the near future, we expect "ether" to be used for ordinary transactions, "finney" for microtransactions and "szabo" and "wei" for technical discussions around fees and protocol implementation; the remaining denominations may become useful later and should not be included in clients at this point.

The issuance model will be as follows:

Ether will be released in a currency sale at the price of 1000-2000 ether per BTC, a mechanism intended to fund the Ethereum organization and pay for development that has been used with success by other platforms such as Mastercoin and NXT. Earlier buyers will benefit from larger discounts. The BTC received from the sale will be used entirely to pay salaries and bounties to developers and invested into various for-profit and non-profit projects in the Ethereum and cryptocurrency ecosystem. 0.099x the total amount sold (60102216 ETH) will be allocated to the organization to compensate early contributors and pay ETH-denominated expenses before the genesis block. 0.099x the total amount sold will be maintained as a long-term reserve. 0.26x the total amount sold will be allocated to miners per year forever after that point.

Group At launch After 1 year After 5 years

Currency units 1.198X 1.458X 2.498X

Purchasers 83.5% 68.6% 40.0%

Reserve spent pre-sale 8.26% 6.79% 3.96%

Reserve used post-sale 8.26% 6.79% 3.96%

Miners 0% 17.8% 52.0%

Long-Term Supply Growth Rate (percent)

Despite the linear currency issuance, just like with Bitcoin over time the supply growth rate nevertheless tends to zero

The two main choices in the above model are (1) the existence and size of an endowment pool, and (2) the existence of a permanently growing linear supply, as opposed to a capped supply as in Bitcoin. The justification of the endowment pool is as follows. If the endowment pool did not exist, and the linear issuance reduced to 0.217x to provide the same inflation rate, then the total quantity of ether would be 16.5% less and so each unit would be 19.8% more valuable. Hence, in the equilibrium 19.8% more ether would be purchased in the sale, so each unit would once again be exactly as valuable as before. The organization would also then have 1.198x as much BTC, which can be considered to be split into two slices: the original BTC, and the additional 0.198x. Hence, this situation is exactly equivalent to the endowment, but with one important difference: the organization holds purely BTC, and so is not incentivized to support the value of the ether unit.

The permanent linear supply growth model reduces the risk of what some see as excessive wealth concentration in Bitcoin, and gives individuals living in present and future eras a fair chance to acquire currency units, while at the same time retaining a strong incentive to obtain and hold ether because the "supply growth rate" as a percentage still tends to zero over time. We also theorize that because coins are always lost over time due to carelessness, death, etc, and coin loss can be modeled as a percentage of the total supply per year, that the total currency supply in circulation will in fact eventually stabilize at a value equal to the annual issuance divided by the loss rate (eg. at a loss rate of 1%, once the supply reaches 26X then 0.26X will be mined and 0.26X lost every year, creating an equilibrium). Note that in the future, it is likely that Ethereum will switch to a proof-of-stake model for security, reducing the issuance requirement to somewhere between zero and 0.05X per year. In the event that the Ethereum organization loses funding or for any other reason disappears, we leave open a "social contract": anyone has the right to create a future candidate version of Ethereum, with the only condition being that the quantity of ether must be at most equal to 60102216 * (1.198 + 0.26 * n) where n is the number of years after the genesis block. Creators are free to crowd-sell or otherwise assign some or all of the difference between the PoS-driven supply expansion and the maximum allowable supply expansion to pay for development. Candidate upgrades that do not comply with the social contract may justifiably be forked into compliant versions.

Mining Centralization

The Bitcoin mining algorithm works by having miners compute SHA256 on slightly modified versions of the block header millions of times over and over again, until eventually one node comes up with a version whose hash is less than the target (currently around 2192). However, this mining algorithm is vulnerable to two forms of centralization. First, the mining ecosystem has come to be dominated by ASICs (application-specific integrated circuits), computer chips designed for, and therefore thousands of times more efficient at, the specific task of Bitcoin mining. This means that Bitcoin mining is no longer a highly decentralized and egalitarian pursuit, requiring millions of dollars of capital to effectively participate in. Second, most Bitcoin miners do not actually perform block validation locally; instead, they rely on a centralized mining pool to provide the block headers. This problem is arguably worse: as of the time of this writing, the top three mining pools indirectly control roughly 50% of processing power in the Bitcoin network, although this is mitigated by the fact that miners can switch to other mining pools if a pool or coalition attempts a 51% attack.

The current intent at Ethereum is to use a mining algorithm where miners are required to fetch random data from the state, compute some randomly selected transactions from the last N blocks in the blockchain, and return the hash of the result. This has two important benefits. First, Ethereum contracts can include any kind of computation, so an Ethereum ASIC would essentially be an ASIC for general computation - ie. a better CPU. Second, mining requires access to the entire blockchain, forcing miners to store the entire blockchain and at least be capable of verifying every transaction. This removes the need for centralized mining pools; although mining pools can still serve the legitimate role of evening out the randomness of reward distribution, this function can be served equally well by peer-to-peer pools with no central control.

This model is untested, and there may be difficulties along the way in avoiding certain clever optimizations when using contract execution as a mining algorithm. However, one notably interesting feature of this algorithm is that it allows anyone to "poison the well", by introducing a large number of contracts into the blockchain specifically designed to stymie certain ASICs. The economic incentives exist for ASIC manufacturers to use such a trick to attack each other. Thus, the solution that we are developing is ultimately an adaptive economic human solution rather than purely a technical one.

Scalability

One common concern about Ethereum is the issue of scalability. Like Bitcoin, Ethereum suffers from the flaw that every transaction needs to be processed by every node in the network. With Bitcoin, the size of the current blockchain rests at about 15 GB, growing by about 1 MB per hour. If the Bitcoin network were to process Visa's 2000 transactions per second, it would grow by 1 MB per three seconds (1 GB per hour, 8 TB per year). Ethereum is likely to suffer a similar growth pattern, worsened by the fact that there will be many applications on top of the Ethereum blockchain instead of just a currency as is the case with Bitcoin, but ameliorated by the fact that Ethereum full nodes need to store just the state instead of the entire blockchain history. The problem with such a large blockchain size is centralization risk. If the blockchain size increases to, say, 100 TB, then the likely scenario would be that only a very small number of large businesses would run full nodes, with all regular users using light SPV nodes. In such a situation, there arises the potential concern that the full nodes could band together and all agree to cheat in some profitable fashion (eg. change the block reward, give themselves BTC). Light nodes would have no way of detecting this immediately. Of course, at least one honest full node would likely exist, and after a few hours information about the fraud would trickle out through channels like Reddit, but at that point it would be too late: it would be up to the ordinary users to organize an effort to blacklist the given blocks, a massive and likely infeasible coordination problem on a similar scale as that of pulling off a successful 51% attack. In the case of Bitcoin, this is currently a problem, but there exists a blockchain modification suggested by Peter Todd which will alleviate this issue.

In the near term, Ethereum will use two additional strategies to cope with this problem. First, because of the blockchain-based mining algorithms, at least every miner will be forced to be a full node, creating a lower bound on the number of full nodes. Second and more importantly, however, we will include an intermediate state tree root in the blockchain after processing each transaction. Even if block validation is centralized, as long as one honest verifying node exists, the centralization problem can be circumvented via a verification protocol. If a miner publishes an invalid block, that block must either be badly formatted, or the state S[n] is incorrect. Since S[0] is known to be correct, there must be some first state S[i] that is incorrect where S[i-1] is correct. The verifying node would provide the index i , along with a "proof of invalidity" consisting of the subset of Patricia tree nodes needing to process APPLY(S[i-1],TX[i]) -> S[i] . Nodes would be able to use those nodes to run that part of the computation, and see that the S[i] generated does not match the S[i] provided.

Another, more sophisticated, attack would involve the malicious miners publishing incomplete blocks, so the full information does not even exist to determine whether or not blocks are valid. The solution to this is a challenge-response protocol: verification nodes issue "challenges" in the form of target transaction indices, and upon receiving a node a light node treats the block as untrusted until another node, whether the miner or another verifier, provides a subset of Patricia nodes as a proof of validity.

Conclusion

The Ethereum protocol was originally conceived as an upgraded version of a cryptocurrency, providing advanced features such as on-blockchain escrow, withdrawal limits, financial contracts, gambling markets and the like via a highly generalized programming language. The Ethereum protocol would not "support" any of the applications directly, but the existence of a Turing- complete programming language means that arbitrary contracts can theoretically be created for any transaction type or application. What is more interesting about Ethereum, however, is that the Ethereum protocol moves far beyond just currency. Protocols around decentralized file storage, decentralized computation and decentralized prediction markets, among dozens of other such concepts, have the potential to substantially increase the efficiency of the computational industry, and provide a massive boost to other peer-to-peer protocols by adding for the first time an economic layer. Finally, there is also a substantial array of applications that have nothing to do with money at all.

The concept of an arbitrary state transition function as implemented by the Ethereum protocol provides for a platform with unique potential; rather than being a closed-ended, single-purpose protocol intended for a specific array of applications in data storage, gambling or finance, Ethereum is open-ended by design, and we believe that it is extremely well-suited to serving as a foundational layer for a very large number of both financial and non-financial protocols in the years to come.

Notes, References and Further Reading Notes

1. A sophisticated reader may notice that in fact a Bitcoin address is the hash of the elliptic curve public key[15], and not the public key itself. However, it is in fact perfectly legitimate cryptographic terminology to refer to the pubkey hash as a public key itself. This is because Bitcoin's cryptography can be considered to be a custom digital signature algorithm, where the public key consists of the hash of the ECC pubkey; the signature consists of the ECC pubkey concatenated with the ECC signature; and the verification algorithm involves checking the ECC pubkey in the signature against the ECC pubkey hash provided as a public key, and then verifying the ECC signature against the ECC pubkey. 2. Technically, the median of the 11 previous blocks. 3. An oracle contract needs external information not present in the contract itself nor the blockchain. Converting USD to BTC would require an oracle, external data in a contract which in this case is used for an accurate conversion to occur at a given time—which would be be a dynamic external exchange rate between BTC and USD. 4. Internally, 2 and "CHARLIE" are both numbers, with the latter being in big-endian base 256 representation. Numbers can be at least 0 and at most 2256-1. 5. Note made on 7 July 2017 for those not familiar with arrays in programming languages: the index starts at 0, and increments by 1. So the nth item in an array has an index of n-1. So in the case in question, the item in the list with an index of 2, is the 3rd item, which has a value of 0. (To learn a programming language it is often suggested to learn Python first as it is designed to be easy to learn, read and understand. Learn Python the Hard Way is often touted as a good way for learning Python. There are many free, online platforms available (as well as paid online platforms and in person training such as university courses) for learning programming languages, including Codecademy (which provides an introduction to many programming languages), learncpp.com (which provides in-depth training of C++). C++ is a good language to learn for Ethereum's Solidity programming language, which is used to build decentralized apps.

References 1a. Nakamoto, S. 31 October 2008. "Bitcoin: A Peer-to-Peer Electronic Cash System". Also known as the Bitcoin whitepaper. http://nakamotoinstitute.org/bitcoin/. http://bitcoin.org/bitcoin.pdf. https://github.com/saivann/bitcoinwhitepaper. Accessed 7 July 2017. 1b. Davis, J. 10 October 2011. "The Crypto-Currency: Bitcoin and its mysterious inventor". The New Yorker. http://www.newyorker.com/magazine/2011/10/10/the-crypto-currency. Retrieved 31 October 2014. Accessed 7 July 2017. 2. Unknown author. Unknown date. "Intrinsic value". http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt- have-it-and-why-bitcoin-does-have-it/. Unable to access 7 July 2017. 3. Assia, Y.; Vitalik, B.; Haki, M.; Meni R.; and Rotem, L. U.d. "Colored coins whitepaper". https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuo Wu2z1BE/edit. Accessed 7 July 2017. 4. Last edited on 10 May 2016. "Smart property". Bitcoin Wiki. https://en.bitcoin.it/wiki/Smart_Property. Accessed 7 July 2017. 5. Last modified 6 July 2017. "Namecoin". https://namecoin.org/. Accessed 7 July 2017. 6. Last edited on 24 June 2017. "Smart contracts". Bitcoin Wiki. https://en.bitcoin.it/wiki/Contracts. Accessed 7 July 2017. 7. Buterin, V. Sep 19, 2013. "Bootstrapping A Decentralized Autonomous Corporation: Part I". Bitcoin Magazine. http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous- corporation-part-i. Accessed 7 July 2017. 8. "Blind signature". Last modified 29 March 2017. Wikipedia. https://en.wikipedia.org/wiki/Blind_signature. Accessed 7 July 2017. 9. Dai, W. U.d. "B-money". http://www.weidai.com/bmoney.txt. Accessed 7 July 2017. 10. Hal, F. Reusable proofs of work: http://www.finney.org/~hal/rpow/. Unable to access 7 July 2017. 11. Back, A. U.d. Hashcash. http://www.hashcash.org/. Accessed 7 July 2017. 12. Last edited on 15 June 2017. "Sybil attack". Wikipedia. https://en.wikipedia.org/wiki/Sybil_attack. Accessed 7 July 2017. 13. Last edited on 30 June 2017. "SHA-2". Wikipedia.https://en.wikipedia.org/wiki/SHA-2. Accessed 7 July 2017. 14. Szabo, N. 1998. "Secure property titles with owner authority". http://szabo.best.vwh.net/securetitle.html. Unable to access 7 July 2017. Alternative link here: http://nakamotoinstitute.org/secure-property-titles/. Accessed 7 July 2017. 15. Last edited on 27 June 2017. "Elliptic Curve Digital Signature Algorithm". Wikipedia. https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm. Accessed 7 July 2017. 16. Dogecoin. http://dogecoin.com/. Accessed 7 July 2017. 17. Last edited on 29 June 2017. "Denial-of-service attack". Wikipedia. https://en.wikipedia.org/wiki/Denial-of-service_attack. Accessed 7 July 2017.