2nd R3 Smart Contract Templates Summit (All Slides)

The Second R3 Smart Contract Templates Summit 16 November 2016 London and New York UNRESTRICTED

Agenda UNRESTRICTED 2

NY LDN NY LDN 08.00 13.00 Arrival and breakfast / 10.30 15.30 Languages and Sofus Mortensen, light lunch abstraction layers to Chief Quantitative Analyst, support the adoption Nordea Markets 08.30 13.30 Welcome. Agenda and Todd McDonald of smart contracts goals for the summit Co-Founder, R3 Robin Green, Executive Director, Digital Markets Innovation, CIBC Capital 08.40 13.40 Smart contract Dr. Lee Braine Markets templates: progress Investment Bank CTO 11.00 16.00 Dispute resolution Isabelle Corbett, Office, Barclays for smart contracts Senior Counsel, R3 08.55 13.55 Smart contract Dr. Chris Clack templates: Senior Lecturer, University Matt Britton, Consultant, R3 requirements and College London Ian Grigg, Consultant, R3 abstract specification 11.25 16.25 Conceptualizing Aaron Wright 09.15 14.15 ISDA: distributed Clive Ansell smart contracts Cardozo Law School ledger technology and Head of Market 11.50 16.50 Can smart contracts Sean Murphy smart contracts – the Infrastructure and be legally binding Partner, Norton Rose future of derivatives Technology, ISDA contracts? Fulbright processing? 12.15 17.15 Summary of key Gavin Thomas points from the Tech COO, R3 09.35 14.35 Smart contracts for Simon Puleston Jones summit cleared derivatives Head of Europe, FIA 12.20 17.20 Next steps Dr. Lee Braine Investment Bank CTO 09.55 14.55 Experimental oracle for Mark Raynes Office, Barclays Corda Blockchain Developer, 12.30 17.30 Close Thomson Reuters 17.30 Networking and drinks 10.15 15.15 Coffee break (London only) UNRESTRICTED 3

Summit goals Todd McDonald Co-Founder, R3 UNRESTRICTED 4

Summit goals Elicit views and opinions on standards for representing smart legal agreements Share leading edge thinking on smart contract languages and future implementations Engage with a broad spectrum of financial industry participants Drive open innovation through collaboration UNRESTRICTED 5

Smart contract templates: progress Dr. Lee Braine Investment Bank CTO Office, Barclays UNRESTRICTED 6

Smart contract templates: progress Lee Braine, Investment Bank CTO Office 16 November 2016 Presentation at The Second R3 Smart Contract Templates Summit London and New York UNRESTRICTED 7

Contents 1. Internal Team in Barclays Accelerator 2. First summit 3. First research paper 4. Second summit 5. Second research paper 6. Publicly available materials 7. Questions UNRESTRICTED 8

1. Internal Team in Barclays Accelerator – January to April 2016 Introduction Demo Day Complex challenge – each bank maintains it own Aim – showcase a vision of the future: the lifecycle of a separate ledgers and systems, huge duplication of “smart” standardised financial product effort and cost Software demo – prototype web application to edit Solution – shared ledgers and smart contracts templates, edit agreements, enter trades, affirm trades, Piece in jigsaw puzzle – smart contract templates and view trades Our focus – legal document templates to facilitate History in the making – first public demo of prototype smart contracts application on R3’s prototype Corda platform • connect legal text to business logic, simplify Venue – The O2 in London, audience of 800, largest legal documentation processes FinTech demo day ever anywhere • drive standards adoption via reusable Collaboration – Barclays Investment bank, R3, University templates College London, ISDA, Société Générale, Techstars • mutualise costs via common components General benefits – cost reductions, efficiency improvements, risk reductions UNRESTRICTED 9

Internal Team in Barclays Accelerator – software demo UNRESTRICTED 10

2. First summit The R3 Smart Contract Templates Summit • held in London and New York in June 2016 • presentations by R3, Barclays, ISDA, University College London and Norton Rose Fulbright • over 60 participants from over 20 organisations UNRESTRICTED 11

3. First research paper Smart Contract Templates: foundations, design landscape and research directions • position paper presenting vision • foundations (terminology, automation, enforceability, semantics), e.g.: “A smart contract is an agreement whose execution is both automatable and enforceable. Automatable by computer, although some parts may require human input and control. Enforceable by either legal enforcement of rights and obligations or tamper-proof execution.” • design landscape (parameter sophistication, code commonality, long-term research) • joint Barclays-UCL authorship • publicly released in August 2016 ert UNRESTRICTED 12

Design landscape Evolution of legal prose and parameters PDF/Word Prose linked to Prose linked to All contract Computer base type Computer higher order Law business logic as documents Science parameters Science parameters higher order parameters Evolution of code sharing Different across Standardisation Common Standardisation Common banks utility functions business logic Long-term research Source Admissible Language Source Language Code Legal Computer Science Computer Science Prose and Law and Law Code Legal Code Prose UNRESTRICTED 13

4. Second summit The Second R3 Smart Contract Templates Summit • held in London and New York in November 2016 • presentations by R3, Barclays, CIBC, Nordea, ISDA, FIA, Norton Rose Fulbright, University College London and Cardozo Law School UNRESTRICTED 14

5. Second research paper Smart Contract Templates: requirements and abstract specification • explores initial requirements, basic agreements, and extended agreements • focuses on key data structures to support smart legal agreements • joint Barclays-UCL authorship • to be publicly released in December 2016 Consider the Ricardian Contract triple: ricardian-contract → prose parameter * code prose → prose-element * prose-element → markup | text parameter → name type value * = zero or more 15 UNRESTRICTED

6. Publicly available materials Smart Contract Templates at Video https://vimeo.com/168844103 Barclays Accelerator Demo Press article http://www.ibtimes.co.uk/barclays-smart-contract-templates-heralds-first-ever-public- Day demo-r3s-corda-platform-1555329 Press article http://www.coindesk.com/barclays-smart-contracts-templates-demo-r3-corda/ The R3 Smart Contract Slide deck http://r3cev.com/s/R3-Smart-Contract-Templates-Summit-_FINAL.pdf Templates Summit Press release https://r3cev.com/press/2016/7/13/press-release-r3-led-industry-group-investigating- smart-contract-templates-for-blockchain-inspired-platforms Press interview http://www.ibtimes.co.uk/r3-extends-collaboration-smart-contract-templates-summit- 1570121 Article https://www.burges-salmon.com/news-and-insight/legal-updates/key-themes-from- the-r3-summit-on-smart-contract-templates/ Smart Contract Templates: Research paper https://arxiv.org/pdf/1608.00771.pdf foundations, design landscape Press article http://www.coindesk.com/barclays-collaboration-sets-forth-vision-smart-contracts- and research directions future/ Legally-Enforceable Smart Video https://www.youtube.com/watch?v=IHAT7zCzIhM Contracts Press article http://www.ibtimes.co.uk/legally-enforceable-smart-contracts-debated-london-fintech- week-2016-1572084 The Second R3 Smart Contract Slide deck To be made publicly available in November 2016 Templates Summit Smart Contract Templates: Research paper To be made publicly available in December 2016 requirements and abstract specification UNRESTRICTED 16

