Speaker 1: Hello, my name is Anetta, and I'm part of the Blockchain Presence Project at the University of Zürich. As part of my work, I analyze the legal framework of smart contracts. In the next few minutes, I would like to give you a quick and comprehensible overview about the current legal contractual challenges smart contract users and oracles face when using smart contracts. As the smart contract technology is very promising and therefore still very dynamic, this is just a general overview about the status quo. I refer to current research, definite legal rules and answers will need to be provided by legal practice. Specific cases need to be checked thoroughly, individually and according to applicable law with legal experts. In this video, we are going to quickly talk about some motivation for the topic, how a contract is concluded, and we will look at an applied case, including a blockchain oracle. Let's start by looking at a smart contract from the legal perspective. The term smart contract may be a little misleading. A smart contract on blockchain does not represent a legal contract. The smart contract itself only is an automated computer program, as long as we do not have the framework constituting a contractual relationship from a legal point of view. Smart contracts do underlie contractual law as they do have an impact on the real world and therefore human beings. Also, code is not necessarily law, as law contains many things that code cannot perform due to its deterministic nature, and code may contain unlawful clauses. In this section, we are looking at what contractual challenges and mannerisms smart contracts face. For a legal contract to arise, we need binding declarations of intent. In smart contracts, such declarations of intent are given by performance. This would be the case if a party interacts with a smart contract. Also, for a legal contract to arise, we need to be able to identify the contractual parties that are involved in the legal contract containing the smart contract. We are looking at the case where a contract would be concluded on-chain, where the party's declarations of intent are transmitted electronically. Such a declaration of intent, therefore performance, can be declared by a human directly, for example, through a transaction directly triggered by an externally owned address. It could also be declared by a smart contract instructing another smart contract to send a transaction. This would be an automated declaration of intent, which is electronically generated. In this case, the performance, and therefore the declaration of intent, is accountable for the party triggering a smart contract to perform. Due to the deterministic nature of smart contract code, everything in the smart contract setting traces down to the act of a human or a group of humans. This simplifies identifying the party declaring intent in theory, but it is a challenge to trace and identify the involved humans, especially if a decentralized autonomous organization is involved, due to the anonymity we face on blockchain. If parties do not lay open their identities to one another, it is hard to enforce claims in the real world that may arise due to malicious execution or even fundamental different circumstances. Smart contract code is also a relevant topic when looking at whether or not a contract formed by interacting with a smart contract is legally binding. It has been argued whether the lack of understanding of code is a problem, as parties may plead a fundamental error in the forming of their declaration of intent as they do not understand the contract language. Anyway, researchers like Weber and Collards and Heckman argue that parties that use a smart contract agree with the fact that the smart contract code is purely the contract language and therefore the contract would still be binding. This reasoning would not be applicable for cases where the outcome of the smart contract would differ from the expected outcome. One of the things we do love about smart contracts is the fact that we can trust on the execution of the agreement without necessarily trusting each other due to the automated and irreversible execution of agreements. Therefore, smart contracts are particularly suitable for dealings with a low risk of malfunction, where subsequent claims are very rare, as such claims are hard to enforce due to the anonymity on blockchain. In order to make the topic more comprehensible, I introduce an example with a flight insurance company that insures its customer for a flight delay. This flight insurance uses a smart contract for the execution of the contract it holds with its customer. This smart contract has been deployed by its developer. The flight details tell whether a plane was laid or not. In order to feed real-world data into the smart contract, an oracle is needed. Let's look at the performance of the parties involved. The smart contract is initially deployed by a developer. This smart contract then is activated by the flight insurance by sending a transaction involving a crypto balance that is stored in the smart contract account. The smart contract does its job according to its code, so the smart contract orders the flight details via oracle as it has been triggered to do so by the flight insurance. The oracle then works as an intermediary for the flight details provider and the smart contract. When the smart contract receives the real-world data, it can determine whether the flight insurance's customer has a claim on the insurance or not, and therefore the smart contract would either send crypto in its account back to the insurance or to the insurance's customer. All the lighter blue parties are legal parties involved. As you can see, the smart contract itself is just the automated mechanism executing the contract. As you can see, in real-world applications, the oracle is of great importance, as it's the party implementing important real-world data. The smart contract needs to be instructed in its code to let the oracle have access. Therefore, a channel into the smart contract is opened that would otherwise be safe and shut. Also, the information transmitted by the oracle determines the execution of the agreement. As an oracle has such a great influence on the smart contract, it needs to be safe and trustworthy. Weber introduced in his work that the oracle may be identified as a vicarious agent. But as there have not been a lot of cases yet, we are all excited for legal practice giving the definite answers to these questions, especially as many more details can be of relevance looking at contractual relationships. On this slide, you can find the literature I consulted preparing this video. And if you want to find out more about blockchain oracles and familiar topics, please subscribe to our channel. Our social media channels are linked here. Have a good time.