First R3 Smart Contract Templates Summit (All Slides)

June 29th, 2016 New York and London

Smart Contract Templates Summit th June 29 , 2016 New York and London

Agenda 2

NY LDN NY LDN 08.00 13.00 Arrival and breakfast / 10.55 15.55 Smart legal contracts: Dr. Chris Clack light lunch prose, parameters, Senior Lecturer, University code College London 08.30 13.30 Welcome. Agenda David Rutter and goals for the Founder, R3 11.15 16.15 Introduction to shared Richard Gendal Brown summit ledger architecture CTO, R3 08.40 13.40 Smart Contract Dr. Lee Braine 11.25 16.25 Architectural Nick Palmer Templates progress Investment Bank CTO Office, considerations for Investment Bank Lead to date Barclays Smart Contract Architect, Barclays Templates 09.00 14.00 FinTech’s role in Clive Ansell derivatives markets Head of Market Instructure 11.55 16.55 Priorities for Smart Clemens Wan and Technology, ISDA Contract Templates Associate Director, R3 09.30 14.30 Legal documentation Darren Jones 12.10 17.10 Summary of key points Clemens Wan automation in Head of Investment Bank from the summit Associate Director, R3 investment banking Legal Automation, Barclays Gavin Thomas Tech COO, R3 10.00 15.00 A lawyer’s view of Sean Murphy smart contracts Partner, Norton Rose 12.15 17.15 Next steps Dr. Lee Braine Fulbright Investment Bank CTO Office, 10.15 15.15 Coffee break Barclays 12.30 17.30 Close 10.30 15.30 Introduction to the Ian Grigg Ricardian Contract Consultant Architect, R3 17.30 Networking and drinks (London only) 3

Summit Goals David Rutter Founder, R3 4

Lead to a base understanding of legal, architectural and business considerations Elicit challenges, concerns and issues Elicit preferences for future strategies whether legal, architectural or general design Identify candidate next steps Identify candidate next steps 5

Smart Contract Templates: Progress to Date Dr. Lee Braine Investment Bank CTO Office, Barclays 6

First R3 Smart Contract Templates Summit (All Slides) - Page 7
First R3 Smart Contract Templates Summit (All Slides) - Page 8
First R3 Smart Contract Templates Summit (All Slides) - Page 9
First R3 Smart Contract Templates Summit (All Slides) - Page 10
First R3 Smart Contract Templates Summit (All Slides) - Page 11

   

First R3 Smart Contract Templates Summit (All Slides) - Page 13
First R3 Smart Contract Templates Summit (All Slides) - Page 14
First R3 Smart Contract Templates Summit (All Slides) - Page 15

FinTech’s Role in Derivatives Markets Clive Ansell Head of Market Infrastructure and Technology, ISDA 16

June 29, 2016 London/New York FinTech’s Role in Derivatives Markets Clive Ansell Ian Sloyan Head of Market Infrastructure Director, and Technology Data and Reporting ISDA ISDA ® ISDA is a registered trademark of the International Swaps and Derivatives Association, Inc. 17 Copyright © 2016 International Swaps and Derivatives Association, Inc.

Contents • About ISDA • ISDA’s role • Industry challenges • Solutions • Smart contracts 18

About ISDA Since 1985, ISDA has worked to make the global derivatives markets safer and more efficient. Today, ISDA has over 850 member institutions from 67 countries. These members comprise a broad range of derivatives market participants, including corporations, investment managers, government and supranational entities, insurance companies, energy and commodities firms, and international and regional banks. In addition to market participants, members also include key components of the derivatives market infrastructure, such as exchanges, intermediaries, clearing houses and repositories, as well as law firms, accounting firms and other service providers. Information about ISDA and its activities is available on the Association's web site: www.isda.org. 19

ISDA’s Role • ISDA fosters safe and efficient derivatives markets to facilitate effective risk management for all users of derivative products • Market Infrastructure and Technology objectives: - Process simplification - Increased quality of data - Fair access - Robust derivatives market infrastructure - Consistent regulatory compliance 20

Industry Challenges • Complexity • Capacity • Regulatory compliance • Robust market infrastructure and processes • Cost and efficiency 21

Solutions • Standardisation • Process • Data • Documentation • Collaboration • All market participants • Mutualisation • Identify opportunities and benefits • Technology • FinTech – RegTech – DLT 22

Smart Contracts • Leveraging ISDA's documentation library • FpML • ISDA's plans 23

Questions? 24

Legal Documentation Automation in Investment Banking Darren Jones Head of Investment Bank Legal Automation, Barclays 25

             

            