7. Questions “It will take time to build, but the potential benefits are enormous” “Further collaboration is required; it needs industry behind it” UNRESTRICTED 17

Smart contract templates: requirements and abstract syntax Dr. Chris Clack Senior Lecturer, University College London UNRESTRICTED 18

Smart Contract Templates: Dr. Christopher D. Clack requirements and abstract The Centre for Blockchain Technologies Department of Computer Science specification University College London Consultant to Barclays The Second R3 Smart Contract Templates Summit 16 November 2016 UNRESTRICTED 19

Contents  Smart legal agreements  Requirements sine qua non  Defining formats for storage and exchange  Smart legal agreement – basic and extended  Complex smart legal agreements  Discussion points  Next steps UNRESTRICTED 20

Smart legal agreements  The legal contract includes both prose and parameters  Parameters provide the link from prose to code  Parameters are embedded in the prose – they must be identified and passed to the code  Key question: what are the requirements for supporting smart legal agreements? UNRESTRICTED 21

Requirements sine qua non  Methods for creating and editing smart legal agreements  Standard formats for storing, exchanging, and retrieving smart legal agreements  Methods to add signatures to smart legal agreements  Methods to link the legal prose and the smart contract code  Methods for making smart legal agreements available to dispute resolution processes UNRESTRICTED 22

Defining formats for storage and exchange  Used for:  storage and retrieval  exchange between counterparties  Standard formats will facilitate common semantics, automated procedures, and development of tools by technology vendors  There could potentially be different standard formats for different categories of financial products (derivatives, trade finance, etc.)  Key question: can communities define abstract specifications that capture the core requirements, from which concrete standards could be derived? UNRESTRICTED 23

A smart legal agreement – basic  “basic” = a single document Header  Digital representation of legal prose  simple formatting (bold, italic, …)  simple way to identify embedded parameters (with name, type & value) Legal Prose  Extended with a header for administrative convenience  contains data not in prose (e.g. document identifier, hash) UNRESTRICTED 24

A smart legal agreement – basic Illustrative example abstract syntax: smartLegalAgreement : header prose header : Date* Signature* InstantiatedSmartContractID? DocHash? DocID prose : proseSection+ proseSection : presentationalMarkup? parameter? Text presentationalMarkup : PresentationalStyle* parameter : ParameterName ParameterType ParameterValue UNRESTRICTED 25

A smart legal agreement – extended  Structured semantic markup Header  bidirectional references (active links)  clause semantics (for analysis)  clause hashing (for standard clauses) Extended Legal Prose  Structured prose  names, lists, tables, optional clauses  Extended parameters References  execution, nonexecution, analytic  arrays, expressions UNRESTRICTED 26

Complex smart legal agreements  Grouping of multiple documents (parts of Header legal agreement, plus other documents) Header  Bidirectional references between documents Legal Prose Header  Distributed binding Legal Prose Extended Legal  define parameter “X” in Document A References Prose (links)  give parameter a value in Document B References (links)  refer to the name/value in Document C References (links)  Extended header  edit history, versions  document status, group status  parent-child hierarchies UNRESTRICTED 27

Discussion points • Should the abstract syntax be accompanied with an abstract semantics, to facilitate automated checking and analysis? • Should there be a generic abstract syntax (and semantics?) that is applicable across the whole of law? - or focused on just financial agreements? - or focused just for one business area? • What are the constraints for development of common abstract syntaxes? • Any preferences for academic research directions? UNRESTRICTED 28

Next steps • Develop a “straw-man” abstract syntax • Publish the second academic research paper • Explore different concrete implementations • Develop an abstract semantics, to facilitate automated checking and analysis • Explore the genericity of the abstract specification • Explore the use of semantic markup to assist workflow UNRESTRICTED 29

Distributed ledger technology and smart contracts – the future of derivatives processing? Clive Ansell Head of Market Infrastructure and Technology, ISDA UNRESTRICTED 30

November 16, 2016 London/New York Distributed Ledger Technology and Smart Contracts – The Future of Derivatives Processing? Clive Ansell Head of Market Infrastructure and Technology ISDA ®ISDA is a registered trademark of the International Swaps and Derivatives Association, Inc. 31 UNRESTRICTED Copyright © 2016 International Swaps and Derivatives Association, Inc.

ISDA Whitepaper • The Future of Derivatives Processing and Market Infrastructure https://www2.isda.org/functional-areas/infrastructure-management/market-infrastructure-and-technology/ • Current infrastructure challenges • The need for change • Opportunities for Technology and Standardisation UNRESTRICTED 32

Primary Challenge – Complexity • Reduces efficiency • Increases cost • Creates operational risk • Challenges for regulatory compliance UNRESTRICTED 33

A High Level Generic Process Flow UNRESTRICTED 34

An Extract of Reality UNRESTRICTED 35

Opportunities for Technology and Standardisation • Standardisation • Process – operating models and interactions • Data – identifiers and formats • Documentation – umbrella/master and product • Collaboration • Counterparties, Infrastructures, Vendors, Regulators • Solicit views to ensure end state is suitable for all • Technology • FinTech • RegTech • Smart Contracts UNRESTRICTED 36

ISDA – A Trade Associations Role • Member reach – facilitate participation and dissemination: • Across multiple market segments • Globally • Provide access to expertise - leveraging existing working group structures: • Asset class – credit, rates, equity • Functions – trading, reporting, confirmation, settlement • Discipline – business, legal, operations and technology • Connect thought leaders • Facilitate integration of legacy and next generation environments • A standards body UNRESTRICTED 37

Other Considerations • FpML as a basis for financial derivatives Smart Contracts • The relationship between Smart Contracts and Distributed Ledger Technology • What is the goal – agreeing primary objectives and limitations • How do we get there – a plan for adoption 38 UNRESTRICTED

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. UNRESTRICTED 39

Smart contracts for cleared derivatives Simon Puleston Jones Head of Europe, FIA UNRESTRICTED 40

16 November 2016 Smart Contracts for Cleared Derivatives Simon Puleston Jones, Head of Europe UNRESTRICTED 41

Overview • The punchline • The context: what are “Cleared Derivatives”? • Industry standard legal documentation for Cleared Derivatives • The challenges of implementing Smart Contracts for Cleared Derivatives UNRESTRICTED 42

Conclusion • Smart contracts are an important technical innovation that will increasingly be employed for both relationship documentation and trades in OTC markets • Smart contracts are a viable tool for contract creation when using the FIA Terms of Business to document a clearing broker’s relationship with its client • The platforms used to build such contracts can be integrated into other enterprise systems, to assist with the capture, analysis and monitoring of such contracts • Self-executing contracts are not yet viable for client cleared derivatives, due to the level of discretion afforded to the client, the clearing broker, the clearing house and regulatory authorities in the context of a cleared derivatives transaction • We encourage the industry and vendors alike to consider further whether the current challenges in applying smart contracts to cleared derivatives are surmountable in a scalable way and, if so, how UNRESTRICTED 43

What are “Cleared Derivatives”? UNRESTRICTED 44

