Introduction
This term was coined in an article published in 1996 by US computer scientist and legal scholar Nick Szabo in “Extropy” magazine (Building Blocks For Digital Free Markets). Many people believe that he is the man behind the pseudonym “Satoshi Nakamoto”, the creator of Bitcoin (Blockchain), although he has always denied it.
Szabo focused on the operation of vending machines and predicted that digital and mechanical developments would make it possible to automate the execution of increasingly complex contracts. He anticipated that hardware and software systems could emulate the entire contract life cycle, replacing any human intervention in the contracting process. Szabo felt that vending machines met two critical requirements in contracting: firstly, they execute the activities inherent to the exchange, by taking money and dispensing products. These machines also contain security mechanisms to ensure that the cost of a breach (breaking into them to get products without paying) is higher than what can be gained through theft. Thus, vending machines with the current security measures are useful because they dispense inexpensive products like beverages, snacks and sweets, which are not worth destroying a machine to get. If today’s vending machines sold diamonds, it would probably be common for them to be broken into to get them.
The unstoppable development of technology in recent years and the appearance of phenomena such as Blockchain have led Szabo’s ideas, which had gone unnoticed, to gain unexpected relevance. Indeed, digital progress – primarily Blockchain – has converted Szabo’s once Utopian ideas into realistic projects. Simple mechanical devices have now been replaced with combinations of digital systems, online networks and devices connected to the Internet, thus making it possible to expand his idea beyond the limited sphere of vending machines.
They are a key example of what has been called “Blockchain 2.0” and could prompt an authentic legal revolution. The idea is to translate legal wording into computer code that is then initialled by the contract parties. This would make agreements self-executing, releasing them from the subsequent will of the parties.
To fully understand smart contracts, they must be put into context with two other recent phenomena: Blockchain and Smart Properties. These three form an eco-system that needs to be regarded as a whole.
Blockchain
Literally, this means a chain of blocks. It is a computer protocol that enables the creation of “distributed ledgers”. A “distributed ledger” is structured so that the recordings it contains are consensually agreed upon by the anonymous participants involved in its creation. In addition, each participant has an updated copy of this ledger, which is unique and universal. This “evidence matrix” that is used to prevent “double spending” in cryptocurrency transfers can also be used to create other “crypto-ledgers” as long as the elements entailed in them can be mathematically represented.
What is truly revolutionary about this procedure is the way in which the records that are added to the ledger are agreed on. We are talking about a mathematical consensus in which each of the participants involved in reaching the consensus (miners) must solve a computational challenge, a mathematical puzzle to be solved by brute force (trial/error). The only way to impact this consensus is to accumulate a computational capacity that is higher than 50% of that of all the other miners involved. Since it is very costly to overcome this challenge (it entails hardware and electricity costs), influencing a decision in which a large enough number of miners participate is so expensive that the amount stolen would have to be very high for it to be worth the effort.
This is clearly a probative procedure, decentralised evidence by intermediation. Only what is recorded in the matrix is authentic. However, the decision-making about the records in it and its custody are shared with everyone involved in its creation.
Smart properties
The second component in the eco-system is “smart property” or “cryptoproperty”. In light of the effectiveness of distributed ledgers for monetary exchanges, it is logical to assume that other assets and rights could be transferred using this protocol as tender. To accomplish this, the asset or right to be transferred must first be “tokenized”. “Tokenizing” means mathematically representing a right or property. A sequence of letters and digits (information) that unambiguously represents them and is added to a distributed ledger. These tokens are like the chips at a casino, which represent a certain value of legal tender. To be able to transfer ownership of an asset or right, first you have to represent that asset or right in a digital format that is compatible with the protocol you are using to transfer it.
In a digital environment, these tokens are merely “data” (information) that represents assets or rights. The work in a way similar to securities. Possession grants ownership over the specific asset or right and entitles the holder to subsequently dispose of it, transferring it to a new owner. The virtue of Blockchain when it emulates the function of securities is the same as that which enables the use of “cryptocurrencies”: it prevents multiple ownership. It solves the “problem of double spending”. However – and this is very important – the singularity of each transaction (that the owner of the asset or right has not repeated the procedure with other “distributed ledgers”) is not guaranteed. For this reason, it cannot be categorically stated that smart property emulates traditional ownership.
Legal nature of smart property
It is not easy to find regulatory references to this term. The Swiss electronic signature law confirms the eco-system in its definition. The wording links smart property to distributed ledgers (Blockchain) and to smart contracts. It says:
(1)Digital information that includes all the elements of the right to ownership, (2) that is recorded in Blockchain or in another distributed ledger, (3) that can be transferred by executing a protocol and (4) that may or may not be accompanied by additional functions governed by a smart contract that is regulated by a code and/or manual entry of data.
Smart property cannot be considered a right in rem, such as a deed held by someone, which grants ownership over a thing or a right. Firstly, because it is not included in the cases defined by law. In addition, as mentioned, it is not an absolute right that can be objected to “erga omnes”. For that to be the case, the use of the protocol would have to ensure that the asset or right has not be previously disposed of. That such asset has not been “tokenized” and added to another distributed ledger. Finally, it is not easily recognised by potentially affected third parties.
There is also doubt about the acceptance of ownership of cryptoproperty within the legal world. Possession cannot be deduced from the execution of a protocol. Possession does not arise from having a password that provides access to a file.
To shed light on this matter, it is advisable to look at the laws in the US states of Arizona and Vermont, which are, to a great extent, forerunners in regulating these issues. The legislation on Blockchain and smart contracts in the state of Arizona says that they are “files of evidence”, a way of “securing” information. Whoever possesses the private code has the right of use or ownership of that information. The regulations do not consider this information (data) as “things” or “rights”, or even as “values”, but it is merely deemed “information”. Thus, for Arizona lawmakers, “cryptoproperty” is nothing more than the right to access and/or transfer certain information (data).
In turn, the state of Vermont has also amended its regulations, introducing provisions that contain legal assumptions linked to the use of these technologies; Blockchain files referring to facts are assumed to be authentic. However, this presumption does not extend to the accuracy, validity or legal nature of the contents added to them. Therefore, the provision sets forth that the burden of proof as to whether a file is not authentic lies with the individuals who are harmed by its contribution or invocation.
Thus, these are “sui generis” deeds that grant the holder the right to access a database (the distributed ledger). That means this is a probative instrument without any specific legal effects. If the token was transferred through a contract (smart contract), the parties could be bound by that agreement, but whether the token can be enforced against third parties is a matter of debate.
Smart contracts
This is the third component of the eco-system. Smart properties can be automatically transferred by executing a computer code. Smart contracts are merely a computer code (contractware) saved in a distributed ledger, which, when executed, guarantees that the data obtained from it will also be saved in this ledger.
“Contractware” is the translation of legal (contractual) wording into computer code. The coding includes not just the agreements reached but also the consequences that could arise from performance or a breach of the provisions. If, for example, the transfer of a token is arranged, the smart contract does not just set out the transfer agreements. It also verifies the data and executes the consequences agreed upon by the undersigned parties. In this way, for example, the code receives the contributions of the parties (payment in cryptocurrency and the token) and sends the contribution of each party to the other. Many authors refuse to consider these code sequences as authentic contracts because, whereas simple contracts merely include promises of future fulfilment of contributions, smart contracts execute them.
When a smart contract is programmed, the type of code to be implemented is conditional. It follows a pattern of: “If this happens…you do that. If this other thing happens, you do that other thing”. In sum, this is a code that easily adapts to legal wording and is simply implemented. For this reason, referring to this kind of contract as a “smart contract” is often criticised. This is because the modern definition of the term “artificial intelligence” refers to machines that have “cognitive independence”, which is achieved through what is known as “neuronal computation”. This enables machines to learn by themselves and their responses are sometimes unpredictable. However, conditional coding does not create machines with cognitive independence and unpredictable responses. Quite the contrary. The legal security of smart contracts is based on the predictability of the machine under specific circumstances programmed in advance. Therefore, these contracts are not “smart” in this sense.
How smart contracts work
There are three phases in the life cycle of a contract: generation, conclusion and performance. The generation phase entails information, negotiation and wording of the agreement to be formalised; conclusion is the phase in which the intents are met based on the premises set out in the first phase. In the performance phase, the parties proceed to fulfil (or not fulfil) the obligations undertaken.
Smart contracts do not have much impact on the first two phases. In the generation phase, when a contract is with a consumer, the other party must ensure that pre-contractual information is furnished to the consumer prior conclusion of the contract. Current legislation already stipulates that, for non-smart contracts, this information must be furnished in a “durable medium”. It does not seem likely that pro-consumer legislation will be affected by automating contracts. In fact, information about coding and self-executing agreements is likely to be added to consumers’ right to information.
No major differences are seen in the conclusion phase either. In smart contracts, as well as in ordinary ones, the use of the electronic signatures set forth in current legislation is mandatory, including advanced electronic signatures based on asymmetrical key cryptography, which is initially provided for in the formalisation of smart contracts. However, we must bear in mind that, under certain circumstances, when the regulations require that the parties involved be identified, the use of the public key infrastructure will not suffice if the assignment of the asymmetrical keys does not first require the parties requesting them to be identified.
This is where the similarities end. In an ordinary contract, the parties keep their “signed counterparts” or the certificate issued by an “intermediating third party” that has been entrusted to certify the meeting of intents. If the need to verify the existence and content of the contract arises, each party can exhibit or provide their copy. However, with smart contracts, after the meeting of intents, the computer code is added to a distributed ledger, remaining at an “address” of the ledger until it is completed executed. The inclusion of the code into the ledger guarantees its inalterability. No one can change it, so whatever is added to the chain will be what is executed in the end, and will serve as the basis for obtaining the “data exit”.
Furthermore, when a smart contract is used, the party drawing up the contract must add a clause stating that the other party agrees to the coding of the agreements and subsequent automatic execution thereof. Consent must also be requested for the use of specific information sources that fill in the computer code variables prior to execution. In sum, the contract must contain a list of the oracles and IoTs (Internet of Things) that will be used as sources for incorporating the information they supply to the computer code variables (smart contract), as we shall see later.
To understand how “contractware” works, it is also important to understand the meaning of “oracle”. When a smart contract is formalised, as nothing more than a computer programme (code), certain details are unknown at that time. These are future data that in one way or another affect the result of the execution of that code. When “contractware” is created, the future data are represented by variables that will be assigned the value obtained from consulting an electronic information source agreed upon by the parties in advance.
Before the code can be executed, all the variables in it must be filled in with the information provided by the sources agreed upon by the parties. Let’s imagine, for example, the automation of a game of chance. It is coded in such a way that whoever wishes to participate must transfer the amount (in cryptocurrency) required to play to a certain wallet. Let’s assume that the bet refers to the outcome of a football match, the score of which will be known at the end of the match (and also the end of the deadline for players wishing to place bets). In the rules of play (the smart contract) players are informed that the results will be known after “launching” a query to the website of the Spanish Football Federation, for example. At the end of the match, the programme will launch the question to the oracle and will fill in the variable. This is how it gets the information needed to execute the code that automates the bet. When the code is executed, it will be possible to determine which player or players (if any) won the bet (correctly predicted the outcome) and to automatically transfer the amount (also in cryptocurrency) applicable in each case.
The data that “feed” the computer code variables are known as “data entry”. Oracles are not the only “data entry” (the only source of information) for filling in variables in a smart contract. They can also be filled in with information provided by “IoTs”.
“IoTs” are “internetized” things, devices connected to the internet. Today, our smartphones and smart TVs are already connected to the internet, so they are considered IoTs. If we open the weather app on our smartphones, we can check the weather forecast for anywhere in the world. This information can be provided by an oracle (such as the website of the Spanish Meteorological Agency) or by an “internetized” device (or a network of them) equipped with appropriate sensors to capture this information and send it in real time to one or more servers. Increasing numbers of connected devices are being developed with sensors to capture a wide array of information that can be used as “data entry” in smart contracts, and increasing numbers of “internetized” things are also being deployed around the world. Indeed, Gartner Consulting has estimated that for 2020 there will be a whopping 20.4 billion connected devices worldwide.
The execution of the computer code added to the chain (distributed ledger), after filling in the variables of course, results in new data that are known as “data exit”.
This information can be saved in a distributed ledger (chain of blocks) to create an irreversible, permanent record of the results of this execution. For example, the result of executing a smart contract may be the change of ownership of a smart (tokenized) property or a cryptocurrency transfer to the wallet of one of the participants.
“Data exit” may also be destined for IoTs. These are known as “triggers”, meaning that the result of the execution of the code could have mechanical consequences (such as in the vending machines referred to by Nick Szabo). Think about car sharing, for example. I mean those shared vehicles that are popping up everywhere these days. To use them, users search for the closest vehicles on their devices and choose the most convenient one. To access it, the user is sent a code. The “challenge code” for comparison is sent to the selected vehicle by internet, so that only the registered user who has booked that vehicle can enter it. This technique, which is being used increasingly in English-speaking countries, has numerous uses and clear legal relevance. It can be used for property rentals, for instance. With “internetized” locks, the door to a property can be opened by a person who has signed a smart rental contract. This is a kind of “key handover” because through this procedure, access to goods or property can be granted to the person who has entered into the corresponding smart contract.
Another common use of “triggers” is for automation of motor vehicle financing. A smart contract is drawn up in which a monthly payment of the amount to be deducted from the account (wallet) of the party to pay the instalments is programmed. A rule is also added to the code, whereby if the party purchasing the vehicle has failed to make three payments, a programme function is executed that connects to the vehicle, sends instructions to shut it off (the user can no longer start up the vehicle) and geolocates the vehicle so that it can be removed by the party that financed the purchase. Smart contracts can provide for deferred or upfront payments. When payments are deferred, as in the case of motor vehicle financing, the bank reserves ownership of the purchased vehicles it finances. If the borrower defaults on payment, ownership of the vehicle is not transferred (the ownership deed is not modified in the record). If payment is made up front, the code can be programmed for the buyer to transfer the stipulated amount to the address indicated in the code and for this amount to remain on deposit until the services agreed by contract are performed. Imagine that the purchase of some tokens representing a stake in a certain company is arranged. The code calls for the parties to fulfil their respective obligations. The seller sends the token to the smart contract address and the buyer transfers the stipulated price to the same address. By querying the distributed ledger, the code verifies that the tokens have not already been transferred and that the payment is for the agreed amount. Once these details have been checked, the code adds the change of ownership of these tokens to the record and sends the cryptocurrency to the address of the seller’s wallet.
UNCITRAL regulations and smart contracts
Many of the legal definitions and concepts of the regulations governing electronic commerce are based on the guidelines set by the United Nations Commission on International Trade Law (UNCITRAL). This Commission has addressed the exponential growth in electronic relationships in international trade by creating diverse accreditation instruments based on the principles of (i) functional equivalence between electronic and paper documents and (ii) technology neutrality.
In the absence of specific regulations for smart contracts, it may be useful to turn to the UNCITRAL rules which, as mentioned before, have been based on regulations governing contracting by electronic methods for decades now. Thus, the Model Law on Electronic Signatures (2001), the Convention on the Use of Electronic Communications in International Contracts (2005) and the UNCITRAL Model Law on Electronic Transferable Records (MLETR) would all be applicable to electronic contracting.
This latter law could be used as reference for future legislative initiatives on smart contracts. It refers to electronic transferable records, designed to emulate the function of securities. Thus, they could represent specific assets and, where appropriate, transfer the related ownership deed.
The only difference between electronic transferable records and tokens is that the former is a data set and the latter is another set of data but in this case linked to a computer code (computer programme) that could trigger them to be self-executed, releasing them from the subsequent will of the parties. That is, ownership would be transferred automatically by executing the programme when the criteria agreed by the parties are met.
Are the fundamental principles of UNCITRAL regulations applicable to smart contracts?
The UNCITRAL regulations are built upon three fundamental principles: non-discrimination, technology neutrality and functional equivalence, which require preliminary analysis to decide whether they apply to smart contracts.
Regarding the principle of non-discrimination, we must recall that the regulations on electronic signatures and commerce stipulate that the legal value of a document cannot be denied merely based on the fact that it is in electronic format. Thus, a presumption of lawfulness is established for electronic methods. Because Blockchain and smart contracts have an electronic format, this presumption affects the technology of distributed ledgers.
In turn, the “principle of technology neutrality” aims to avoid obsolescence in the wording of the rules, making them applicable immediately when technological progress takes place. Therefore, this principle fosters innovative procedures such as Blockchain and smart contracts and supports the transition toward these technologies.
It is the principle of functional equivalence that raises the greatest issues. Ultimately, the equivalence is with documents (including contracts) in paper format. Thus, smart contracts must meet the same requirements as documents in paper format: they must be in writing, original and signed. Smart contracts can meet the requirement of being in writing (the computer code is a form of writing that can be queried at a later time), original (they have this status by being included in the distributed ledger) and signed (as mentioned, transactions are signed using asymmetrical key cryptography – electronic signatures). However, UNCITRAL was apparently not thinking of self-executing code, so the comparison with a paper document may not suffice to answer the legal questions that could arise.
The requirements for contract creation set out in the UNCITRAL regulations should also be analysed in order to conclude whether or not they are applicable to smart contracts.
Since the offer and acceptance of an electronic transaction are just “data messages”, and this term is defined in the MLETR as information generated, sent, received or saved by electronic means, we can consider electronic messages, including interactions using computer code (smart contracts) as included here. The principle of being in written form is met when the formalised contract is available for subsequent consultation, and this is the case for smart contracts. The signature requirement is met when the electronic signature method used provides authentic identification. As mentioned above, the use of asymmetrical key cryptography (assigning public and private keys to the signatory) only provides identification if the recipient and user of these keys have been identified beforehand. However, if the asymmetrical key cryptography is used in the same way as in Bitcoin (asymmetrical keys are assigned without any requirement to even declare an identity), the signature will be deemed anonymous and therefore not identifying, so one of the requirements would not be met, namely that the contract must be signed by the parties involved. Signature means linking the electronic declaration of intent with a specific identity.
The integrity requirement is easily met in smart contracts. Bear in mind that we are talking about a code and some data that are saved in a distributed ledger under a Blockchain protocol. Since this protocol merely entails hashing block transactions, it would be very difficult to alter anything signed.
To sum up, UNCITRAL regulations on electronic contracting are apparently not so far removed from Blockchain. Ultimately, smart contracts are just the culmination of digital contracting processes. Regulations on electronic communications and signatures in contracting processes are clearly applicable. The explicit legal provisions on transferable legal records provide recognition for securities and electronic evidence matrixes. However, the regulations do not include explicit provisions on self-execution of these contracts or on applicable regulations or competent jurisdiction in this cases.
Legal relevance of smart contracts
To start with, we must accept, even if only from a theoretical perspective, the regulatory capacity of computer code. This matter must be accepted “de facto”, since the execution of computer code on users’ computers could influence their behaviour or that of third parties affected by this execution. Therefore, we could speak of a “sui generis regulatory capacity” of smart contracts, given that their effects could coincide with the law and with traditional contracts. Imagine, for example, the rules of use of a social network to which millions of users around the world are subject. The way to post, join, report or remove contents, conditions for access to the site, etc. They generate a habit conditioned by the programming. Users of this computer programme (the social network’s code) would have a hard time straying from the standards programmed by the code’s creators.
While it is true that legal regulations and computer code bear certain similarities, it is also true that there are considerable differences. The main difference probably lies in the fact that computer code is created by private agents whereas the responsibility for regulating currently falls almost exclusively on previously qualified agents (lawmakers and judges) whose mission is to safeguard the common good. In addition, these agents have independent terminology and grammar rules that are difficult to understand for the uninitiated in these disciplines. For example, a smart contract is only governed by the rules set forth in its design. From a computing perspective, it is hard for the programmer to take into consideration the grounds for contract nullity when designing the programme unless explicit instructions are given in that regard. Therefore, there may be discrepancies between the two systems (legal and computing) that cause smart contracts to be executed that violate the law, which could undoubtedly prove problematic. For this reason, it is common to distinguish between simple smart contracts that are no more than computer code with a certain function and “legal smart contracts”, which are those that translate certain prior agreements that meet the applicable regulations in each case into computer code. Consequently, one of the challenges of smart contracts is to harmonise these two systems, the legal and the computing, in order to generate mechanisms that guarantee that the computer code will comply with valid regulations.
Code is law?
Technological advances are starting to have the capacity to question longstanding legal conceptions. Thus, there are some people who feel that certain technologies can emulate the law that regulates the conduct of those using them. However, up to now, no one has questioned the monopoly of legal systems as coercive mechanisms for law enforcement. If they are violated, one can resort to the “legal order” to force compliance and to compensate for any loss and damage caused by the infringement. However, enthusiasts of these technologies, such as Lawrence Lessig, believe that smart contracts have the potential to displace legal systems in their essential mission of enforcing contractual agreements. They feel that programmers transfer to software users ways of acting and rules that replace the law. Lessig’s followers commonly refer to this way of thinking as “code is law”.
This is no trivial matter. Contracts are essential tools that support our way of life in both social and economic terms. Until now, no one had ever questioned whether contract execution required the support of legal systems. However, as mentioned before, technological breakthroughs have given rise to speculation about the possibility of contract law being displaced to a great extent by these devices. The strongest supporters believe not only that smart contracts do not need a legal system to exist; they also amount to a “technological alternative” to traditional legal systems that could lead to the disappearance of many litigious concepts, at least those deriving from breaches of contract. These are not isolated opinions: Russian Prime Minister Dmitry Medvedev has stated: “The systems that create these smart contracts are self-regulating, beyond the boundaries of the law.”
In sum, this is a technology that arouses interest, respect, aversion and enthusiasm. For some, it is going to revolutionise commercial relations and our current understanding of property. However, sceptics feel that it is a sophisticated scam, similar to a “Ponzi scheme”.
Regardless of these opposing opinions and whether or not smart contracts are going to transform the world, it does not appear unreasonable that they will be welcomed by the business world. Ultimately, they are merely the culmination of so-called digital or electronic contracts and could afford savings and efficiency in business. As their use becomes more widespread, they will exert growing pressure on legal agents to replace traditional contracts, at least under certain circumstances.
In my opinion, however, they will never replace contract law because of a fundamental issue that distinguishes them: contract law is a legal institution, the main mission of which is to remedy the consequences of breaches in agreements reached between contract parties. Its mission is not to ensure “ex ante” fulfilment of the provisions but rather to resolve claims that may arise “ex post”, after the breach of one of the contractual provisions. The fact that smart contracts cannot be violated means that it will not be necessary to remedy or rectify the harmful effects of breaches, which cannot exist. However, this does not mean that contract law will cease to apply. Parties may not be comprehensive enough in foreseeing the situations that could apply to their specific relationship. There may also be cases of errors in the code that prompt the contract to behave in a way not foreseen by the parties. Exogenous circumstances beyond the parties’ control may also arise that affect performance or execution of the agreement. In these cases, and probably also in many others, contract law and traditional legal systems will still be necessary. Furthermore, with its fundamental mission of order and justice, the law cannot be removed from phenomena such as these.
The attack on The DAO as a paradigm for a legal reflection on smart contracts
DAO (Decentralised Autonomous Organization) refers to a company that operates (at least from a corporate perspective) by executing one or more smart contracts. The participants in a DAO exchange cryptocurrency by holding tokens, usually in an ICO16. Among other rights, this transaction entitles them to vote on certain matters related to the company’s business.
In May 2016, a decentralised management venture capital fund was set up: a DAO whose business focused on investing in start-ups related to Blockchain and smart contracts on the Ethereum Platform. Its name was “THE DAO”. This was the largest crowdfunding operation in history: 150 million dollars and 11,000 investors worldwide. “THE DAO” was managed exclusively through a smart contract executed over this platform.
On 17 June 2016, an unknown hacker transferred “Ethers” worth 60 million dollars from the DAO to his wallet. He took advantage of a bug in the code programming (the smart contract) that enabled successive withdrawals of cryptocurrency before the balance was updated, thus leading to unjustified enrichment. This matter is of interest in legal terms because the legal conditions accepted by those participating in The DAO adhered to the “code is law” philosophy, whereby they were only bound by the execution of the code.
The Ethereum platform is governed by the “Ethereum Foundation”, whose decision-making is based on consensus (voting) by its members. Following this incident, a fierce debate arose among the members of The DAO as to how to respond. Some felt it amounted to theft (misappropriation), which they should attempt to remedy. Others saw it as a typical vulnerability of code and as such, a risk inherent to smart contracts. The latter group supported acting in consequence, in the understanding that the participants in The DAO should accept the losses.
In the end, they decided to implement a “hard fork”. This is an agreed manipulation of the chain that enables a new chain of blocks to be generated. It starts at the block prior to the one containing the fraudulent transfer or any other transfer that for some reason should be left out of the distributed ledger. To accomplish this, the majority of the nodes acting as miners in the system must agree to join the new chain that is free of the transfer to be excluded. In this way, the protocol participants managed to avoid damage to the company resulting from the loss of the 60 million dollars transferred.
This decision led the Ethereum Foundation to split into two separate platforms: Ethereum and Ethereum Classic. This case illustrates the paradigm of whether “code is law” or if, above and beyond the code, law and justice should prevail.
However, it would be advisable to consider what would have happened if the “hard fork” had not been possible, if the Ethereum miners had not reached a consensus or if the spread of the transaction had made it impossible to undo. In that case, two questions of a legal nature would have arisen: Firstly, would it have been possible to locate an anonymous hacker whose only trace is an asymmetrical key granted with no need to prove identity? Secondly, assuming he could be identified, would it have been possible to take civil or criminal action against the hacker?
Furthermore, there is one other thing that makes me uneasy. The Blockchain movement is of a crypto-anarchist nature, thus aspiring to decentralised decision-making. This prevents the risk of corrupting those who “make records in” and custody the evidence matrix. One of the benefits of Blockchain, in terms of proof, is that its transactions are irreversible. However, cases like that of “The DAO” reveal that this irreversibility is not absolute and that reversible transactions may include those linked to the assets of the participants in the chain. They may decide to reverse the transactions to their own benefit, giving rise to damage to third parties involved in the transactions they reverse.
Final note
The foregoing analysis refers to smart contracts in a Blockchain (distributed ledger) setting. However, automation of contractual processes with centralised evidence matrixes is also possible. The pre-requisite for implementing this kind of contract is that there must be an evidence matrix that is separate from the parties to the contract rather than the distributed or collaborative nature of the record-keeping.
José María Anguiano
Partner, Garrigues
