1.7 Automation Perspective

1.7 Automation Perspective

1.7 Automation Perspective

1.7.1 Smart Contracts

Views on Smart Contracts Merit Kolvart, Margus Poola and Addi Rull define a smart contract as an autonomous agent, a programmed functionality.³¹⁸ These authors noticed that information technology (IT) professionals view smart contracts differently than lawyers, treating them as free of any jurisdiction while lawyers note that the grounds for putting contracts outside of any jurisdiction are simply not there.³¹⁹ Another definition, from Andreas Sherborne, provides that smart contracts automatically execute coded contractual terms without requiring a lawyer, a central

³⁰⁷Birgit Clark, Technology Practice, and Burstall, “Crypto-Pie in the Sky? How Blockchain Technology is Impacting Intellectual Property Law”.

³⁰⁸Ibid.

³⁰⁹Ibid.

³¹⁰Infra Section 1.7.1.

³¹¹Birgit Clark, Technology Practice, and Burstall, “Crypto-Pie in the Sky? How Blockchain Technology is Impacting Intellectual Property Law”.

³¹²Ibid.

³¹³Ibid.

³¹⁴Ibid.

³¹⁵Ibid.

³¹⁶Ibid.

³¹⁷Ibid.

³¹⁸Dariusz Szostek and Wydawnictwo C.H. Beck. Blockchain a prawo. Polish. OCLC: 1080930761. Warszawa: Wydawnictwo C. H. Beck, 2018 quoting Merit Kõlvart, Margus Poola, and Addi Rull. “Smart Contracts”. In: Feb. 2016, pp. 133”147. isbn: 978-3-319-26894-1. doi: 10.1007/978-3-319-26896-5_7

³¹⁹Szostek and Wydawnictwo C.H. Beck, Blockchain a prawo quoting Kõlvart, Poola, and Rull, “Smart Contracts”

entity, a legal system or an outside authority, thus providing clarity, predictability, control mechanism and enabling easy enforcement.³²⁰ Some authors make distinction between smart contract code and smart legal contract, the latter depending on legal, political and business institutions.”³²¹ Jacek Czarnecki defines smart contract as a legal bond that can function independently in the digital space, without the need to refer to the real world.”³²² Jake Goldenfein and Andrea Leiter define automated transactions (rather than smart contracts) as a means of exchanging value in which some dimension of the actual exchange is processed by a machine, without human intervention.”³²³ Goldenfein and Leiter point out that we are yet to see how legal systems react to the fact that transactions on the blockchain cannot be edited or deleted and how they address the need of having some kind of dispute resolution in place.³²⁴ Goldenfein and Leiter also note that [i]n many ways, [the] engineers are building the legal standards for engaging and transacting on these systems, and like many systems of standardization, their authorizing force is market dominance and several blockchain initiatives are already competing over the authority to shape the legal rules - while jurisdictions, as Werbach (quoted therein) noted, are competing for the title of the leading jurisdiction for the crypto economy.³²⁵

Clark and Burstall see two divergent views of smart contracts:

A replacement of legal agreements and practitioners with self-enforcing code; or
A supplement to legal agreements and practitioners with self-enforcing code.³²⁶

Clark and Burstall believe the first view is overly simplistic because it does not reflect real-life human and business interaction, where contractual disputes often cent[er] on the quality of contractual performance. ³²⁷ Furthermore, and discussed in more detail by Giancaspro, smart contracts work well for easily computable and objective terms (such as a small dispute or micropayments), but should not be solely relied upon in situations where there is [a] need for a subjective judgment and evidence of facts. ³²⁸ Rather, Clark and Burstall believe the second view is more appropriate because it conceptualizes smart contracts as computerised transaction protocols that execute contract terms . . . without human involvement once the underlying binding contract has been coded. ³²⁹

Technical Issues Alharby Maher and Aad van Moorsel in Blockchain Based Smart Contracts: A Systematic Mapping Study conducted a systematic mapping study of twenty-four (24) studies related to smart contracts in multiple domains to identify current research topics and open challenges for future studies in smart contract research. ³³⁰ Maher and van Moorsel’s study focused on three research questions:

“What are the current research topics on smart contracts?”;

³²⁰Szostek and Wydawnictwo C.H. Beck, Blockchain a prawo quoting Andreas Sherborne. BLOCKCHAIN, SMART CONTRACTS AND LAWYERS. tech. rep. original-date: 2017. International Bar Association, 2017, pp. 1 8. url: https://www.ibanet.org/Document/Default.aspx?DocumentUid=17badeaa-072a-403b-b63c-8fbd985d198b

³²¹Maher Alharby and Aad van Moorsel. Blockchain Based Smart Contracts : A Systematic Mapping Study . In: Aug. 2017, pp. 125 140. doi: 10.5121/csit.2017.71011.

³²²Szostek and Wydawnictwo C.H. Beck, Blockchain a prawo quoting Jacek Czarnecki. Czym s¡ inteligentne kontrakty i DAO . Polish. In: Blockchain, inteligentne kontrakty i DAO. original-date: 10-27-2016. Wardynski+Wspolncy; Koalicja Na Rzecz Polskich Innowacji. url: https://www.wardynski.com.pl/w_publication/blockchain-inteligentne-kontrakty-i-dao/; Jacek Czarnecki. Czym s¡ inteligentne kontrakty i DAO. pl-PL. Oct. 2016. url: http://blockchain.prawo.io/z-archiwum-4-czymsa-inteligentne-kontrakty-i-dao/ (visited on 12/20/2019)

³²³Jake Goldenfein and Andrea Leiter. Legal Engineering on the Blockchain: “Smart Contracts” as Legal Conduct . In: Law and Critique 29 (May 2018). doi: 10.1007/s10978-018-9224-0.

³²⁴ibid. (Arbitration courts are an already tested and internationally regulated alternative to national courts, as suggested by the Mattereum White Paper.).

³²⁵Ibid.

³²⁶Birgit Clark, Technology Practice, and Burstall, Crypto-Pie in the Sky? How Blockchain Technology is Impacting Intellectual Property Law .

³²⁷Ibid.

