2. Some of the values identified as “parameters” in the agreement (and in the template) may not have an operational impact and therefore should not be included in the set of execution parameters. 3. It is possible for a parameter to be defined (given a name) in one document, given a value in a second document, and used (e.g. in business logic) in a third document. Although parameters need not have values in a template, they must have values in a signed agreement. All of an agreement’s parameter values are a critical part of the contract as they directly reflect the business relationship between parties and those that are execution parameters influence the operation of the contract. 3.2 The design landscape for Smart Contract Templates In this section, we consider the possible areas for future development of Smart Contract Templates. We do this by considering three distinct areas of development relating to: (i) the sophistication of parameters, (ii) the standardisation of code, and (iii) long-term research. We conclude by sketching a roadmap for future development. 3.2.1 Increasing the sophistication of parameters Mostparametersinexistinglegal document templates have simple types, such as date, number, etc. These are “base” or “primitive” types8 and, as an example, Figure 3 illustrates the identification of a date in a master agreement; once highlighted and annotated, the name (“AgreementDate”), type (“Date”) and value (“16-Mar-2016”) of this parameter will be passed to the executable code. Figure 3: From a Barclays demonstration of Smart Contract Templates: an editor permits a date in the legal prose to be highlighted, and then annotated to denote a simple parameter. The parameter has a name “Agreement Date”, type “Date” and value “16-Mar-2016”. It is not necessary for parameters to be restricted to base types. It is very likely that values of more complex types, such as lists, will also need to be transferred to the executable code. The passing of parameters to the executable code is necessary because of the desire to use standardised code. It would, for example, be theoretically possible to generate entirely new code for every trade and in this case there would be no need for parameters. The number of parameters, and the complexity of the types of those parameters, will typically increase as the code becomes more generic. Beyond parameters with base types and more complex types such as lists, parameters can also be expressions containing references to other parameter names. Unless those other 8https://en.wikipedia.org/wiki/Data_type 8