Lawyer’s Advice Knowledge & Experience Precedents/ Templates Market Practice Internal Policies/ Law & Regulation Business Appetite for Processes Risk

• •

A Lawyer’s View of Smart Contracts Sean Murphy Partner, Norton Rose Fulbright 31

A lawyer’s view of smart contracts Sean Murphy, Partner 29 June 2016 32

What is a smart contract? Smart contracts lie on a spectrum Contract entirely Contract in code “Split” natural Natural language in code with separate language contract contract with i 100% natural language with encoded encoded payment Per A s C version performance mechanism fo tou on manrmated tr oC acte d Encoding Natural Language Automation ce 33

Code is contract: challenges • Is there a contract? • What are its terms? Smart Legally contracts binding contracts 34

Automated performance: challenges • Legal formalities • Proof of signature • Longer term smart contracts • Coding as the parties intended • Amendments • Confidentiality 35

Are there limits to smart contracts? ‘Material adverse change’ Current technology 36

The split contract model • Code and natural language at odds • Bugs in coding 37

Dispute resolution • Dispute resolution - can draw on existing dispute resolution mechanisms: –online dispute resolution platforms (e.g. EU Regulation 524/2013 provides for the establishment of an EU-level model for B2C disputes) –expert determination –choice of law and jurisdiction clauses –automatic operation of dispute resolution 38

Regulation • Regulatory considerations: –what exactly is it that should be regulated? –which activities? –AML and KYC considerations –governance, systems and controls obligations 39

Discussion points • How can amendments be dealt with? • What dispute resolution mechanisms are practical? • In the light of the Ethereum DAO, what steps should be taken to deal with security concerns in relation to smart contracts? 40

41

Disclaimer Norton Rose Fulbright US LLP, Norton Rose Fulbright LLP, Norton Rose Fulbright Australia, Norton Rose Fulbright Canada LLP and Norton Rose Fulbright South Africa Inc are separate legal entities and all of them are members of Norton Rose Fulbright Verein, a Swiss verein. Norton Rose Fulbright Verein helps coordinate the activities of the members but does not itself provide legal services to clients. References to ‘Norton Rose Fulbright’, ‘the law firm’ and ‘legal practice’ are to one or more of the Norton Rose Fulbright members or to one of their respective affiliates (together ‘Norton Rose Fulbright entity/entities’). No individual who is a member, partner, shareholder, director, employee or consultant of, in or to any Norton Rose Fulbright entity (whether or not such individual is described as a ‘partner’) accepts or assumes responsibility, or has any liability, to any person in respect of this communication. Any reference to a partner or director is to a member, employee or consultant with equivalent standing and qualifications of the relevant Norton Rose Fulbright entity. The purpose of this communication is to provide general information of a legal nature. It does not contain a full analysis of the law nor does it constitute an opinion of any Norton Rose Fulbright entity on the points of law discussed. You must take specific legal advice on any particular matter which concerns you. If you require any advice or further information, please speak to your usual contact at Norton Rose Fulbright. 42

Coffee break 43

Introduction to the Ricardian Contract: A retrospective Ian Grigg Consultant Architect, R3 4444

Introduction On the Internet, how do you: • issue a financial instrument? • that hundreds or millions can rely upon? • securely negotiate a financial agreement? • and not end up in a mess? • capture all the legal significance of a deal? • reduce confusions, empower traders, resolve disputes? 45

The Ricardian Contract is... A tool to capture the essence of any deal on the Internet, reliably, securely, and honestly. This presentation will show: • how it came to be • why it had to be in the form it is • how it expands to ‘blockchain’ finance 46

Ian Grigg 1995 - invented 1996 - first released in Ricardo 2004 - paper 2015 - extended for blockchains 2015 - consultant architect at R3 [email protected] or [email protected] 47

The ZERO XS Coupon Bond is the Atomic Element of Finance • NPV • CashFlow • options • Black-Scholes • Interest Rates • ... Z by Uyen T. Nguyen: licensed under CC BY 48

eCash, zeros, finance, oh my! 1983: blind signature 1994: eCash - dollar for paying on Internet DigiCash showed how to issue $1 on Internet Finance shows how to build zeros into any financial instrument eCash is a dollar, and a zero pays a dollar… Therefore, eCash is a zero! Therefore we can issue anything on the Internet... 49

Systemics Goal - issue anything on net 1) Research… 2) Pick an MVP → Bonds! 3) Deep Dive • Parameters Issuer, face, date, … • Coupons by induction, sub-bonds • Fine print legal prose → T&Cs Pacific Rail Road Bond, 1865: public domain. Source https://en.wikipedia.org/wiki/File:San_Francisco_Pacific_Railroad_Bond_WPRR_1865.jpg 50