What is clearing and why is it important? • We run a day-long seminar called “Clearing in a Day” that answers these two questions in detail. It is aimed primarily at those coming into the cleared derivatives industry for the first time • Clearing is the process of a clearing house intermediating a buyer and a seller, with the aim of protecting each of the buyer and the seller from the other’s default and ensuring settlement of their financial obligations to one another • Clearing replaces direct counterparty credit risk with CCP credit risk and mutualised clearing member risk, which is mitigated by regulator independent initial and variation margin calls • Clearing involves risk margining, reporting, the netting of trades into single positions, tax handling, failure handling and, for many clearing houses, compression - it also provides for standardised expiry and delivery processes • From a product perspective, “Cleared derivatives” covers futures, exchange traded options, swaps, certain commodities, repos and other derivatives that are intermediated by a clearing house UNRESTRICTED 45

Why is clearing important? Pittsburgh G20 Leaders Summit 2009 communiqué: “All standardised OTC derivative contracts should be traded on exchanges or electronic trading platforms, where appropriate, and cleared through central counterparties by end-2012 at the latest. OTC derivative contracts should be reported to trade repositories. Non-centrally cleared contracts should be subject to higher capital requirements.” UNRESTRICTED 46

Clearing of OTC derivatives in Europe UNRESTRICTED 47

Executing/Clearing an OTC interest rate swap THE ORIGINAL OTC TRADE Fixed Rate Party A ISDA Master Agreement + Schedule (+CSA?) Party B (Buyer) (Seller) Floating Rate BECOMES CLEARED AS FOLLOWS Fixed Rate Fixed Rate Party A CCP Rulebook CCP CCP Rulebook Party B (Buyer) (Seller) Floating Rate Floating Rate UNRESTRICTED 48

Executing/Clearing an OTC interest rate swap OR, IF PARTY A IS NOT A MEMBER OF THE CCP BUT PARTY B IS A CLEARING MEMBER: THE ORIGINAL OTC TRADE Fixed Rate Party A ISDA Master Agreement + Schedule (+CSA?) Party B (Buyer) (Seller) Floating Rate BECOMES CLEARED AS FOLLOWS Fixed Rate Fixed Rate Fixed Rate Party A FIA ToBs + Clearing CCP Rulebook CCP CCP Rulebook Party B (Buyer) Clearing Module Broker (Seller) Floating Rate Floating Rate Floating Rate UNRESTRICTED 49

Margining of a cleared interest rate swap IF BOTH PARTIES ARE A MEMBER OF THE CCP AND PARTY A IS IN-THE-MONEY Initial Margin Initial Margin Party A CCP Party B (Buyer) (Seller) Variation Variation Margin Margin Default Fund CCP Default Default Fund Contribution Fund Contribution UNRESTRICTED 50

Margining of a cleared interest rate swap OR, IF PARTY A IS NOT A MEMBER OF THE CCP, AND PARTY A IS IN-THE-MONEY Initial Initial Initial Margin Margin Margin Party A Clearing CCP Party B (Buyer) Broker (Seller) Variation Variation Variation Margin Margin Margin CCP Default Fund Default Default Fund Contribution Fund Contribution Excess Initial Margin UNRESTRICTED 51

Who can default under a cleared interest rate swap Fixed Rate Fixed Rate Fixed Rate Party A Clearing CCP Party B (Buyer) Broker (Seller) Floating Rate Floating Rate Floating Rate - Party A - Clearing Broker - Clearing Broker’s settlement banks/custodians - CCP - CCP’s settlement banks/custodians - Party B UNRESTRICTED 52

The clearing of Exchange Traded Derivatives UNRESTRICTED 53

Executing an exchange traded derivative (e.g. a futures contract) for a client Party A Executing Trading Party B (Buyer) Order Broker Order Venue Order (Seller) Back to back arrangement between clearing broker and its client (Party A), governed by FIA Terms of Business, incorporating any rules mandatorily required by TV / CCP rulebook Clearing CCP Party B Broker Futures contract Futures contract (Seller) governed by TV / governed by TV / CCP Rulebooks CCP Rulebooks UNRESTRICTED 54

Clearing an exchange traded derivative (e.g. a futures contract) for a client Party A Executing Trading Party B (Buyer) Order Broker Order Venue Order (Seller) Back to back arrangement between clearing broker and its client (Party A), governed by FIA Terms of Business, incorporating any rules mandatorily required by TV / CCP rulebook Clearing CCP Party B Broker (Seller) Futures contract Futures contract governed by TV / governed by TV / CCP Rulebooks CCP Rulebooks UNRESTRICTED 55

Industry standard documentation for Cleared Derivatives UNRESTRICTED 56

Industry standard documentation? No industry standard • Exchange contract specifications for exchange traded derivatives • Clearing House rules for cleared derivatives • Documentation for indirect client relationship Industry standard documentation exists • FIA Terms of Business and ancillary modules for clearing broker’s relationship with direct client (although most firms currently diverge from the FIA template) • Documentation for direct client relationship • Bilateral trading and clearing terms for OTC derivatives: ISDA Master Agreement and ancillary modules • Regulatory disclosures and annexes UNRESTRICTED 57

Industry Standard Documentation? Direct Client’s Clearing Terms and House’s regulatory Rulebook disclosure Indirect Direct Clearing Clearing Client(s) Client Member House Clearing Member’s terms and regulatory disclosures UNRESTRICTED 58

Industry Standard Documentation - TODAY FIA Terms of ISDA Master Business Agreement + + Numerous Numerous modules to the modules to the FIA Terms of ISDA Master Business Agreement +? + FIA ISDA / FIA ISDA / FIA Clearing or Client Clearing Client Clearing Module Addendum Addendum UNRESTRICTED 59

Industry Standard Documentation - TOMORROW FIA Terms of Business + Numerous modules to the FIA Terms of Business UNRESTRICTED 60

The challenges of implementing smart contracts for cleared derivatives UNRESTRICTED 61

The promise of Smart Contracts • Simplify / electronify the process of contract creation • Increased standardisation of trading terms • Electronic execution • Immediate integration of legally binding contracts into documentation storage platforms and of the terms of those contracts into wider IT infrastructure that capture, analyse and monitor trade terms • Self-execution of contracts UNRESTRICTED 62

The challenges of Smart Contract implementation Simplify / electronify the process of contract creation • Two different things to solve for contractually: o The wider relationship between clearing broker and direct client (governed by the clearing broker’s Terms of Business); and o The terms of the trade being cleared (governed by a combination of such Terms of Business and the exchange/clearing house rules relating to the applicable derivative contract). • So, it’s not just a single, bilateral, relationship with a single set of terms • How do you capture the clearing house rules that are required to be incorporated into the Terms of Business between the clearing broker and the direct client? What should the effect of subsequent rule changes be and how do you incorporate those into the contract? • Regulations from around the globe form the bedrock of the legal agreements - after the date of entry into of the contract, how does a Smart Contract cater for changes in regulation that require changes to the contract? UNRESTRICTED 63

The challenges of Smart Contract implementation Increased standardisation of trading terms • The modular architecture of the FIA Terms of Business lends itself to standardisation of terms • Smart Contracts can be used to select the appropriate modules and then “fill in the blanks” within the clauses of the relevant module • If clients are willing to accept a more standardised offering, this can significantly decrease the time it takes to on-board a new client UNRESTRICTED 64

The challenges of Smart Contract implementation Electronic execution • In a global business, the ability to sign documents electronically may further reduce client on-boarding times • You still need to be comfortable that: o electronic execution is legally binding in all applicable jurisdictions; and o that the person purporting to execute the contract has power, capacity and authority to do so UNRESTRICTED 65

