• It should provide support for both legal prose and parameters. • It should support different internal structured formats, such as XML. • It should support the output of execution parameters in a variety of formats, such as FpML. • It should support contracts that comprise multiple documents. • It should manage multiple agreements being instantiated from a single template (and hierarchies of templates). • It should permit parameters to be defined in one document, given a value in a second document, and used in a third document. • It should support a wide range of parameter types, including higher-order parameters. • It should support increasing standardisation and sharing of common code. • It should support multiple execution platforms. • It should support full interaction with, and increasing automation of, legal prose. • It should support Ricardian Contracts, and therefore for example it should support digital signing of contracts, the construction of a cryptographic hash of the contract, and the use of that hash as an identifier for reference and recovery of the smart contract. It is a significant challenge to ask a single specification language to do all of the above. We aim to report on progress in a subsequent academic paper, including an abstract syntax and concrete examples. 4 Summary and Further Work 4.1 Summary This paper began by considering four foundational topics regarding smart contracts: terminology, automation, enforceability, and semantics. We defined a smart contract as an agreement whose execution is both automatable and enforceable. We viewed legal contracts within a simple semantic framework as having two interpretations: the operational semantics concerning execution of the contract and the denotational semantics concerning the non- operational legal interpretation of the contract. We then described templates for legally-enforceable smart contracts as electronic representations of legal documents containing prose and parameters (with each parameter comprising an identifier, a type and an optional value). Agreements are then fully-instantiated templates (with all parameters having values), including any customised legal prose and parameters. By also selecting the appropriate smart contract code, this approach results in the creation of Ricardian Contract triples. The design landscape was then explored including increasing the sophistication of parameters from base types to complex higher-order types to business logic that could be admissible in court and potentially replace the corresponding legal prose. We also explored increasing the use of common standardised code through greater sharing, evolving from 13