My bond is my contract A bond is nothing more, nothing less than … a contract. Which lawyers model as a set of elements: • a party and a counterparty • offer & acceptance • consideration: • goods/services <-> money • terms and conditions 51

New Goal – reduce Contract to Bytes Contract at beginning, performance to follow Law first, accounting second → divide and conquer Goal reduced – convert terms & conditions legal-babble Into Tag-values, SQL, expressions, DSL, technobabble 52

Resistance level Clauses not clear, not standard, not even settled Rewrite the terms: • on a debacle… • because we can… • hide clauses in fine print… No two bonds were alike. Conclusion – impossible to convert directly... 53

The War of the Wordsmiths What to do? • Get rid of the wordsmiths? Not likely… • Train the wordsmiths? Ditto... • Use algebra to convert? No: • vagueness, uncertainty, unpredictability… efficient! • Subsets? No, it was all equally important / not important • Duplicate prose with bytes? • not good if contracts are a weapon… What’s left? Simplify …. 54

Lightbulb - The Contract IS the Issue Flip the logic upside down • keep prose document as is • let the program extract its parts from document • place the users -issuer+holder- first • and the developer second As developer, I don’t need to convert the bond 1. capture into signed digital document 2. read out 10 or so values 3. identify the document for accounting Light bulb from Edison Patent 223,898, 1880: public domain. Source https://en.wikipedia.org/wiki/File:Light_bulb.png 55

1. How to sign a digital, readable doc PGP showed us how to doc-sign as a Feature: • clear start line • clear start of Sig • signature block (PGP was the 1990s email encryption program) signed PGP message by OpenBazaar: Creative Commons Attribution 4.0 International 56

2. How to read values - Markup 57

58

3. Identifying my Bond How to identify the document? • Dematerialisation → get rid of paper → automate everything • IT trend to automation → must ‘allocate’ a number • Allocation for bonds → registry? • National? International? for bonds? derivatives? • Costs, admin, delay, rules, death by a thousand cuts… This is not the open entry, no barriers market I wanted! 59

3. The Hash as identifier PGP again provided the clue cryptographic message digest or Hash Turns any ‘document’ into number: 1Q2TWHE3GMdB6BZKafqwxXtWAWgFt5Jvm3 (Hal Finney’s Bitcoin account) Hashes are: • Secure, unique, global, free • 1:1 with your document 60

The Ricardian Contract 61

The Ricardian Contract • Captures any legal prose contract • any financial deal • no harder to read or write than any other contract • (too) brutally honest • not good for hiding intent • Signed and Hashed • self-identifying, self-verifying • hash makes participation in any digital agreement trivial • add keys & server locs for self-assertion, self-routing • Easy to implement – 1000 lines of code 62

Ext 1 - Contracting • One Riccy can: • include another Riccy (OpenTransactions) • refer to another Riccy by hash • Use the form for any purpose • config, params, packets (OT) • Internet shopping (OpenBazaar) 63

Ext 2 - Complexity Code - as text - but what about binary? Prose - as text - but what about Masters, Annexes? Simple answer - refer to code, text by hash - in params Ricardian triple: { Prose, Params, Code } Can manage anything: blockchains, smart contracts, identities, IoT, network objects 64

The Future -1-3 Barclays’ Smart Contract Templates browser, 2016 1.Implementing the triple – R3’s Corda 2.Jurisprudence: Enforceability? Admissability? Precedent? Dispute Resolution? 3. Contract browser – Barclays’ Smart Contract Templates 65

The Future - 4 4. Prose versus Code • duplication versus sole coverage • verify conformance between code and prose • derive code from prose or v.v.? • insert code into prose or v.v.? • tight couplings of code function <-> prose clause who’s right? 66