The challenges of Smart Contract implementation Immediate integration of legally binding contracts into documentation storage platforms and of the terms of those contracts into wider IT infrastructure that capture, analyse and monitor trade terms • This is an enormously useful feature of Smart Contracts: some clearing brokers will have hundreds of contracts with their client base, possibly thousands. This is an efficient way of establishing: o What contracts have you entered into? o When? o With whom? o On what terms? o To what extent do those terms deviate from the house template? o How many of those agreements contain a specific provision? UNRESTRICTED 66

The challenges of Smart Contract implementation Self-execution of contracts Discretion is the enemy of smart contracts. Clearing relies on discretion - a lot: • Clearing broker has discretion in how much margin to call the client for, and when • Default of the client: clearing broker has discretion in how, whether and when to close out the client, and what to do with the posted collateral • Default of the clearing broker: client has discretion as to whether to port their positions to a back up broker or close them out • Default of the clearing house: the clearing house management and regulators have significant discretion, that may impact the client/clearing broker relationship • The clearing broker can exercise discretion to change the terms of the trade in light of the actions of markets or regulators Further, unlike OTC derivatives, the relationship is not bilateral – what happens to the contract and trades under it are impacted by exchange rules and clearing house rules. UNRESTRICTED 67

The challenges of Smart Contract implementation Self-execution of contracts How do you: • Address the margining of the position, given the contract typically says, effectively, “you, the client, will pay much whatever margin I ask for, whenever I ask for it”? • Deal with the default of the client? • Deal with the default of the clearing broker, given the default management procedures of the clearing house will have a direct impact on what happens to the trade between the clearing broker and the client? • Ensure that your automated margin call mechanisms integrate into your client money/client asset compliance regime? • Document and operate margin transformation services? • Address cross-product margining? • Deal with set-off and indemnities? • Address post-trade regulatory change, to the extent it impacts on the derivatives entered into under the agreement? UNRESTRICTED 68

Other considerations • If a trade association establishes industry standard terms, does the entire industry have to use the same vendor? • What IT platform should be used? What if the two parties use different smart contract systems? • ETD markets are often accessed via a number of brokers and “long chains” are a common feature of ETD markets – how may smart contracts work harmoniously along the entire chain? • Some of these contracts (e.g. inflation swaps) might last 50 years – technology changes a lot in 50 years… • In the absence of a single industry standard language or platform for Smart Contracts, is it too early to standardise using Smart Contracts? UNRESTRICTED 69

Conclusion • Smart contracts are an important technical innovation that will increasingly be employed for both relationship documentation and trades in OTC markets • Smart contracts are a viable tool for contract creation when using the FIA Terms of Business to document a clearing broker’s relationship with its client • The platforms used to build such contracts can be integrated into other enterprise systems, to assist with the capture, analysis and monitoring of such contracts • Self-executing contracts are not yet viable for client cleared derivatives, due to the level of discretion afforded to the client, the clearing broker, the clearing house and regulatory authorities in the context of a cleared derivatives transaction • We encourage the industry and vendors alike to consider further whether the current challenges in applying smart contracts to cleared derivatives are surmountable in a scalable way and, if so, how UNRESTRICTED 70

Experimental oracle for Corda Mark Raynes Blockchain Developer, Thomson Reuters UNRESTRICTED 71

Experimental oracle for Corda The Second R3 Smart Contract Templates Summit Mark Raynes 16 November 2016 Blockchain Developer Applied Innovation UNRESTRICTED 72

Introduction • What is Thomson Reuters Applied Innovation? - Responsible for the exploration of emerging technologies - Currently looking at Blockchain, Cognitive Computing, IoT, Cloud, AR/VR and more - Also responsible for mobile application development for internal and external clients • What are we doing in this space? - Public/Blockchain Initiatives – BlockOne ID - Private/DLT Initiatives – Oracles, Corda (and others) • This presentation: - Provide an overview of oracles and how they relate to legal agreements - Provide an example of how an oracle takes part in a smart legal agreement - Propose a high level oracle architecture - Discuss key considerations and future work UNRESTRICTED 73

Oracles • Why do we need oracles? - All parties to an agreement must be able to independently arrive at the same result for a given transaction - We cannot ensure that external services will always return the same answer - We need trusted agents that can attest to certain facts by signing transactions that contain them • What can oracles do? - Act as a trusted source of data - Respond to defined queries - Sign data within a transaction - Act as a definitive model / valuation service - Act as a scheduler or notification service UNRESTRICTED 74

Oracles and Legal Agreements • Automatically establish key facts of agreement - Holiday dates - Current market prices • Automation of lifecycle events - Rate fixings - Maturity events • Ability to specify data sources up-front - Future interest rates will be provided by “ProviderX:RatesOracle” • Traceability - Results are signed and permanently committed to ledger UNRESTRICTED 75

Example – Floating Rate Loan Agreement • Governs a floating rate loan agreement between two parties • “LoanAgreement” object represents deal: - Payment terms – Immutable - Payment schedule – Mutable (via transactions) • Interest rate oracle is specified up-front - Would be possible to specify backup(s) • Utilises Corda’s in-built “TwoPartyDealProtocol” - Orchestrates rate fixings • Utilises Prototype Rate Fix Oracle - Provides interest rates and signs transactions UNRESTRICTED 76

Example – Floating Rate Loan Agreement • Agreement is mutated throughout its lifecycle via transactions • Corda platform ensures transactions are signed by the required parties UNRESTRICTED 77

Potential Architecture • Service Integration Layer - Abstracts communication with external data service - Manages sessions • Oracles - Support different use cases / workflows - Support different subscription patterns (e.g. request / response, publish / subscribe) - Provide appropriate behavior (e.g. caching/persistence, interpolation) • Protocols - Standard (e.g. interest rate fix, end-of-day pricing) - Proprietary (e.g. complex valuations) UNRESTRICTED 78

Potential Oracles • Market Pricing • Valuations - Intraday / End-of-Day - Evaluated pricing - Models / Analytics • Corporate Actions - Dividends • Reference Data - Earnings - Symbols / Identifiers - Capital changes - Industry classifications - Descriptive data - Calendars UNRESTRICTED 79

Key Considerations • Standardisation - Identifiers / Symbology - Protocols / Workflows - Encourage data providers to adhere to common interfaces - Terminology • Testing - TestNet presence - Simulators – Must be able to test against realistic data • Commercial Models - Must adhere to incoming license agreements 80 UNRESTRICTED

Future Work • Establish and understand requirements - Engage with market participants - Engage with standards bodies • Continue to experiment with Corda and other emerging platforms UNRESTRICTED 81

Questions? UNRESTRICTED 82

Coffee break UNRESTRICTED 83

Simpler OTC smart contracts Sofus Mortensen Chief Quantitative Analyst, Nordea Markets UNRESTRICTED 84

Simpler OTC Smart Contracts The Second R3 Smart Contract Templates Summit Sofus Mortensen 16 November 2016 UNRESTRICTED 85

Motivation • Reduce complexity of writing a new type of contract – Specification – Testing • Making OTC Smart Contracts accessible by business – Reading – Reasoning – Writing? • Reduce complexity of manual validation transactions UNRESTRICTED 86

