Following the victory of blockchain-technology-based cryptographic currency bitcoin, new technological developments enable the creation of self-executing smart contracts.
Here, services such as the transfer of a given amount in a cryptocurrency are made dependent on the occurrence of previously programmed conditions. Smart contracts are executed via computers in a peer-to-peer network, with no need for central, controlling brokers such as fiduciaries or banks. In fact, no human supervision of smart contracts is needed. This makes blockchain technology and smart contracts attractive wherever trust is required.
Such systems have the advantage of reducing counterperformance risks and transaction costs, because it is almost impossible to manipulate the fulfillment of conditions. Performance and compensation can be guaranteed. Legal enforcement costs are eliminated, because each party to the contract can be certain of performance when the contract is created. And services can be controlled: For example, a car could deny service if the rental fee is not paid. Insurance companies are playing around with smart contracts that would automatically pay out money after storms.
Increased standardization should also reduce costs that arise through incompatibilities. Developers could envision electric cars being automatically charged at red lights, for example. One of the most promising advantages beckoning to the public administration sector is the possibility of making blockchains publicly readable or recordable. This would allow money to be traced, rights to be verified and authenticated contracts to be executed.
These challenges can of course also be effectively and securely met using conventional technology. But smart contracts should make things even more efficient and trustworthy. Smart contracts should not come into play where proven technical solutions are already supporting smooth processes. Instead their development should focus on those areas that until now have only been served with difficulty and high friction losses. No need to create problems for smart contracts, instead smart contracts should be examined as solutions for existing problems.
When we look at the legal aspects of programmed contracts, the question arises as to whether in future program code will contain the contract text and create the legal effects – an approach where "code is law". Such an approach has little in common with legal realities, however, even if some smart contract developers maintain otherwise: The "code is law" dogma conflicts with some mandatory aspects of German law.
Even a smart contract cannot exceed the boundaries laid out by the law – no more so than a paper contract. Or in other words: code is not the only law. Instead, the German Civil Code stipulates that a contract's content is always determined by the will of the contracting parties. The circumstances surrounding the conclusion of the contract are also intended to be considered when interpreting it. Add to this the as yet legally untested issue of whether the contract language can be a programming language that is perhaps only expressed in compiled code. Given all this, it is no wonder that many smart contract applications address only pure performance execution, with the legal relationship covered by framework agreements.
Still, we should remember that today's body of law already contains the necessary instruments to meet the challenges posed by these new technologies. For developers this means that they must comply with existing law when programming smart contracts: For example, the automation of service provision by the smart contract can be a weakness, when the smart contract deviates from the actual will of at least one of the contracting parties. It might make sense in such cases to open up capacity for a type of arbitration instance in the algorithm, even if this goes against some of the advantages of blockchain. Developers should also keep in mind that it can make sense to program warranty rights into the smart contract, for example, so that the legal consequences of a performance deficiency can be automatically demonstrated.
The further development of smart contracts not only faces technical challenges, but is also dependent on the resolution of the related legal questions. Open issues are apparent in the areas of data and consumer protection law, competition and cartel law, and surrounding liability for incorrectly programmed smart contracts.
And that is not all: If we assume that under certain circumstances programming smart contracts represents a legal service under the meaning of the German Legal Services Act, this raises the question of whether and to what extent programmers are allowed to create such smart contracts without qualified legal support. And lastly we can ask whether smart contract providers will need to comply with regulatory requirements, or even a "lex smart contract", in the future. There is plenty of suspense around future developments.