References David Chaum (1983) "Blind signatures for untraceable payments," 1983 Advances in Cryptology, Crypto 82 (3): 199–203. Bryce “zooko” Wilcox-O’Hearn (2001) “Names: Decentralized, Secure, Human-Meaningful - Choose Two.” Marc Steigler (2005) “An Introduction to Petnames,” http://www.skyhunter.com/marcs/petnames/IntroPetNames.html Chris Odom (200x?) "Open-Transactions: Secure Contracts between Untrusted Parties", http://www.opentransactions.org/open-transactions.pdf Chris Odom, "Sample Currency Contract", http://opentransactions.org/wiki/index.php/Sample_Currency_Contract Washington Sanchez (2014) “Ricardian Contracts in Open Bazaar,” https://gist.github.com/drwasho/a5380544c170bdbbbad8 Nick Szabo (1994) “Smart Contracts”, http://szabo.best.vwh.net/smart.contracts.html Ian Grigg (2004) “The Ricardian Contract,” IEEE 1st Workshop on Electronic Contracting, http://iang.org/papers/ricardian_contract.html Mark S. Miller, Chip Morningstar, Bill Franz, (2000) “Capability-based Financial Instruments - an Ode to the Granovetter Operator.” Financial Cryptography 2000, Anguilla Jörg F. Wittenberger (2002) “Askemos - a distributed settlement,“ http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.11.5050 Lee Braine (2016) “Barclays’ Smart Contract Templates,” Barclays London Accelerator 2016, The O2, http://www.ibtimes.co.uk/barclays-smart-contract-templates-heralds-first-ever-public-demo-r3s-corda-platform-1555329 and https://vimeo.com/168844103 67

Smart Legal Contracts: Prose, parameters, code Dr. Chris Clack Senior Lecturer, University College London 68 68

Smart Legal Contracts: Dr. Christopher D. Clack Prose, parameters, code The Centre for Blockchain Technologies Department of Computer Science University College London Consultant to Barclays Presentation to R3 Smart Contract Templates Summit 29 June 2016 69

Contents  Smart Contract Templates  Legal Prose, Parameters, Code and their Evolution  Potential Roadmap  CLACK Language  Discussion Points 70

Smart Contract Templates  A template is an  An agreement is a fully- electronic representation instantiated template of a legal contract (eg (including any customised issued by a standards legal prose and parameters) body) 71

Agreements – Parameters and Legal Prose  The legal contract includes both prose and parameters  Parameters provide the link from prose to code  A parameter might be named in one document, given a value in a second document, and used in a third document  An agreement can be understood in two ways:  it specifies operational details of actions to perform  it specifies non-operational details of rights and obligations 72

Evolution of Parameters and Legal Prose Example of prose linked to base type parameter Example of prose linked to higher order parameter 73

Evolution of Code Example of common utility function: valuation function for derivative Example of common business logic: global liquidity rules for cash sweeping 74

Long-term Research • Source language which can be compiled • Structured source language which to both legal prose and executable code is itself admissible in court • Compiled legal prose is admissible in • Language can be compiled into court executable code 75

Potential Roadmap 76

CLACK Language  Common Language for Augmented Contract Knowledge (“CLACK”)  Specifies document containers (for legal prose, parameters, etc), library objects, etc  Assists design and implementation of Smart Contract Templates  Academic paper to be published  Will be available at http://clacklang.org/ 77

Discussion Points • Would higher order parameters be useful? • What is the constraint for the roadmap: computer science or law? • How long until a source language could generate both admissible legal prose and executable code? Any preferences for research directions? • How long until an admissible source language could also generate executable code? Any preferences for research directions? 78

Shared Ledger Architectures Introduction Richard G Brown Chief Technology Officer, R3 79

80

81

82

Consensus Versailles - 1919 : licensed under Creative Commons Attribution-Share Alike 2.0 Generic Credit to https://www.flickr.com/photos/nostri-imago/3449948513 83

Validity XHTML : This file is ineligible for copyright and therefore in the public domain because it consists entirely of information that is common property and contains no original authorship Credit to https://commons.wikimedia.org/wiki/File:Valid_XHTML_1.0.svg 84

Uniqueness Snowflake : licensed under Public Domain Credit to https://en.wikipedia.org/wiki/Snowflake 85

Immutability Medusa Gorgon : licensed under the Creative Commons Attribution-Share Alike 2.0 Generic Credit to https://commons.wikimedia.org/wiki/File:Mask_of_the_Gorgon_Medusa,_dating_from_c._130_AD_and_found_in_the_Forum_Romanum_in_Rome,_Romisch- Germanisches_Museum,_Cologne_(8115605754).jpg 86

Authentication 87

“I know that what I see is what you see…" • Consensus • Validity … the “blockchain menu” • Uniqueness • Immutability • Authentication 88

Architectural Considerations for Smart Contract Templates Nick Palmer Investment Bank Lead Architect, Barclays 89

           91

            92

Priorities for Smart Contract Templates Clemens Wan Associate Director, R3 93

Standards Bodies Academia (Computer Science, Law) Document Automation Priorities for Architecture Smart Contract Templates? Legal Shared Ledgers 94

Summary of Key Points from the Summit Clemens Wan Gavin Thomas Associate Director, R3 Tech COO, R3 95

Next Steps Dr. Lee Braine Investment Bank CTO Office, Barclays 96

Networking and drinks (London only) 97