The shoulders of giants: “Composing Contracts: an adventure in financial engineering” Simon Peyton Jones, Jean-Marc Eber, Julian Seward UNRESTRICTED 87

Smart Contracts – Corda’s approach - Actor proposes transaction - Transaction is validated against contract by network - Upon consensus transaction is final STATE Transaction STATE Transaction STATE Smart contract refers to the code that verifies transactions UNRESTRICTED 88

Smart Contracts – refining Corda’s approach Contract state is the contract Readable by both machines and humans STATE Transaction STATE Transaction STATE Implementation details for Corda: • Validation of transaction is still done in a “Super Smart Contract” that can interpret the state • The light weight contract found in the state is called Arrangement to avoid confusion UNRESTRICTED 89

Contract Examples Basics UNRESTRICTED 90

Debt Indicates beginning of light weight contract “highStreetBank” and “acmeCorp” are references arrange { to involved parties and are defined elsewhere highStreetBank.owes(acmeCorp, 100.K, GBP) } UNRESTRICTED 91

Zero coupon bond ACME Corp has the right to exercise after specified date arrange { actions { acmeCorp.may { "execute".givenThat(after("2018-06-01")) { highStreetBank.owes(acmeCorp, 100.K, GBP) } } } } UNRESTRICTED 92

Contract examples IR Caplet UNRESTRICTED 93

IR Caplet Placeholder for future LIBOR fixing arrange { actions { (acmeCorp or highStreetBank).may { "exercise".anytime { val floating = interest(notional, "act/365", fix("LIBOR", "2016-04-01", Tenor("6M")), "2016-04-01", "2016-10-01") val fixed = interest(notional, "act/365", 0.5, "2016-04-01", "2016-10-01") Calculation of interest on notional highStreetBank.owes(acmeCorp, floating - fixed, GBP) } } } } Note that debt obligation must be of positive amount. Hence exercise is only valid if floating leg is larger than fixed leg. UNRESTRICTED 94

IR Caplet Following transaction applying fixing from oracle arrange { actions { (acmeCorp or highStreetBank).may { Placeholder replaced with actual fixing "exercise".anytime { val floating = interest(notional, "act/365", 0.67, "2016-04-01", "2016-10-01") val fixed = interest(notional, "act/365", 0.5, "2016-04-01", "2016-10-01") highStreetBank.owes(acmeCorp, floating - fixed, GBP) } } } } UNRESTRICTED 95

IR Caplet Resulting state following exercise arrange { val floating = interest(notional, "act/365", 0.67, "2016-04-01", "2016-10-01") val fixed = interest(notional, "act/365", 0.5, "2016-04-01", "2016-10-01") highStreetBank.owes(acmeCorp, floating - fixed, GBP) } Reduces to obligation UNRESTRICTED 96

Contract examples IR Swap UNRESTRICTED 97

IR “Swaplet” Calculation of interest of floating and fixed leg. Floating leg uses placeholder for LIBOR fixing. arrange { val floating = interest(notional, "act/365", fix("LIBOR", "2016-04-01", Tenor("6M")), "2016-04-01", "2016-10-01") val fixed = interest(notional, "act/365", 0.5, "2016-04-01", "2016-10-01") Choice of exercise depends on which is larger, actions { (acmeCorp or highSteetBank).may { fixed or floating leg "exercise floating".anytime { highStreetBank.owes(acmeCorp, floating - fixed, GBP) } "exercise fixed".anytime { acmeCorp.owes(highStreetBank, fixed - floating, GBP) } } } } UNRESTRICTED 98

IR Swap Rollout of date sequence from September 2016 to 2017 with semi-annual frequency arrange { rollOut("2016-09-01", "2017-09-01", Frequency.SemiAnnual) { val floating = interest(notional, "act/365", fix("LIBOR", start, Tenor("6M")), start, end) val fixed = interest(notional, "act/365", Note placeholders for start and end date for interval 0.5, start, end) actions { (acmeCorp or highSteetBank).may { "exercise floating".anytime { highStreetBank.owes(acmeCorp, floating - fixed, GBP) next() } "exercise fixed".anytime { Links to next interval in date sequence acmeCorp.owes(highStreetBank, fixed - floating, GBP) next() } } } } } UNRESTRICTED 99

IR Cancelable Swap arrange { rollOut("2016-09-01", "2017-09-01", Frequency.SemiAnnual) { val floating = interest(notional, "act/365", fix("LIBOR", start, Tenor("6M")), start, end) val fixed = interest(notional, "act/365", 0.5, start, end) actions { (acmeCorp or highSteetBank).may { "exercise floating".anytime { highStreetBank.owes(acmeCorp, floating - fixed, GBP) next() } "exercise fixed".anytime { acmeCorp.owes(highStreetBank, fixed - floating, GBP) next() } } acmeCorp.may { “cancel”.anytime { acmeCorp.owes(highStreetBank, 10.K, GBP) } } ACME Corp can cancel the swap, paying a fee. } } Note absence of “Next”. Contract ends here. } UNRESTRICTED 100

Thank you! Sofus Mortensen [email protected] UNRESTRICTED 101

Languages and abstraction layers to support the adoption of smart contracts Robin Green Executive Director, Digital Markets Innovation, CIBC Capital Markets UNRESTRICTED 102

The Second R3 Smart Contract Templates Summit Languages and abstraction layers to support the adoption of smart contracts Robin Green Executive Director, Digital Markets Innovation, CIBC Capital Markets 16 November 2016 UNRESTRICTED 103

Introduction Question - Can we create a means to clearly define the business intent of a smart contract? Similar things have been done in other areas, for example: Web Page Design - HTML Create a table with one row and two cells. In the first cell put the word ‘hello’ and in the second put the word ‘world’

Abstracting Business operations Can we do the same for smart contracts? Would it be possible to have a platform independent, legally binding means of defining the operation of smart contracts. For example, would it be possible to have a Delivery vs Payment (DVP) contract defined by the following tag: The rights and obligations of all parties entering into this DVP contract, along with the operation of the contract would be defined in legally enforceable language. Why would this be useful? 1. It would allow parties to enter into a fully defined legal contract, without having to worry about the code implementation 2. The legal definition would only need to be made once when the Tag is initially created / defined. 3. Developers would have a very clear business definition that describes exactly how the contract should operate and what they should code, leaving no room for misinterpretation 4. Operation across ledgers, while complex, would become a purely technical problem. Both parties will be agreeing to identical versions of the legal agreement, tags and parameters; this will not (if correctly coded) be affected by the underlying ledger technology. UNRESTRICTED 105

Breaking the problem down – into layers When thinking about how we might put this approach into practice, it can be helpful to think of Smart Contracts that run on a distributed ledger as a layered model as in the table below. Each layer would be agnostic to the implementation in the layers above and below, but each layer would expose a set of distinct methods or properties that can be called by layers above. Smart Contract Layers 5 Tags 4 Choreography / Orchestration 3 Actions 2 Data 1 Ledger Services 0 Ledger UNRESTRICTED 106