³²⁸Birgit Clark, Technology Practice, and Burstall, Crypto-Pie in the Sky? How Blockchain Technology is Impacting Intellectual Property Law ; Giancaspro, Is a `smart contract’ really a smart idea? Insights from a legal perspective .

³²⁹Birgit Clark, Technology Practice, and Burstall, Crypto-Pie in the Sky? How Blockchain Technology is Impacting Intellectual Property Law .

³³⁰Alharby and Moorsel, Blockchain Based Smart Contracts : A Systematic Mapping Study .

“What are the current smart contract applications?”; and
“What are the research gaps that need to be addressed in future studies?”³³¹

Maher and van Moorsel categorized the issues into four categories:

codifying issues,
security issues,
privacy issues, and
performance issues.³³²

For our research purposes, we discussed all four categories because these issues can affect any automated licensing approach that utilizes smart contracts. Maher and Van Moorsel identified the following as codifying issues:

Difficulty of writing smart contracts,
Inability to modify or terminate smart contracts,
Lack of support to identify under-optimized smart contracts, and
Complexity of programming languages.³³³

The first issue, difficulty of writing smart contracts, primarily affects whether developers can develop a smart contract that executes as intended.³³⁴ If a smart contract is difficult to write, even for those well-versed in smart contract development, the likelihood of errors and mishaps is high.³³⁵ Maher and Van Moorsel identified three potential solutions to this issue:

Semi-automate the creation of smart contracts by “translat[ing] … human-readable contract representations to smart contract rules”;
Creating smart contract guidelines for developers; and
“[F]ormal verification techniques to detect unintended behaviours of smart contracts.”³³⁶

The second issue, inability to modify or terminate smart contracts, concerns the immutability of data stored on a blockchain.³³⁷ Once a smart contract is deployed on the blockchain, its terms, i.e., the source code, cannot be modi ed or terminated without a massive undertaking such as a hard fork.³³⁸ Maher and van Moorsel identified the creation of standards for modifying or terminating smart contracts taken from traditional contract law as a potential solution to this issue.³³⁹

The third issue, lack of support to identify under-optimized smart contracts, concerns under-optimized smart contracts, which are smart contracts that contain[] unnecessary or expensive operations, (e.g., paying more in Gas fees than necessary ).³⁴⁰ Maher and van Moorsel identified that programming optimization patterns and tools thereto could be a potential solution to this issue.³⁴¹

³³¹Alharby and Moorsel, “Blockchain Based Smart Contracts : A Systematic Mapping Study”.

³³²Ibid.

³³³Ibid.

³³⁴Ibid.

³³⁵Ibid.

³³⁶Ibid.

³³⁷Ibid.

³³⁸Ibid.

³³⁹Ibid.

³⁴⁰Ibid.

³⁴¹Ibid.

The fourth issue, complexity of programming languages, concerns the type of programming language utilized for writing smart contracts.³⁴² Maher and van Moorsel discussed the difference between procedural- and logic-based programming languages.³⁴³ In procedural-based programming languages such as Solidity (smart contract language for Ethereum Virtual Machine), programmers must specify what and how things should be done because code is executed in steps.³⁴⁴ This makes the task of writing smart contracts in those languages cumbersome and error prone. ³⁴⁵ Contrastingly, in logic-based programming languages, programmers need not specify the sequence of steps in the code. However, algorithms for logic-based languages are expensive and inefficient. ³⁴⁶

Maher and van Moorsel identified the following as privacy issues:

lack of transactional privacy, and
lack of data feeds privacy.³⁴⁷

Lack of transactional privacy is an issue for smart contracts because all data is publicly accessible on a blockchain.³⁴⁸ This may deter the adoption of smart contracts in financial transactions and transactions involving confidential or private information.³⁴⁹ Lack of data feeds privacy is an issue because smart contracts that rely on external data need to “send[] a request to the party that provides those feeds.” ³⁵⁰ Because data stored on blockchains are publicly accessible, “th[ese] request[s] [are] exposed to the public . . .” ³⁵¹

Maher and van Moorsel identified the lack of trustworthy data oracles as a security issue.³⁵² Lack of trustworthy data oracles is an issue for smart contracts that rely on external data because there is no guarantee that the information provided by an external source is trustworthy. ³⁵³

Maher and van Moorsel identified sequential execution of smart contracts as a performance issue.³⁵⁴Sequential execution is a performance issue because most blockchains do not have the scalability capacity (i.e., low transactions-per-second (TPS)) to process a high volume of transactions executed via smart contracts.³⁵⁵ Thus, the more smart contracts that are executed, the slower it will take for the transactions executed via smart contract to be processed and added to the blockchain.³⁵⁶ Additionally, a high volume of transactions will lead to network fees (i.e., miner’s fees) rising, thereby making each transaction more costly.³⁵⁷

Music Licensing Proof of Concepts The first smart contract automation approach for music was performed by Ujo Music, in partnership with Imogen Heap, to release Imogen Heap’s song Tiny Human as a digital music file that worked in conjunction with a smart contract on the Ethereum blockchain.³⁵⁸ This release showed the promise of blockchain for automating music licensing because you could interact with the music file through a smart contract, and the web application showed transparent metadata because it displayed the following information to prospective purchasers:

³⁴²Alharby and Moorsel, “Blockchain Based Smart Contracts : A Systematic Mapping Study”.

³⁴³Ibid.

³⁴⁴Ibid.

³⁴⁵Ibid.

³⁴⁶Ibid.

³⁴⁷Ibid.

³⁴⁸Ibid.

³⁴⁹Ibid.

³⁵⁰Ibid.

³⁵¹Ibid.

³⁵²Ibid.

³⁵³Ibid.

³⁵⁴Ibid.

³⁵⁵Ibid.

³⁵⁶Ibid.

³⁵⁷Ibid.

³⁵⁸Imogen Heap releases a single on the Ethereum blockchain. en. url: https://futurism.com/imogen-heap-releases-on-the-ethereum-blockchain (visited on 10/18/2019); Imogen Heap’s Tiny Human. url: https://imogen2.surge.sh/#/imogen_heap/tiny_human/tiny_human (visited on 10/18/2019).

credits (the team behind the song),
stems (individual segments of the song) can be individually purchased,
lyrics,
inspiration for the song, and
licensing information (policies, distributions, and transactions).³⁵⁹

This First example has led to the rise of more Proof-of-Concepts (PoC) trying to automate music licensing via smart contracts, and an example PoC is discussed in the following paragraphs.

Andreas Fougner Engebretsen and Hallvard Kristo er Boland Haugen in their thesis, The Music Industry on Blockchain Technology, developed a PoC demonstrating music copyright registration and licensing through smart contracts on the Ethereum blockchain as a potential solution for the lack of transparency and excessive middlemen in the music industry.³⁶⁰

Engebretsen and Haugen were motivated to produce their PoC because they wanted to show that blockchain has real-world applications, and could resolve issues musicians face regarding transparency, efficiency and fairness. ³⁶¹ Engebretsen and Haugen’s two goals for the PoC were:

[i]dentify the core problems in the music industry and understand how blockchain technology can be utilized to resolve the issues ; and
[d]emonstrate that musicians and other industry players can bene t from transparent blockchain based decentralized applications. ³⁶²

Engebretsen and Haugen’s research question for their thesis was [h]ow can blockchain technology be utilized in order to solve problems related to transparency, efficiency, and fairness along the music industry value chain? ³⁶³ Engebretsen and Haugen’s research methods for the thesis were to analyze the relationships between stakeholders in the music industry to determine core problems, and then applying their PoC to remedy these core problems.³⁶⁴ For our research purposes, we only discussed Chapters 3 7 of Engebretsen and Haugen’s thesis because the background information contained in Chapter 2 is discussed in another section.³⁶⁵

Concerning the relevant properties of distributed and decentralized networks, Engebretsen and Haugen discuss the three axes of centralization:

architectural,
political, and
logical,

and highlighted three advantages of these networks:

security,
immutability, and
transparency.³⁶⁶

³⁵⁹Imogen Heap releases a single on the Ethereum blockchain; Imogen Heap’s Tiny Human.

³⁶⁰Hallvard Kristoer Boland Haugen and Andreas Fougner Engebretsen. “The Music Industry on Blockchain Technology”. eng. MA thesis. Norway: Norwegian University of Science and Technology, 2018. url: https://ntnuopen.ntnu.no/ntnu-xmlui/handle/11250/2565110 (visited on 12/17/2019).

³⁶¹Ibid.

³⁶²Ibid.

³⁶³Ibid.

³⁶⁴Ibid.

³⁶⁵Ibid.

³⁶⁶Ibid.

In Chapter 3, Engebretsen and Haugen discuss the design of their PoC, and why they chose the Ethereum blockchain as the underlying infrastructure for their PoC.³⁶⁷ Engebretsen and Haugen’s goal for the PoC was to implement a copyright database and music licensing dApp that appealed to both copyright holders and licensees.³⁶⁸ Engebretsen and Haugen chose the Ethereum blockchain for their DApp because the Ethereum blockchain has built-in security measures that mitigate against distributed denial of service (DDoS) attacks, the Ethereum blockchain’s transparency characteristic makes it a viable option for a global rights database, the use of ERC-721 tokens (i.e., Non-fungible Tokens (NFTs)) to represent copyright on the blockchain, and blockchain’s immutability ensures that any data collected through the DApp will not be altered in the future³⁶⁹ Additionally, Engebretsen and Haugen chose the Ethereum blockchain because Ethereum has a strong community and strong leadership supporting the development of the blockchain.³⁷⁰ Engebretsen and Haugen’s DApp focused on three essential use cases:

“Registering a musical work;
Creating license contracts; and
Searching for musical works and purchase licenses from a database.”371

Engebretsen and Haugen defined a musical work as an object with the following attributes:

“title”,
“type of work (song, recording, composition, lyrics, etc.)”,
“description”,
“time of registration”,
“list of all [contributors] and their respective share of ownersh[i]p”, and
“a file embodying the work itself.”³⁷²

Engebretsen and Haugen determined that the only two attributes that need to be stored on the Ethereum blockchain were the file (specifically the hash) and the list of contributors.³⁷³ Only these two attributes were needed because the file identifies the musical work, and the list of contributors identifies the royalty splits.³⁷⁴ By storing only these two attributes, Engebretsen and Haugen determined that this would help reduce Gas fees since storing data on the Ethereum blockchain is expensive.³⁷⁵

In Engebretsen and Haugen’s technical implementation of their DApp, they discuss the technical design choices and some critical code structures.³⁷⁶ Engebretsen and Haugen describe their technical implementation of their DApp, which includes the back-end logic written in a collection of smart contracts, and the front-end user interface written in Angular, a JavaScript library.³⁷⁷ Engebretsen and Haugen organized their back-end logic into the following smart contracts:

“contract WorkBase”,
“contract ERC721”,
“contract TokenOwnership is WorkBase, ERC721”

³⁶⁷Haugen and Engebretsen, The Music Industry on Blockchain Technology.

³⁶⁸Ibid.

³⁶⁹Ibid.

³⁷⁰Ibid.

³⁷¹Ibid.

³⁷²Ibid.

³⁷³Ibid.

³⁷⁴Ibid.

³⁷⁵Ibid.

³⁷⁶Ibid.

³⁷⁷Ibid.

“contract LicenseBase is TokenOwnership”, and
“contract LicensePurchase is LicenseBase.”³⁷⁸

Engebretsen and Haugen described the core smart contracts of their DApp: 1) WorkBase, 2) TokenOwnership, 3) LicenseBase, and 4) LicensePurchase, while leaving the other contracts to be understood based on in-line comments in the smart contracts.³⁷⁹ For our research purposes, we focused on the back-end of the DApp rather than the front-end because the back-end describes how music licenses can be converted into smart contracts.³⁸⁰

The WorkBase smart contract defines the core data of the DApp:

the musical work as a struct data type,
an array to act as a master database for the musical works,
a function to register a work and determine the contributors and their payment splits,
certain mappings, including a mapping “of whether a work has been approved or not,” and
a function issuing copyright tokens to contributors as proof of registration.³⁸¹

Engebretsen and Haugen de ned the copyright tokens to be distributed based on the splits determined by the contributors with one token representing ten percent (10%) ownership of a work’s overall copyright, thus only ten tokens are issued.³⁸² Engebretsen and Haugen chose to only issue ten (10) tokens to optimize the smart contract because Gas fees have a linear positive relationship with the number of tokens issued.³⁸³

The TokenOwnership smart contract defines:

an array where all tokens are stored,
a mapping to keep track of which tokens are owned by which addresses,
a function to transfer tokens from one address to another, i.e., to assign copyrights from a holder to another person, and
a token standard by inheriting the ERC-721 standard.³⁸⁴

The LicenseBase smart contract provides the code for creating and storing license profiles that can be “purchased through [the] web application.”³⁸⁵ Specifically, the LicenseBase smart contract defines the:

a struct of license profiles,
a mapping of license profiles to addresses,
an array to act as a master database for the license profiles, and
a function to register a license and add it to the array.³⁸⁶

³⁷⁸Haugen and Engebretsen, “The Music Industry on Blockchain Technology”.

³⁷⁹Ibid.

³⁸⁰Ibid.

³⁸¹Ibid.

³⁸²Ibid.

³⁸³Ibid.

³⁸⁴Ibid.

³⁸⁵Ibid.

³⁸⁶Ibid.

Additionally, Engebretsen and Haugen discussed that the LicensePurchase smart contract can hold ETH as part of transactions, and that a mapping is included so that the ETH stored in the smart contract, i.e., paid royalties, will be mapped onto the token ID, i.e., the contributors addresses.³⁸⁷ This mapping scheme was chosen to save on gas costs and to optimize the smart contracts.³⁸⁸ The withdrawFromWorkId() function determines which tokens, i.e., copyrights to a work, the sender owns (through msg.sender), calculates the aggregated token balance sum, [and sends the sum] from the smart contract account to the account of msg.sender. ³⁸⁹

In the web application, Engebretsen and Haugen specifically mention the blockchain services needed to connect the web application to the smart contracts.³⁹⁰ Engebretsen and Haugen included two blockchain services in their Angular application to handle blockchain-related services:

“web3.service.ts,” and
“ethereum.service.ts.”³⁹¹

The web3.service.ts service is mainly for establishing a Web3.js provider [to] connect [the] Angular application to the running blockchain.³⁹² That is the service where MetaMask is set as the current Web3 provider. ³⁹³ The ethereum.service.ts service provides the components with access to the functionality of the deployed smart contract. ³⁹⁴

Engebretsen and Haugen then summarized the results of their PoC.³⁹⁵ Engebretsen and Haugen determined that in applying blockchain to the music industry, blockchain could provide more transparency within the ecosystem and optimize the industry’s currently inefficient money flow.³⁹⁶ Engebretsen and Haugen’s PoC successfully implemented these four components:

“an open [and] transparent” registered works and licenses database,
representing copyright as erc721 tokens,
“[u]sers can create and purchase licenses for single musical works
“[m]usicians get real-time information about generated license royalties.”³⁹⁷

Two unresolved problems Engebretsen and Haugen’s PoC could not address were:

an international standard for regulating licensing, and
“[s]ingle license contracts that involve several musical works.”³⁸⁹

A major accomplishment we ascertained from Engebretsen and Haugen’s PoC (which they also acknowledged) was creating a Graphical User Interface (GUI) that made it less apparent to the user that they were interacting with smart contracts and the technicalities of a blockchain.³⁹⁹ A specific feature of Engebretsen and Haugen’s web application that we thought was very supportive of automated licensing was providing contributors the option to o er synchronization and public performance licenses by default, and the option for contributors create their own license as a license pro le.⁴⁰⁰ In developing our Tokenized Music License (TML) on the OpenLaw

³⁸⁷Haugen and Engebretsen, “The Music Industry on Blockchain Technology”.

³⁸⁸Ibid.

³⁸⁹Ibid.

³⁹⁰Ibid.

³⁹¹Ibid.

³⁹²Ibid.

³⁹³Ibid.

³⁹⁴Ibid.

³⁹⁵Ibid.

³⁹⁶Ibid.

³⁹⁷Ibid.

³⁹⁸Ibid.

³⁹⁹Ibid.

⁴⁰⁰Ibid.

platform, we believe our license could be used in conjunction with Engebretsen and Haugen’s Rights Done Right DApp and web application in the create work section by including our license as a license pro le or creating a web form for the TML.⁴⁰¹

After developing their PoC, Engebretsen and Haugen considered the challenges of blockchain, whether the music industry is ready for blockchain, blockchain as an economic transaction system, blockchain’s immutability characteristic, centralized v. distributed storage, and web applications.⁴⁰² Because the challenges associated with smart contracts was mentioned earlier by Maher and van Moorsel, we only discussed challenges Maher and van Moorsel did not address in their paper.⁴⁰³

A major challenge for Engebretsen and Haugen’s PoC were the Gas fees associated with registering a musical work on their DApp.⁴⁰⁴ Engebretsen and Haugen estimated that the cost of registering a work to the DApp was approximately $0.10 - $0.60, an amount that may be trivial to an independent musician, but is a significant amount to a major publisher because of the large number of works that they need to register.⁴⁰⁵ Engebretsen and Haugen discussed that the most popular Ethereum programming language, Solidity, has major limitations because of its relative immaturity compared to other mature languages such as Java or .NET, and certain technical limitations that Engebretsen and Haugen had to make up for on the front-end.⁴⁰⁶ Engebretsen and Haugen do not believe the music industry is ready to transition to trustless DApps because the major intermediaries, CMOs and record labels, do not have the incentive to radically change their business models, especially to a new platform that they do not control.⁴⁰⁷ Engebretsen and Hauge expect a slow transition from legacy systems to blockchain-backed systems in the music industry.⁴⁰⁸ Then regarding the necessity of blockchain to solve issues in the music industry, Engebretsen and Haugen believe blockchain can disrupt the oligarchy in control of the music industry, but that a blockchain is not necessary for solving the lack of information and standards in the music industry because a centralized solution can be developed to address this issue.⁴⁰⁹ Engebretsen and Haugen concluded that cryptocurrencies are currently not a sound basis for [a] financial transaction system because of their extreme volatility relative to at currencies, and that the current financial system revolves around government-issued at currencies.⁴¹⁰ In their DApp, Engebretsen and Haugen priced the licenses in ETH because ETH is a static value, but because ETH is volatile compared with at currencies, the price of a license will constantly fluctuate.⁴¹¹ A possible workaround suggested by Engebretsen and Haugen is to price the licenses in USD instead through the aid of a data oracle, albeit with further research needed on whether oracles weaken[] blockchain’s core decentralization objectives. ⁴¹² Engebretsen and Haugen discussed the advantages and disadvantages of blockchain’s immutability.⁴¹³ Immutability provides data integrity as no stored records on the blockchain can be altered, but this also provides disadvantages if musicians want to make changes to their registered work, or the inability to patch a smart contract if a vulnerability is found.⁴¹⁴

Engebretsen and Haugen discussed the advantages and disadvantages of centralized versus distributed storage.⁴¹⁵ Engebretsen and Haugen discussed that centralized storage’s major advantage is its easy configurability and integration with any application. ⁴¹⁶ However, a disadvantage of centralized storage is that such data centers are a single point of failure, and users must trust a third party to keep their data safe and not

⁴⁰¹Haugen and Engebretsen, “The Music Industry on Blockchain Technology”.

⁴⁰²Ibid.

⁴⁰³Haugen and Engebretsen, “The Music Industry on Blockchain Technology”; Alharby and Moorsel, “Blockchain Based Smart Contracts : A Systematic Mapping Study”.

⁴⁰⁴Haugen and Engebretsen, “The Music Industry on Blockchain Technology”.

⁴⁰⁵Ibid.

⁴⁰⁶Ibid.

⁴⁰⁷Ibid.

⁴⁰⁸Ibid.

⁴⁰⁹Ibid.

⁴¹⁰Ibid.

⁴¹¹Ibid.

⁴¹²Ibid.

⁴¹³Ibid.

⁴¹⁴Ibid.

⁴¹⁵Ibid.

⁴¹⁶Ibid.

share their data with third parties.⁴¹⁷

In distributed peer-to-peer storage, data is stored across a network [of] nodes, making them more secure, possibly faster, cheaper and censorship resistant.⁴¹⁸ Distributed storage systems leverage the enormous amounts of unused storage space located on the user’s hard drive[s] around the world. ⁴¹⁹ Many of the distributed storage solutions are in development so Engebretsen and Haugen instead chose to use Google’s Firebase, which does lead to more centralization than wanted, but they still believe their DApp is sufficiently decentralized.⁴²⁰

In answering their research questions, Engebretsen and Haugen concluded that blockchain could apply to solve problems in the music industry related to transparency, efficiency, standards, and inaccessible copyright information. ⁴²¹ However, Engebretsen and Haugen’s research also revealed limitations of blockchain such as scalability and processing time, and the lack of maturity in tools and community which hinder DApp development.⁴²² Two areas for further research Engebretsen and Haugen mentioned were investigating the legal and governance issues involved with creating a music licensing DApp.⁴²³

1.7.2 Metadata

Bill Rosenblatt proposed the use of audio watermarks in conjunction with blockchain technology to track musical works in Watermarking Technology and Blockchains in the Music Industry. ⁴²⁴ In proposing this solution, Rosenblatt identified the following issues in the music industry that have led to the need for tracking musical works:

there are two separate copyrights in the musical composition and the sound recording and the difficulty of tying sound recordings to specific musical compositions,
the lack of a uniform “source for mapping recordings to their underlying compositions”, and
standard identifiers in the music industry are “neither ubiquitous nor comprehensive enough to enable automated identification of music without errors, gaps, or ambiguities.”⁴²⁵

These issues led Rosenblatt to consider the need for unique identifiers for tracking musical compositions and sound recordings.⁴²⁶ In creating unique identifiers, Rosenblatt analyzed four methods to bind identifiers to digital audio files that could curb the above issues:

header metadata;
hashes;
acoustic fingerprints; and
digital watermarks.⁴²⁷

In analyzing the four methods, Rosenblatt concluded that digital watermarks are the best method for binding identifiers to digital audio files.⁴²⁸

Rosenblatt examined the binding identifiers based on the following criteria:

⁴¹⁷Haugen and Engebretsen, “The Music Industry on Blockchain Technology”.

⁴¹⁸Ibid.

⁴¹⁹Ibid.

⁴²⁰Ibid.

⁴²¹Ibid.

⁴²²Ibid.

⁴²³Ibid.

⁴²⁴Bill Rosenblatt. Watermarking Technology and Blockchains in the Music Industry. Whitepaper. Digimarc Corporation, pp. 1” 24. url: https://www.digimarc.com/docs/default-source/digimarc-resources/whitepaper-blockchain-in-music-industry.pdf?sfvrsn=2.

⁴²⁵Ibid.

⁴²⁶Ibid.

⁴²⁷Ibid.

⁴²⁸Ibid.

“Robustness: the identifier remains associated with the file even after the file has been transformed in various ways, such as transcoding, downsampling, excerpting, pitch-shifting, re-equalizing, and digital-analog-digital conversion”;
“Data Flexibility: the same audio data can exist in multiple files with different identifiers”;
“Identifer Reliability: the identifier can reliably identify the recording in the file for rights and royalty management purposes”; and
“Security: the identifier is difficult to remove or change without altering or marring the content.”⁴²⁹

Rosenblatt determined that header metadata provided data reliability and identifier reliability because they are easy to insert into a file, even multiple headers, and can contain multiple types of values, but lacked in robustness and security because it is trivially easy to change or remove header metadata without affecting the content, and may not survive when the file is transformed.⁴³⁰

Rosenblatt determined that hashes provided identifier reliability since hashes are generally unique for an individual file, but lacked in robustness, security, and data flexibility because they do not give the copyright owner or distributor any flexibility or control over identifiers, and the hash can easily change if just a single bit of audio data is modi ed, such as by changing the file format.⁴³¹

Rosenblatt determined that acoustic fingerprints⁴³² provided robustness and security because like standard hashes, fingerprints are inherent in the data, so they can’t be removed or separated from it. But unlike standard hashes, it’s difficult (if not impossible) to alter a file’s fingerprint without perceptibly marring its sound to a listener. ⁴³³ However, acoustic fingerprints lacked in data flexibility and identifier reliability because fingerprinting is not very good at differentiating between certain versions of a given music track that might need to be distinguished for rights and royalty management purposes, and it is impossible to assign different identifiers to different files containing the same recording. ⁴³⁴

Rosenblatt determined that digital watermarks excelled in each category because [a] well-designed watermarking scheme is robust to transformations . . . , can be used to associate any data desired . . . , can allow a level of certainty comparable to header metadata, and can’t be altered without seriously disrupting the audio itself. ⁴³⁵ The one disadvantage of watermarks is that they need to be inserted into legacy audio content.⁴³⁶

Rosenblatt also considered the application of blockchain technology with digital watermarks.⁴³⁷ Concerning storing digital music files on a blockchain, Rosenblatt concluded that digital music files should not be stored on a blockchain because blockchains currently are not efficient enough to store files and transaction information.⁴³⁸ Rather, the more appropriate use would be to store transaction information associated with digital music files on the blockchain, though with a loss of security.⁴³⁹ To remedy the loss of security, Rosenblatt recommended creating links between transactions and digital audio files, whereby a unique identifier stored in the transaction references or matches an identifier in a digital audio file.⁴⁴⁰ Rosenblatt identified two secure methods for linkage:

encryption, and
digital watermarks.⁴⁴¹

⁴²⁹Rosenblatt, Watermarking Technology and Blockchains in the Music Industry.

⁴³⁰Ibid.

⁴³¹Ibid.

⁴³²A special type of hash function that returns the same value for all inputs that sound the same to a human listener.

⁴³³Rosenblatt, Watermarking Technology and Blockchains in the Music Industry.

⁴³⁴Ibid.

⁴³⁵Ibid.

⁴³⁶Ibid.

⁴³⁷Ibid.

⁴³⁸Ibid.

⁴³⁹Ibid.

⁴⁴⁰Ibid.

⁴⁴¹Ibid

Rosenblatt assessed that encryption was a suitable method, but would be too complex and cumbersome for the user or service provider because the whole file (digital audio and metadata) must be encrypted together, and if the user or service provider wants to process or convert the file’s format, they will have to use a special application that will decrypt the file, do the conversion, and preserve the integrity of the metadata. ⁴⁴² In comparison with digital watermarks, Rosenblatt assessed that digital watermarks are easier to deal with for users or service providers because they can process or convert the file’s format without any intermediary step and avoid damaging the digital watermark’s integrity.⁴⁴³

Rosenblatt provided an example of how Core Rights could use digital watermarking and blockchain for their venue licensing marketplace.⁴⁴⁴ Core Rights could embed digital watermarks in its digital music files to identify them as Core Rights files for its venue licensing marketplace, and store transactions on the blockchain that include information about the licensee, ISRC, and underlying composition and/or sound recording.⁴⁴⁵ Alternatively, this information can be stored in the digital watermark.⁴⁴⁶ A player application can then be used to read the digital watermark and record acceptance of the license on Core Rights blockchain, or alternatively, the digital watermark can be used for auditing purposes by tracing the digital watermark to transactions on the blockchain.⁴⁴⁷

Rosenblatt provided examples of how producers could use embedded identifiers and blockchain for found music and for royalty payments.⁴⁴⁸ For found music in remixes, producer[s] could use an app that reads the watermark in a [digital] music file, deposits a licensing transaction on a blockchain, and then [the smart-contract will] provide stems (individual tracks) to the producer for remixing. ⁴⁴⁹ Once the producer has created remixes based on the individual stems, the producer will submit the remix through the app to the service provider, which will give the remix its own unique digital watermark and associating the remix’s digital watermark with the digital watermarks associated with the stems.⁴⁵⁰ This will allow the service provider to easily process rights and royalty management for anyone who wants to use the remix, as well as the owner(s) of the stems.⁴⁵¹ For royalty payments, digital watermarks could be used for interactive streaming services because each time a music file is played, a transaction can be recorded on the blockchain with the applicable royalties due to rights holders.⁴⁵² These transactions can be traced to the digital watermark in the digital music file because the identifiers used would be the same, thereby allowing rights holders to access transaction information from extracting identifiers without any need to contact the [digital music service providers (DSPs)] directly. ⁴⁵³ Lastly, Rosenblatt found this royalty scheme applicable with Dot Blockchain Media’s⁴⁵⁴ architecture and Open Music Initiative’s vision.⁴⁵⁵

Benji Rogers approach for dotBlockchain Media (rebranded to Verifi Media) is to create an open-source technology for a file format (ending in .bc ) which will contain metadata referencing blockchain transactions, ownership information, and licensing information in addition to the digital music file.⁴⁵⁶ Verifi Media is being developed to be interoperable with any blockchain (i.e., blockchain agnostic) and existing music rights databases.⁴⁵⁷ Verifi Media’s founders believe the file format’s interoperability will depend on a Minimum Viable Data (MVD) standard.⁴⁵⁸ The MVD standard’s approach is to require the least amount of essential information needed to discern a

⁴⁴²Rosenblatt, Watermarking Technology and Blockchains in the Music Industry.

⁴⁴³Ibid.

⁴⁴⁴Ibid.

⁴⁴⁵Ibid.

⁴⁴⁶Ibid.

⁴⁴⁷Ibid.

⁴⁴⁸Ibid.

⁴⁴⁹Ibid.

⁴⁵⁰Ibid.

⁴⁵¹Ibid.

⁴⁵²Ibid.

⁴⁵³Ibid.

⁴⁵⁴Rebranded to Verifi Media

⁴⁵⁵Rosenblatt, Watermarking Technology and Blockchains in the Music Industry.

⁴⁵⁶Benji Rogers. The dotBlockchain Music Project update #7 Minimum Viable Data Doc. en. Sept. 2019. url: https://medium.com/verifimedia/the-dotblockchain-music-project-update-7-minimum-viable-data-doc-561fdfadd5eb (visitedon 12/17/2019); Veri Media. url: https://verifi.media/ (visited on 12/17/2019); Rosenblatt, Watermarking Technology and Blockchains in the Music Industry.

⁴⁵⁷Rosenblatt, Watermarking Technology and Blockchains in the Music Industry.

⁴⁵⁸Rogers, The dotBlockchain Music Project update #7 Minimum Viable Data Doc.

musical recording and associated rights holders from another musical recording.⁴⁵⁹ With this model, musicians can easily upload their musical works and associated information, with changes tracked by a blockchain.⁴⁶⁰ Additional information can also be provided for commercial uses and then tailored to external databases.⁴⁶¹

Another initiative worth mentioning is the Open Music Initiative (OMI), described as a non-pro t initiative . . . creating an open-source protocol for the uniform identification of music rights holders and creators. ⁴⁶² The aim of the initiative is to facilitate platform interoperability. Presence of patrons such as Berklee and Massachusetts Institute of Technology (MIT) Connection Science gives hope that the approach taken may produce noticeable results, amid the myriad of solutions present in the digital music industry.⁴⁶³

1.7.3 Semantic Web

Primavera De Filippi, Greg McMullen, Trent McConaghy, Constance Choi, Simon de la Rouvière, Juan Benet, and Diana J. Stern, in How Blockchains Can Support, Complement, or Supplement Intellectual Property, discussed the benefits of blockchain for intellectual property (IP) with a particular discussion of copyright.⁴⁶⁴ For our research purposes, we focused on Filippi et al.’s discussion of how automated licensing can remove the complexity associated with finding the licensing terms of a copyrighted work.⁴⁶⁵ Automated licensing, with the aid of a public registry for works, can help potential licensees, find an appropriate license and the acceptable methods of payment.⁴⁶⁶ By making it easier for potential licensees to nd appropriate licenses, more people should be encouraged to follow the legal routes for using a copyrighted work.⁴⁶⁷

Additionally, we shall also discuss the Coalition of Automated Legal Applications Intellectual Property Working Group (COALA-IP) development of an IP licensing protocol that combines the Semantic Web with blockchain.⁴⁶⁸ The two major goals of the licensing protocol are to develop a minimum viable data set for IP licensing (JSON-LD, RDF schemas) and a free and open messaging protocol for licensing transactions (ILP, IPLD, LCC).⁴⁶⁹ COALA-IP’s licensing protocol is built on four building blocks:

Linked Content Coalition (LCC) framework,
Linked Data (LD),
InterPlanetary Linked Data (IPLD), and
InterLedger Protocol (ILP).⁴⁷⁰

The LCC framework is meant to unify data standards for IP works through a Rights Reference Model (RRM) and Entity Model (EM).⁴⁷¹ LCC RRM is meant to provide a formal framework of representing intellectual property rights, and is built on top of LCC EM.⁴⁷² LCC EM is a meta-model for identifying entities who are IP rightsholders, and is the base model for LCC RRM.⁴⁷³

⁴⁵⁹Rogers, The dotBlockchain Music Project update #7 Minimum Viable Data Doc.

⁴⁶⁰Ibid.

⁴⁶¹Ibid.

⁴⁶²About. en-US. url: https://open-music.org/about (visited on 12/17/2019).

⁴⁶³OMI API Specification - MVI 1.0 (beta) · Apiary. url: https://omi01.docs.apiary.io/#introduction/common-apiconventions/authentication-and-authorization (visited on 12/17/2019).

⁴⁶⁴Primavera De Filippi et al. HOW BLOCKCHAINS CAN SUPPORT, COMPLEMENT, OR SUPPLEMENT INTELLECTUAL PROPERTY. url: https://github.com/COALAIP/specs/blob/master/presentations/COALA%20IP%20Report%20-%20May%202016.pdf.

⁴⁶⁵Ibid.

⁴⁶⁶Ibid.

⁴⁶⁷Ibid.

⁴⁶⁸COALA-IP Protocol. en. Whitepaper. Github, Oct. 2016. url: https : / / github . com / COALAIP / specs / blob / master / presentations/COALA%20IP%20-%20short.pdf (visited on 12/17/2019).

⁴⁶⁹Ibid.

⁴⁷⁰Ibid.

⁴⁷¹COALAIP/specs. original-date: 2016-10-11T09:21:36Z. Aug. 2019. url: https://github.com/COALAIP/specs (visited on 10/10/2019).

⁴⁷²Ibid.

⁴⁷³Ibid.

Linked Data (LD) is a design approach to connect machine-readable, interlinked resources across the semantic web, i.e., the web of data, through the use of Semantic Web technologies such as Uniform Resource Identifiers (URIs) and the Resource Description Framework (RDF).⁴⁷⁴ RDF’s core data structure is a graph-based model that uses sets of triplets [(subject, predicate, and object)] to construct graph subsets. ⁴⁷⁵ COALA-IP employs JSON-LD to link JSON object’s properties to a corresponding RDF schema through the concept of a context. ⁴⁷⁶ COALA-IP uses JSON-LD in conjunction with schemas from Schema.org, a collaborative initiative with the mission to create, maintain and promote schemata for structured data on the internet. ⁴⁷⁷

IPLD is an attempt to put Linked Data on distributed ledgers by using hashes as content-addressed links, a technique referred to as “Merkle Links.”⁴⁷⁸ Merkle Links provide the ability to cryptographically check the data referred to by a link. ⁴⁷⁹ Through IPLD, IP data stored on different blockchains can reference the existence of related IP data on other blockchains.⁴⁸⁰

ILP is an open source protocol being developed in a W3C Community Group “for sending payments across different ledgers” over the web.⁴⁸¹ COALA-IP may use ILP to conduct IP licensing transactions on multiple blockchains.⁴⁸²

In COALA-IP’s IP licensing protocol, COALA-IP implements the LCC framework with JSON-LD and IPLD, and with certain modifications to meet COALA-IP’s needs.⁴⁸³ COALA-IP’s IP licensing protocol implements the following models of the LCC RRM framework:

Place,
Party,
Creation,
Right,
RightsAssignment,
Assertion, and
RightsConflict.⁴⁸⁴

1.7.4 Ricardian Contracts

Usman W. Chohan in What Is a Ricardian Contract?, discussed how recent technological innovations have made Ricardian Contracts (RCs) viable and considered their wider implementations and uses given their benefits.⁴⁸⁵ Chohan defines a RC as a method of expressing, encoding, and executing a contractual document through

⁴⁷⁴What are Linked Data and Linked Open Data? en-US. url: https://www.ontotext.com/knowledgehub/fundamentals/linked-data-linked-open-data/ (visited on 10/10/2019); Introduction to the Solid Specification | Solid. url: https://solid.inrupt.com/docs/intro-to-solid-spec (visited on 10/18/2019).

⁴⁷⁵COALAIP/specs.

⁴⁷⁶Ibid.

⁴⁷⁷Ibid.

⁴⁷⁸Ibid.

⁴⁷⁹Ibid.

⁴⁸⁰Ibid.

⁴⁸¹COALA-IP Protocol; Interledger Overview. publisher: Interledger. url: https://interledger.org/overview.html (visited on 12/17/2019); Interledger Payments Community Group. en-US. url: https://www.w3.org/community/interledger/ (visited on 12/17/2019).

⁴⁸²COALA-IP Protocol (Additional Semantic Web approaches to examine are Oasis LegalRuleML, Open Digital Rights Language, and Creative Commons Rights Expression Language.).

⁴⁸³COALAIP/specs.

⁴⁸⁴Ibid.

⁴⁸⁵Usman W. Chohan. What Is a Ricardian Contract? en. In: *SSRN Electronic Journal *(2017). issn: 1556-5068. doi: 10.2139/ssrn.3085682. url: https://www.ssrn.com/abstract=3085682 (visited on 10/18/2019).

software, which means that it represents the recording of documents as contractually lawful, and then securely linking them to other ambits/systems, such as of accounting, for the contract to serve as an issuance of value. ⁴⁸⁶

RCs have three primary advantages:

“robust,
transparent, and
efficient.”⁴⁸⁷

RCs are robust because they utilize cryptographic hashes.⁴⁸⁸ RCs are transparent because the legal prose is human-readable.⁴⁸⁹ RCs are efficient because the markup language extracts essential information as machine-readable tags.⁴⁹⁰ Chohan describes the advantages of Ricardian Contracts from a legal perspective and a computing perspective.⁴⁹¹

From a legal perspective, the markup language leads to reduced transaction costs, faster dispute resolution, better contract enforcement and enhanced transparency. ⁴⁹² From a computing perspective, the software design pattern [] digitizes documents . . . without losing any of the richness of the contracting tradition. ⁴⁹³ An additional bene t for both perspectives is that cryptographic hash functions mitigate against fraud because there is a cryptographic hash function that refers to the agreement, and the parties both sign the agreement with a cryptographic signature (similar to signing a transaction with a public-private key pair in a cryptocurrency transaction).⁴⁹⁴

Chohan describes the four components of a RC as follows:

“a contract is offered by an issuer to contract holders”;
“[i]t is held for a valuable right by holders and managed by the issuer”;
“[i]t is easily readable on paper and by programs”; and
“[i]t is digitally signed, carrying the keys and server information, and is allied with a unique, secure identifier.”⁴⁹⁵

Chohan describes the characteristics of a RC as follows:

“dislocalization of parties across time and domain”;
cryptographic hashes to bind the parties for “legal and accounting aspects”;
each subsequent transaction references the hash of the Ricardian contract;
“operations of … transactions and the issuance of the contract are cleanly separated”; and
agreements may be done in counterparts and/or in smaller sub-agreements that are combined to form one single agreement.⁴⁹⁶

⁴⁸⁶Ibid.

⁴⁸⁷Ibid.

⁴⁸⁸Ibid.

⁴⁸⁹Ibid.

⁴⁹⁰Chohan, “What Is a Ricardian Contract?”

⁴⁹¹Ibid.

⁴⁹²Ibid.

⁴⁹³Ibid.

⁴⁹⁴Ibid.

⁴⁹⁵Ibid.

⁴⁹⁶Ibid.

Chohan reflects that the concept of RCs is similar to the concept of smart contracts.⁴⁹⁷ However, Chohan discusses that the difference between RCs and smart contracts is that smart contracts [relate] to the automated execution of already agreed contracts, while Ricardian Contracts represent a design pattern that captures the intent of agreeing parties. ⁴⁹⁸ Thus, this difference leads to the realization that Ricardian Contracts are a vehicle for [implementing] smart contracts. ⁴⁹⁹

For an interesting implementation of a Ricardian Contracts for connecting online transactions with online legal agreements, please refer to Jørgen Svennevik Notland, Jakob Svennevik Notland, and Donn Morrison’s masters thesis, The Minimum Hybrid Contract (MHC): Combining legal and blockchain smart contracts. ⁵⁰⁰

1.7.5 Online Dispute Resolution

Derric Yeoh in Is Online Dispute Resolution The Future of Alternative Dispute Resolution?’ discusses online mediation, online arbitration, and blockchain-based arbitration.⁵⁰¹ Yeoh describes online mediation as disputants interacting with a mediator in virtual chatrooms.⁵⁰² Yeoh described asynchronous mediation as the most popular method for three reasons:

“[it] allows parties flexibility and faster resolution of the matter compared to online mediation,”
it provides “savings in cost, time and convenience,” and
it gives the “parties time to fashion their response.”⁵⁰³

Though, a drawback of online mediation is that it does not capture the human relational aspect of mediation. ⁵⁰⁴ Yeoh describes online arbitration as an arbitration in which all aspects of the proceedings are conducted online, with the disputants generally sometimes interacting via video conferencing, but more often than not simply submitting evidentiary documents to the arbitrator, receiving feedback, and then the arbitrator’s decision.⁵⁰⁵ Online arbitration provides the same advantages and disadvantages of online mediation, but there is less of a concern over the human relational aspect since the disputants rarely directly interact in traditional arbitration.⁵⁰⁶

Yeoh, than transitions to discuss blockchain-based arbitration as the ADR choice for smart contract-related disputes, especially in the case of complex smart contracts.⁵⁰⁷ Yeoh highlights two blockchain-based ADR organizations, CodeLegit and Coopérative Kleros (Kleros) as pioneering blockchain-based ADR.⁵⁰⁸ Yeoh highlighted two issues that might prevent blockchain-based arbitration from replacing traditional arbitration.⁵⁰⁹ First, certain national legislatures may not recognize smart contracts as contracts under their contract law framework, and the difficulty of translating legal contracts into smart contracts.⁵¹⁰ Second, whether including an arbitral clause in a smart contract will satisfy a legal requirement of an arbitration clause be in writing.⁵¹¹ Though, these two issues can be avoided with a Ricardian Contract.⁵¹² An interesting issue Yeoh raised with

⁴⁹⁷Ibid.

⁴⁹⁸Ibid.

⁴⁹⁹Ibid.

⁵⁰⁰Jørgen Svennevik Notland, Jakob Svennevik Notland, and Donn Morrison. The Minimum Hybrid Contract (MHC): Combining legal and blockchain smart contracts. 2020. arXiv: 2002.06850 [cs.CY].

⁵⁰¹Derric Yeoh.* Is Online Dispute Resolution The Future of Alternative Dispute Resolution?* en-US. Mar. 2018. url: http://arbitrationblog.kluwerarbitration.com/2018/03/29/online-dispute-resolution-future-alternative-dispute-resolution/ (visited on 12/19/2019).

⁵⁰²Ibid.

⁵⁰³Ibid.

⁵⁰⁴Ibid.

⁵⁰⁵Ibid.

⁵⁰⁶Ibid.

⁵⁰⁷Ibid.

⁵⁰⁸Ibid.

⁵⁰⁹Ibid.

⁵¹⁰Ibid.

⁵¹¹Ibid.

⁵¹²Supra Section 5.9.

Kleros is that since jurors in Kleros court can only consider blockchain transactions as evidence, then any decision rendered by the Kleros court may be refused recognition and enforcement under Article V(1)(b) of the New York Convention for not giving the party the opportunity to present its case. ⁵¹³

Kleros ADR Protocol

Coopérative Kleros (Kleros) is a French cooperative that is developing an open source, decentralized ADR system ( Kleros Court ) and escrow service on the Ethereum blockchain to resolve disputes (generally with a focus on disputes arising from, or related to, smart contracts).⁵¹⁴ Kleros Court is a crowdsourced juror system which incentivizes people to become jurors with cryptoeconomic schemes (i.e., game theory) where jurors (who must purchase Kleros’ PNK tokens to participate in Kleros Court) earn arbitration fees for ruling on disputes, dependent on the juror’s good or bad behavior.⁵¹⁵

The Kleros Court adjudication process comprised of seven (7) components:

“Contract,
Securing Evidence,
Jury Selection,
Analysis,
Voting,
Appeal, [and]
Token Redistribution.”⁵¹⁶

The Contract component requires the parties to voluntary opt-in to resolving their dispute on Kleros Court, decide the subcourt to hear their dispute, and to pay a deposit fee to cover juror’s fees.⁵¹⁷ The Securing Evidence component requires the parties to submit evidence to Kleros via public key cryptography.⁵¹⁸

The Jury Selection component is made up of two parts, self-selection and sortition.⁵¹⁹ A candidate self-selects to be a juror in a specific subcourt by depositing a reputation token called pinakion (PNK) with the subcourt.⁵²⁰ The probability [of being drawn] as [a] juror is [positively] proportional to the [deposit amount]. ⁵²¹ Sortition describes the process of how juries are selected for specific disputes.⁵²²In Kleros Court, juries are randomly selected from the juror pool (candidates who have self-selected to be jurors) for a specific subcourt.⁵²³ Each juror’s voting power, and the amount of tokens they will win or lose as a result of voting, in a dispute depends on the number of times they are drawn (i.e., the number of times their PNK tokens were randomly selected) for a dispute.⁵²⁴

⁵¹³Yeoh, Is Online Dispute Resolution The Future of Alternative Dispute Resolution?

⁵¹⁴Nick Sawinyh. Kleros - decentralized court system to adjudicate smart contracts. en. Nov. 2019. url: https://defiprime.com/kleros (visited on 12/11/2019); About Us. url: https://kleros.io/about/ (visited on 12/11/2019).

⁵¹⁵Sawinyh, Kleros - decentralized court system to adjudicate smart contracts; About Us.

⁵¹⁶Federico Ast. Kleros, a Protocol for a Decentralized Justice System. en. Jan. 2018. url: https://medium.com/kleros/klerosa-decentralized-justice-protocol-for-the-internet-38d596a6300d (visited on 12/12/2019).

⁵¹⁷Ibid.

⁵¹⁸Ibid.

⁵¹⁹Ibid.

⁵²⁰Ibid.

⁵²¹Ibid.

⁵²²Ibid.

⁵²³Ibid.

⁵²⁴ibid. ( Jury selection is done randomly among all the users that activated their pinakion in a subcourt. Theoretically a candidate may be drawn more than once for a specific dispute. The amount of times a user is drawn for a dispute (called its weight) will define the number of votes he will get in the dispute and the amount of tokens he will win or lose as a result of his vote. Imagine that 6 token owners signed up for the dispute and activated 10,000 in total with the following distribution: For a dispute that requires 5 votes, 5 tokens are drawn out of the 10,000 that were activated. The drawn tokens are number 2519, 4953, 2264, 3342 and 9531. The token owners B, C and F are drawn with a weight of 1. The token owner D is drawn with a weight of 2. Activated pinakion will be frozen during the court session and will be unfrozen after the court has reached a verdict. ).

In the Analysis component, jurors can assess evidence and vote on decisions pursuant to the subcourt’s rules and procedures.⁵²⁵

In the Voting component, jurors are required to cast their votes on issues presented in the case.⁵²⁶ All votes cast are final, and jurors must provide a justification for their vote.⁵²⁷ Juror votes are hidden from other jurors during this process and are only revealed after the final decisions has been entered.⁵²⁸ The winning option is based on the median of the votes.⁵²⁹ Any option below the median will be vetoed by more than half of the voters (the upper half), and the same will happen with options above the median (and the lower-half of voters). ⁵³⁰

In the Appeal component, the losing party may appeal the jury’s decision in the dispute (this may be done several times).⁵³¹ In doing so, the losing party must deposit tokens again to pay for arbitration fees, with the cost of appeal calculated as the arbitration fee multiplied by the number of jurors.⁵³² In each appeal, the number of jurors is doubled plus one from the previous instance, thus, the cost of appeal becomes cost prohibitive in the long run for the losing party.⁵³³

In the Token Redistribution component, after a decision has been made, jurors will gain or lose [PNK] depending on whether their vote was coherent with the rest [(i.e., whether their vote was within the 25 -75th percentile of the vote distribution]. ⁵³⁴ If the juror’s vote is outside the 25-75th percentile, then their PNK will be transferred to the jurors who voted in the 25-75th percentile. Regardless of their vote, jurors will receive arbitration fees equally.⁵³⁵

For subcourt parameters (very much needed depending on the type of dispute), token holders have the right to make a number of decisions affecting . . . subcourts . . . include[ing] policies, session time, arbitration fees, maximum number of jurors drawn and minimum number of tokens activated. ⁵³⁶

Given the unclear nature of blockchain-based arbitration, it is possible that Kleros may or may not be a valid venue for ADR under the United Nations Commission on International Trade Law’s (UNCITRAL) model law on international commercial arbitration? In Dmitry Narozhny’s analysis, Kleros satis es the necessary criteria to be considered an arbitration venue under the model law.⁵³⁷ Narozhny analyzed two pertinent questions to reach the above conclusion:

does Kleros conform to the law? and
“[w]ould a court recognize a Kleros ruling?”⁵³⁸

Narozhny answered affirmatively to the first question because UNCITRAL principles explicitly preserve parties’ full freedom to determine the rules of arbitration procedure on their own and Kleros complies with core principles of due process.⁵³⁹ Narozhny answered affirmatively to the second question as well because Kleros is a self-enforcing arbitration method, and a subsequent review and refusal of a Kleros decision under the New York Convention on the Recognition and Enforcement of Foreign Arbitral Awards is unlikely to occur because procedural grounds to refusal are mitigated in advance by Kleros’ protocol design. ⁵⁴⁰

⁵²⁵Ibid.

⁵²⁶Ibid.

⁵²⁷Ibid.

⁵²⁸Ibid.

⁵²⁹Ibid.

⁵³⁰Ibid.

⁵³¹Ast, Kleros, a Protocol for a Decentralized Justice System.

⁵³²Ibid.

⁵³³Ibid.

⁵³⁴Ibid.

⁵³⁵Ibid.

⁵³⁶Ibid.

⁵³⁷Dmitry Narozhny. *Is Kleros Legally Valid as Arbitration? *en. June 2019. url: http://blog.kleros.io/is-kleros-legallyvalid-as-arbitration/ (visited on 12/11/2019).

⁵³⁸Ibid.

⁵³⁹Ibid.

⁵⁴⁰ibid. (“[P]rocedural grounds [for] refusal: incapacity, lack of jurisdiction, lack of proper notice, tribunal not composed according to

1.7.6 Legal Engineering

Token engineering can be defined as the practice of designing token economic systems (aka token systems) built on Web3 technologies through rigorous engineering practices (though, Web3 technologies are not required).⁵⁴¹ Token engineering can be subdivided into four disciplines:

Technical Engineering,
Economic Engineering,
Legal Engineering, and
Ethical Engineering.⁵⁴²

All four disciplines are required to design an effective token economic system.⁵⁴³ For our research purposes, we shall only discuss legal engineering. For more information on token engineering, please refer to Shermin Voshmgir’s How do Design a Token System and her book, Token Economy (2nd edition).⁵⁴⁴ Legal engineering, as described by Voshmgir, is the practice of tokenizing traditional governance and business models through Web3 technologies (e.g., “smart contracts replac[ing] many of the existing human/paper/client-server based operations”) to be compliant with the applicable laws, rules and regulations of a jurisdiction(s).⁵⁴⁵ Legal engineering plays a larger role in the design of simple token economic systems (“The term simple [a]s used in the complex systems domain.”), which are systems where the “dynamics of the business or governance models of . . . tokens is well known,” such as “(i) central bank money, (ii) securities and other assets, (iii) identification and certification processes, (iv) voting rights, (v) vouchers and coupons or (vi) entry tickets and other access rights.”⁵⁴⁶