Breaking the problem down – into layers Smart Contract Layers Layer 0 – Ledger 5 Tags An off-the-shelf unmodified ledger implementation. Could be Etherium, Corda etc... 4 Choreography / Orchestration 3 Actions Technically, this does not need to be a ledger, but merely a networked data store; the 2 Data Ledger Services layer would then have to implement all missing 'Ledger-like’ functionality 1 Ledger Services 0 Ledger UNRESTRICTED 107

Breaking the problem down – into layers Smart Contract Layers Layer 1 - Ledger Services 5 Tags The smart contract code will require some base functionality to operate - this could either 4 Choreography / Orchestration be provided natively by the ledger, or by trusted third parties that provide services on the ledger (the specific service provider could be specified as an input parameter in the contract 3 Actions definition). This functionality would likely include: 2 Data 1. The ability to enforce a guaranteed and provable state across multiple participants 1 Ledger Services 0 Ledger 2. Operations to support transactions between autonomous actors, e.g., ‘only do x when condition y has been met’. (Consensus, Notary & Semaphoring operations) 3. Escrow services 4. Content agnostic messaging service 5. Identity services UNRESTRICTED 108

Breaking the problem down – into layers Smart Contract Layers Layer 2 – Data 5 Tags Instruments, Cash, etc… In finance, these are likely to be existing FPML or FIX-based 4 Choreography / Orchestration definitions. 3 Actions 2 Data 1 Ledger Services 0 Ledger UNRESTRICTED 109

Breaking the problem down – into layers Smart Contract Layers Layer 3 - Actions 5 Tags Actions are the base level building blocks from which contacts are built. A common set of well 4 Choreography / Orchestration defined actions will be supported by all nodes on the ledger. 3 Actions 2 Data A defined protocol to describe inter-action communication 1 Ledger Services If we assume that two parties are running the ‘Exchange’ action, then at some point in the 0 Ledger process, the code running at Party 1 and at Party 2 will need to communicate – messages might include ‘Does Party 1 have the Assets’ and ‘What is the value of the asset being provided by Party 2. It is suggested that the messages and the wire format that represents the messages should be fully defined. Having a formal definition will: 1. Allow interoperability between different concrete implementations of code for a given action, i.e., the action is the same, but the underlying code is different. 2. Enable the long term goal of having different parties sitting on separate ledgers or other transactional systems, i.e., same as above; the action is the same, but the underlying code is different. 3. Help to decouple the underlying message protocol / fabric from business logic 110 UNRESTRICTED

Breaking the problem down – into layers Smart Contract Layers Layer 4 Orchestration & Choreography – linking things together 5 Tags It should be possible to build up more complex operations by combining actions and tags. 4 Choreography / Orchestration Before the DVP can take place, assets need to be loaded onto the ledger, and the identity of the actors needs to be confirmed. The following pseudo-code outlines the type of concept 3 Actions being considered 2 Data 1 Ledger Services var refToAssetA = 0 Ledger var refToAssetB= var identityOfPartyOne = var identityOfPartyTwo = It would also be useful to investigate properties of variables, e.g., refToAssetA.getValue(USD) refToAssetA.getOwner.getName() Control structures and conditional execution will also be required. UNRESTRICTED 111

Breaking the problem down – into layers Smart Contract Layers Layer 5 – Tags 5 Tags This is what the end user would see, agree to, and would be enforceable in a court of law. An 4 Choreography / Orchestration agreement could be as simple as ‘send party A some cash’, but could obviously become much more complex. A simplified tag may look as follows: 3 Actions 2 Data 1 Ledger Services The Choreography layer could be used to wrap / combine a number of tags and actions 0 Ledger together to create a new tag with inherited or extended functionality. UNRESTRICTED 112

Putting theory into practice Can we develop these ideas and solve a real world problem? Project Banff is looking at the Canadian Banker’s Acceptance market. Would it be possible to: 1. Define a set of tags that represent the legally binding transactions and obligations that make up the Banker’s Acceptance issuance process 2. Implement these tags using a layered approach, and thus begin to abstract the business / legal definition from the underlying technology 3. Represent the smart contract agreement in a form that is more understandable to a non-technical reader UNRESTRICTED 113

Dispute resolution for smart contracts Isabelle Corbett, Senior Counsel, R3 Matt Britton, Consultant, R3 Ian Grigg, Consultant, R3 UNRESTRICTED 114

Dispute Resolution for Smart Contracts Isabelle Corbett, Senior Counsel, R3 Matt Britton, Consultant, R3 Ian Grigg, Consultant, R3 The Second R3 Smart Contract Templates Summit 16 November 2016 Private & Confidential 115 UNRESTRICTED

R3 AWG. Legal & Dispute Resolution Frameworks SWG 1 2 As part of the wider R3 AWG , the Legal & Dispute Resolution Frameworks SWG looked at the following areas, predominantly on the architectural aspects: • User agreements • Legal enforceability of smart contracts • Dispute resolution • Handling of dispute resolution 1 AWG = Architecture Working Group 2 SWG = Sub-Working Group UNRESTRICTED 116

User Agreements. How much change is needed to accommodate DLT? • Agreements governing parties’ behavior and obligations to one another still must exist • Contracts with automated elements are still contracts and, therefore, subject to contract law • Contract law will likely not change as quickly as technology advances, so agreements must adapt UNRESTRICTED 117

User Agreements. Types of Agreements Required • Agreements must be in place that address the following questions: • What determines who is allowed to participate on a ledger? • What governs behavior on the ledger? • What governs transactions in a particular assets? • What sets forth the terms of transactions that parties agree to? • Who else is providing services to facilitate transactions and what are the obligations that attach to provision of those services? UNRESTRICTED 118

User Agreements. Next steps • Look at the agreements that exist today and determine how much those agreements need to change to accommodate the technology • Learn from currently existing electronic trading agreements • Explore the identity question as it relates to signatures • Continue dialogue with regulators • These must be done in parallel with the analysis of enforceability of smart contracts and the suitability of contracts for conversion into “smart contracts” UNRESTRICTED 119

Assumption. Disputes will happen UNRESTRICTED 120

Assumption. Disputes will happen Dispute UNRESTRICTED 121

Assumption. Disputes will happen • More or less frequently • More or less expensive Dispute Goal: to create certainty and confidence UNRESTRICTED 122

Handling disputes. How do we deal with them? UNRESTRICTED 123

Handling disputes. How do we deal with them? Dispute initiateDisputeResolution() pause() UNRESTRICTED 124

Handling disputes. How do we deal with them? Dispute Resolution Exhibit A Dispute initiateDisputeResolution() pause() UNRESTRICTED 125

Handling disputes. How do we deal with them? Dispute Resolution Exhibit A Ruling Dispute initiateDisputeResolution() restart() pause() or terminate() UNRESTRICTED 126

Dispute Resolution. What are the options? Between parties within legal system Courts Between parties with independent, Arbitration decision-making arbitrator Between parties with independent, Mediation non decision-making mediator Between parties only Negotiation UNRESTRICTED 127

Dispute Resolution. What are the options? Between parties within legal system Courts Between parties with independent, Arbitration decision-making arbitrator Between parties with independent, Mediation non decision-making mediator Between parties only Negotiation • Expert knowledge • Cross-border jurisdiction UNRESTRICTED 128

Dispute Resolution. What are the options? Between parties within legal system Courts Between parties with independent, Arbitration decision-making arbitrator Between parties with independent, Mediation non decision-making mediator Between parties only Negotiation • Expert knowledge • Cross-border jurisdiction UNRESTRICTED 129

Arbitration. How would this work? Could be a natural fit for the challenges around expert knowledge and cross-border jurisdiction. Examples: SWIFT, CME, ISDA, EDI & LCH UNRESTRICTED 130

Arbitration. How would this work? Could be a natural fit for the challenges around expert knowledge and cross-border jurisdiction. Examples: SWIFT, CME, ISDA, EDI & LCH What would we need? • Arbitration clause in the legal prose of the Smart Contract • Administration • Policy / set of rules • List of arbitrators and mechanism for selection UNRESTRICTED 131

Arbitration. The challenges 1. Being able to find the experts UNRESTRICTED 132

Arbitration. The challenges 1. Being able to find the experts 2. Scope of disputes Or UNRESTRICTED 133

Arbitration. The challenges 1. Being able to find the experts 2. Scope of disputes Or 3. Volume of disputes UNRESTRICTED 134

Conceptualizing smart contracts Aaron Wright Clinical Professor, Cardozo Law School UNRESTRICTED 135

The Second R3 Smart Contract Templates Summit Conceptualizing Smart Contracts Aaron Wright Clinical Professor, Cardozo Law School November 16, 2016 [email protected] UNRESTRICTED 136

WHAT IS A SMART CONTRACT • A condition facilitated via a blockchain with a high probability of execution • Enables code to operate autonomously from any one party • Not simply an automated legal agreement • Smart contracts have a range of potential applications UNRESTRICTED 137

Universe of Smart Contracts Legal Group Contracts Rules Machine-to- Machine Interactions UNRESTRICTED 138

SMART CONTRACTS AS LEGAL CONTRACTS • Like any code, smart contracts can be used to memorialize or effectuate conditions (promises) • Such a use is a subset of “computable contracts” or data-oriented contracts • However, promises memorialized using a smart contract can be designed such that they are more difficult to terminate and breach, if relying on a public and permissionless blockchain (i.e., “immutable” promises) • Because smart contracts can be designed in such a way that makes it difficult to halt the execution of code, they decrease the risk of non-performance and thus decrease monitoring costs 139 UNRESTRICTED

UNRESTRICTED 140

• Agreements can accept input from outside world, via “oracles” to create dynamic agreements that change economic terms based on real world events • Over a longer time horizon, smart contracts could help facilitate decentralized arbitration systems 141 UNRESTRICTED

• Code → potentially less ambiguous than words for verifiable facts • Code is modular, making it possible to break agreements into chunks which can be assembled by lawyers (or perhaps even AI systems) UNRESTRICTED 142

ENFORCEABILITY OF “SMART” LEGAL CONTRACTS • “Smart” legal contracts are not the first contracts to rely on data and promises memorialized in an electronic format • In the early 1960’s Ed Guilbert develops an electronic message format for sending information about cargo between Du Pont and Chemical Leahman Tank Lines. • 1965, the Holland- America steamship line begins sending trans-Atlantic shipping manifests using telex messages and converting the messages into tape that could be loaded into their computers • Today, over one hundred thousand companies in the United States use an EDI solution to communicate with their business partners. UNRESTRICTED 143

• Any electronic message is defined to be a “writing”' or “in writing” • Agreements expressly provide that the conduct of the parties pursuant to its terms shall evidence a course of dealing and a course of performance which has been accepted by the parties • Agreements bar parties from asserting estoppel in order to bar reliance upon the statute of frauds • Severability clause to provide courts with flexibility if asked to interpret an agreement • Courts have considered cases involving Master EDI agreements; none (based on my research) have been challenged on the basis of invalidity 144 UNRESTRICTED

ENFORCEABILITY OF AGREEMENTS ENTIRELY WRITTEN IN CODE • Answer in New York is largely “yes”; due to the E-Sign Act and New York Electronic Signatures and Records Act (ESRA) • E-Sign: • “a contract relating to such transaction may not be denied legal effect, validity, or enforceability solely because an electronic signature or electronic record was used in its formation.” 15 U.S.C. § 7001. • Electronic record defined as a “a contract . . . .generated . . . by electronic means.” 15 U.S.C. § 7006. • Electronic signature defined as “symbol[] or process, attached to or logically associated with a contract or other record . . . executed or adopted by a person with the intent to sign the record.” 15 U.S.C. § 7006. UNRESTRICTED 145

ENFORCEABILITY OF AGREEMENTS ENTIRELY WRITTEN IN CODE (CON’T) • ESRA: • “An agreement, promise, undertaking or contract, which is valid in other respects and is otherwise enforceable, is not void for lack of a note, memorandum or other writing and is enforceable by way of action or defense provided that such agreement, promise, undertaking or contract is a qualified financial contract” and (a) “there is . . . sufficient evidence to indicate that a contract has been made” or (b) “the parties thereto, by means of a prior or subsequent written contract, have agreed to be bound by the terms of such qualified financial contract from the time they reach agreement (by telephone, by exchange of electronic messages, or otherwise) on those terms.” N.Y. GOL § 5-701(b)(1). • Qualified financial contracts include: “a currency option, currency swap or cross-currency rate swap”; “a commodity swap or a commodity option (other than an option contract traded on, or subject to the rules of a contract market or board of trade)”; “a rate swap, basis swap, forward rate transaction, or an interest rate option”; “a security-index swap or option or a security (or securities) price swap or option.” N.Y. GOL § 5-701(b)(2). UNRESTRICTED 146

ENFORCEABILITY OF AGREEMENTS ENTIRELY WRITTEN IN CODE (CON’T) • ESRA: • Sufficient evidence, includes: (1) “evidence of electronic communication (including, without limitation, the recording of a telephone call or the tangible written text produced by computer retrieval), admissible in evidence under the laws of this state, sufficient to indicate that in such communication a contract was made between the parties”; or (2) a confirmation (communicated electronically) that isn’t objected to by the party sending the confirmation within a certain defined timetable (even if confirmation omits material terms of agreement). See N.Y. GOL § 5-701(b)(3). • Qualified financial contracts include: “a currency option, currency swap or cross-currency rate swap”; “a commodity swap or a commodity option (other than an option contract traded on, or subject to the rules of a contract market or board of trade)”; “a rate swap, basis swap, forward rate transaction, or an interest rate option”; “a security-index swap or option or a security (or securities) price swap or option.” N.Y. GOL § 5-701(b)(2). UNRESTRICTED 147

ENFORCEABILITY OF AGREEMENTS ENTIRELY WRITTEN IN CODE (CON’T) • Enforceability of purely electronic financial contracts buttressed by First Department’s decision in Naldi v. Grunberg, 80 A.D.3d 1, 12, 908 N.Y.S.2d 639, 646 (2010). • Court held that “E–SIGN's requirement that an electronically memorialized and subscribed contract be given the same legal effect as a contract memorialized and subscribed on paper is part of New York law.” • Broad language of E-Sign should be given effect at least in the First Department. 148 UNRESTRICTED

IMMUTABILITY • Are immutable contracts valid? Probably not. • A long held tenet of the law is that “[t]hose who make a contract, may unmake it.” Beatty v. Guggenheim Exploration Co., 122 N.E. 378, 387-88 (N.Y. 1919) (opinion of Cardozo, J.). • Contractual provision that purports to limit the enforceability of a subsequent modification generally deemed unenforceable. • Restatement (Second) of Contracts § 311 cmt. a (1979) (“The parties to a contract cannot by agreement preclude themselves from varying their duties to each other by subsequent agreement.”). UNRESTRICTED 149

IMMUTABILITY (CON’T) • By default, smart contracts arguably have an implied anti-modification provision, which may place the validity of certain smart legal contracts at risk. • Courts and law undergird all computable contracts, including smart contracts used to model legal agreements. Just because promises are memorialized in “code”; the law does not evaporate. • Courts have the authority to determine whether a party breached an agreement and remediate harm after the fact UNRESTRICTED 150

OTHER LIMITATIONS • Do we want entirely code-bases smart contracts? • In certain instances, there is value in keeping contracts open-ended or ambiguous, because it can provide flexibility to the parties while also cutting down on the time and expense of negotiation. • Even if smart contracts make it easier for parties to specify a greater number of possible states of the world, the cost of specifying these contingencies could surpass any gains that may result from such an exercise. • In many cases, it may be more cost-effective to address remote contingencies after the fact—and renegotiate or make further adjustments to an economic arrangement at that point in time—rather than negotiate them up font. UNRESTRICTED 151

Can smart contracts be legally binding contracts? Sean Murphy Partner, Norton Rose Fulbright UNRESTRICTED 152

Can smart contracts be legally binding contracts? Sean Murphy, Partner 16 November 2016 UNRESTRICTED 153

Will the answer involve new law? Smart contracts Smart “contract” raise issues the suggests a law has already contract – addressed: is that correct? • In the EDI context • Contractual impact of new methods of Will normal communicating (e.g. contractual email / the Internet) principles apply? • Electronic signatures UNRESTRICTED 154

Our research A legal review from across these regions: Canada UK Germany USA Europe France China South Australia Key questions: Africa • Can a smart contract give rise to a legally binding contract? • Does “follow-on” contracting give rise to a legally binding contract? The answers may sometimes depend on the model of smart contract used, the factual matrix and the applicable law UNRESTRICTED 155

Smart contracts: models Smart contracts lie on a spectrum Contract entirely Contract in code “Split” natural Natural language in code with duplicated language contract contract with natural language with encoded encoded payment version performance of mechanism 100% non-human Pe Autom Contract aspects rforma Code n ed at is ec UNRESTRICTED 156

Key findings of our research Electronic Electronic nature not problematic for many (but not all) jurisdictions in establishing status contractual formation Certainty as to contractual terms often a critical factor: can the code be understood Certainty by a party? of terms Smart contracts that merely automate a particular process but do not include (or operate in conjunction with) contractual terms may not satisfy such requirements Follow-on Follow-on contracting (by which a later, separate contract is brought about by contracting performance of an earlier smart contract) may not give rise to a legally enforceable contact in some jurisdictions Other technical Other technical requirements of the applicable jurisdiction’s law (typically requirements prescribed by legislation) may, in a few jurisdictions, be a potential impediment to legally binding contractual effect UNRESTRICTED 157

Some country-specific observations  Current legislative proposals to clarify the position USA  Key issues: (1) how the parties give assent to the terms; (2) what steps need to be taken to ensure courts ?t are satisfied parties have sufficient notice of the terms (usual rules will apply) ca  Current precedent indicates US courts may be open to the possibility of follow-on contracting rt  No legislation dealing with the issue specifically, but EU directive requires contracts can be concluded on UK electronically. Electronic nature unlikely to be relevant c  Usual rules concerning contract formation likely to apply ng  Limited authority to suggest follow-on contracting may be possible din bi Australia  Electronic Transactions Act 1999 facilitates electronic contracting and contemplates follow-on contracting yll  In other respects usual common law principles relating to formation apply ga  Currently a machine/software cannot declare intent (a requirement for contract formation) - human Le Germany behaviour is required. But is it possible that machine/software actions might be attributed to the person responsible  The more independently a smart contract acts, the less likely the necessary attribution would be UNRESTRICTED 158

Some country-specific observations  There are both enabling and limiting factors in French law in relation to smart contracts. French Civil Code France envisages possibility of contracting electronically ?t  But essential terms would need to be accessible and understandable by each party, and a technical ca mechanism must be available to express consent r t  China’s Electronic Signature Law facilitates electronic contracting. Also relevant will be China’s Contract Law on China  Where parties form contract by data messaging, either party may request option to sign letter of c conformation before conclusion of the contract. Such requirement could impact upon the efficacy of smart contracts in China ng  A smart contract may be considered a standard form contract, to which additional controls apply di  The Electronic Communications and Transactions Act 2002 gives communications via data messages the n same effect as non-electronic documents. Although the Act provides for formation of an contract by an bi South Africa electronic agent (which might include a smart contract), if the terms are not capable of being reviewed by a y natural person prior to the contract forming, a party interacting with an electronic agent is not bound ll  This means there must be an option to review the terms by a natural person, and to correct errors, before a ga contract is formed  Uniform Electronic Commerce Act 1999 facilitates electronic contracting, but silent in a number of respects Le in relation to smart contracts. Such aspects are determined by common law Canada  Among other things, establishing the requirement of reasonable notice in respect of computer code could be challenging  Also unclear whether follow-on contracts initiated by a smart contract could have binding legal effect UNRESTRICTED 159

The problem of enforceability If legally binding, the technology (especially in permissionless systems) may raise enforceability issues Reasons for this: No central Evidence administering authority and proof  Absence of administrator in permissionless  No obvious defendant (e.g. defective systems program logic or data corruption)  Lack of administrator decision could force  Pseudonymous nature of some transactions parties to court  Proof of existence or content of entirely electronic smart contract  Problems enforcing court judgment or arbitration award in relation to blockchain UNRESTRICTED 160

Is a dispute resolution (DR) mechanism the solution? Scope for parties Administering to agree procedure authority needs in smart contract protection from or blockchain entry dispute resolution terms? liability? A central Is the relevant administering blockchain authority with immutable? power to amend the blockchain? Blockchain Does the permissioned or mechanism need permissionless? to be different for Relevant different parties? factors UNRESTRICTED 161

What characteristics would a DR mechanism need? Delegation to  Provision in smart contract itself allowing delegation to arbitrator arbitrator  Could be triggered by both parties nominating the arbitrating entity Submission to  Provision in the underlying contract (say, the natural language contract arbitration in a “split” model) agreeing to submit disputes to arbitration  It should match delegation mechanism in smart contract  A pool of possible arbitrators Choice of  Administered centrally or via relevant blockchain arbitrator  Could include low level expert determination, or higher value arbitrators for complex disputes UNRESTRICTED 162

Contact Sean Murphy Partner, London Norton Rose Fulbright LLP T:+44 20 7444 5039 [email protected] UNRESTRICTED 163

UNRESTRICTED 164

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. UNRESTRICTED 165

Summary of key points from the summit Gavin Thomas Tech COO, R3 UNRESTRICTED 166

Next steps Dr. Lee Braine Investment Bank CTO Office, Barclays UNRESTRICTED 167

Networking and drinks (London only) UNRESTRICTED 168