Smart contracts en de Haviltex-norm

Stel je voor dat een overeenkomst zichzelf uitvoert. Dat service credits bij een uitbestedingsovereenkomst automatisch in mindering worden gebracht op de maandfactuur omdat bepaalde service levels niet gehaald zijn. Of dat de tarieven van een dienstverlener automatisch worden geïndexeerd op basis van een CBS-index omdat er een bepaalde termijn is verstreken en het niveau van dienstverlening niet onder een bepaald niveau is gezakt in de laatste twaalf maanden. Smart contracts maken dit en veel meer mogelijk, in ieder geval in theorie. Het is dan ook niet moeilijk om te begrijpen waarom smart contracts steeds meer in de belangstelling staan. Dit geldt niet alleen voor techneuten en – in toenemende mate – juristen,[2] maar ook voor de overheid. Zo zal het Ministerie van Veiligheid en Justitie in 2017 een verkennend onderzoek starten naar de sociale en juridische gevolgen van blockchain technologie en toepassingen zoals smart contracts.[3] De opkomst van smart contracting is nauw verweven met die van blockchain technologie. In dit artikel gaan wij niet in op de complexe techniek achter blockchain. Het gaat ons om de plaats die een smart contract in het Nederlands recht inneemt en de wijze waarop het Nederlands recht het gebruik van smart contracts beïnvloedt. Na een korte beschrijving van smart contracts beschrijven we de wijze waarop smart contracts verschillen van traditionele overeenkomsten. Dit betreft met name de onveranderlijkheid van de code en de automatische en autonome uitvoering van smart contracts. We signaleren vervolgens dat er sprake is van een discrepantie tussen een smart contract dat naar zijn aard intern gericht is op de uitvoering van de overeenkomst, en een rechtstelsel waarin de omstandigheden van het geval leidend zijn bij de uitleg van deze overeenkomst. Deze discrepantie werken we nader uit aan de hand van de uitlegjurisprudentie. We besluiten met een korte conclusie.

1 Wat is een smart contract?

De oorsprong van smart contracts wordt toegeschreven aan Nick Szabo, die in rond 1995 verschillende papers publiceerde over het onderwerp. Volgens een van de door hem gehanteerde definities is een smart contract ‘a computerized transaction protocol that executes terms of a contract’.[4] Een andere definitie van Szabo is die van smart contract als: ‘digital, computable contracts where the performance and enforcement of contractual conditions occur automatically, without the need for human intervention.'[5] In de literatuur is, buiten Szabo,[6] lange tijd relatief weinig aandacht voor smart contracts. Dit verandert met de opkomst van blockchain. Bitcoin heeft als een van de eerste toepassingen de grootste impact,[7] maar de achterliggende blockchain technologie is daartoe niet beperkt en kan ook worden gebruikt voor andere toepassingen dan digitale valuta, zoals de smart contracts die Szabo eerder beschreef. De definitie van Szabo lijkt inmiddels niet meer goed aan te sluiten bij het huidige gebruik van de term smart contracts in de literatuur.[8] Tegelijkertijd ontbreekt een gedeelde en eenduidige definitie van smart contracts in relatie tot blockchain. Voor doeleinden van dit artikel sluiten we aan bij de definitie die Antony Lewis[9] hanteert. Hij definieert smart contracts als:

– vooraf bepaalde logica (computercode)

– die wordt opgeslagen en verveelvoudigd op een distributed storage platform (zoals een blockchain),

– die wordt uitgevoerd door een netwerk van computers (wat meestal hetzelfde platform zal zijn als waar de blockchain is opgeslagen),

– en kan resulteren in wijzigingen in het grootboek (de ledger).[10]

Door elementen van een overeenkomst vorm te geven als computercode die door een netwerk van computers middels een blockchain kan worden uitgevoerd, kan gebruik worden gemaakt van de sterke punten van blockchain technologie zoals betrouwbaarheid van de transacties, transparantie van de logica en onafhankelijkheid van een bepaalde partij. Tegelijkertijd heeft het gebruik van blockchain technologie een aantal praktische en juridische consequenties. De eerste is dat computercode die eenmaal is vastgelegd in een blokchain niet, of althans niet eenvoudig, kan worden veranderd. Daarnaast is relevant dat de computercode wordt uitgevoerd door de blockchain waarin deze is opgeslagen, wat betekent dat de computercode in beginsel altijd de instructies uit de blockchain zonder wijziging zal uitvoeren, en zonder dat de contractspartijen of een derde daaraan in de weg kunnen staan. Op deze punten komen wij in paragraaf 2 nader terug.

Bij het maken van een smart contract moet allereerst worden bepaald welke afspraken in de overeenkomst moeten worden geautomatiseerd. De tweede stap is het vertalen van deze afspraken naar concrete triggers en consequenties in computercode die door het netwerk van computers kan worden uitgevoerd. Hiervoor kan gebruik worden gemaakt van verschillende (veelal open source) tools, zoals EtherScripter.11 Voor het vormgeven van de triggers kan gebruik worden gemaakt van externe bronnen, zoals een mutatie in een openbaar register waarmee het smart contract in contact staat. De consequenties kunnen allerlei vormen hebben, zoals een betaling aan een derde, het intrekken van een gebruiksrecht, het intreden van een contractuele garantietermijn, etc.

Een sterk versimpeld smart contract voor de koop van een website tegen bepaalde voorwaarden zou er als volgt uit kunnen zien:

Figuur 1 (hierboven):[12]
Bij bovenstaande figuur passen direct een aantal kanttekeningen. Hoewel met de handelingen wordt beoogd om een verkoop tot stand te brengen als een bedrag op een bepaalde rekening is bijgeschreven, wordt hierbij echter geen rekening gehouden met het feit dat op koop de specifieke regels van de kooptitel in boek 7 BW van toepassing zijn. Een smart contract waarin die regels wel zouden zijn verwerkt zou duidelijker invulling geven aan de aspecten van koop zoals bepaalde in art. 7:1 BW.13 Ook zou duidelijker moeten worden beschreven wat er precies wordt verkocht. De figuur illustreert wat ons betreft dan ook niet alleen de complexiteit van het goed vastleggen van afspraken in smart contracts, maar ook dat de traditionele overeenkomst een belangrijke aanvullende rol zal blijven spelen.

Bij de meeste overeenkomsten zal het deel van de overeenkomst dat zich leent voor automatisering relatief beperkt zijn. Waar een betaaltermijn relatief eenvoudig kan worden geautomatiseerd geldt dit niet voor een contractuele vrijwaring of een beperking van aansprakelijkheid. Dergelijke bepalingen zijn immers bedoeld om het juridische kader te bepalen voor schadeclaims, en kunnen niet actief worden uitgevoerd. Mede om deze reden wordt naast software ook altijd de tekst van overeenkomst aangehecht op de blockchain. Dit principe wordt aangeduid als dual integration.[14] Naast het regelen van de niet-geautomatiseerde onderdelen is het bijvoegen van de tekst van de overeenkomst bovendien nuttig als een derde over de overeenkomst moet oordelen. Daarnaast kan de overeenkomst nuance aanbrengen en een kader scheppen waarbinnen de verplichtingen van toepassing zijn en worden uitgevoerd. Zoals we in paragraaf 4 zullen beschrijven, is het belang van het niet-geautomatiseerde deel van de overeenkomst voor het uitvoeren van het smart contract verwaarloosbaar, maar dit deel kan voor de uitleg en de beslechting van eventuele geschillen een belangrijke rol spelen.

2 Overeenkomsten en verschillen met traditionele overeenkomsten

Een smart contract is afgezien van de uitvoering en vormgeving daarvan niet wezenlijk anders dan een traditionele overeenkomst. Ook bij traditionele overeenkomsten bepalen partijen vooraf de afspraken die tussen hun gelden. Deze afspraken worden vervolgens vertaald in wederzijdse verplichtingen die weer af hankelijk kunnen worden gesteld van het zich voordoen van bepaalde triggers. Hoewel de vastlegging van afspraken in een overeenkomst een andere vorm kent dan het programmeren van scripts, zal een goede contractjurist – net als een programmeur – de afspraken zoveel mogelijk willen opknippen in binaire onderdelen die maar op één manier kunnen worden uitgelegd. De belangrijkste verschillen met traditionele overeenkomsten zijn wat ons betreft 1) de onveranderlijkheid van de geautomatiseerde afspraken en 2) het idee dat een smart contract zichzelf uitvoert zonder dat partijen daarop invloed kunnen uitoefenen.

2.1 Onveranderlijkheid

Door de aard van de techniek zijn afspraken die in een blockchain zijn vastgelegd niet of nauwelijks achteraf aan te passen.[15] De code bepaalt de werking en de uitkomst van de overeenkomst en staat in beginsel voor de volledige levensduur van het smart contract vast. Dit betekent tevens dat reeds gemaakte afspraken niet kunnen verkleuren, of anders worden ingevuld, door externe factoren, tenzij deze factoren specifiek zijn benoemd in het smart contract. Hoewel betoogd kan worden dat dit ook geldt voor een traditioneel contract, ontbreekt bij een smart contract door de binaire vormgeving van de afspraken de ruimte voor context en achtergrond van de afspraken. Voor zover de context relevant is voor de inhoud van de afspraken, zal deze context onderdeel gemaakt moeten worden van de triggers en consequenties. Dit is bij de huidige stand van de techniek in veel gevallen niet mogelijk.[16]

De discussie of een smart contract zich hierdoor feitelijk buiten de geldende rechtstelsels plaatst is onderdeel van de discussie code is/as law. Zoals Lessig beschrijft in zijn boek Code 2.0[17] bepalen programmeurs de technische kaders die uiteindelijk de werking en beperkingen van software bepalen. Hiermee, zo is de stelling, reguleren programmeurs gedrag van gebruikers net zoals wetten, sociale normen en marktmechanismen dat doen. Een interessante vraag die daarbij hoort is in hoeverre externe factoren de uitvoering van de software zouden moeten kunnen beïnvloeden. Of anders gezegd, zou er een uitzondering moeten zijn op het beginsel dat de code doorslaggevend is, ook als de uitkomst van de code ongewenst is? Deze vraag vormde de kern van de discussie rondom een hack van The DAO,[18] een smart contract toepassing op het populaire Ethereum platform. Voor een meer gedetailleerde beschrijving van deze hack en de consequenties daarvan verwijzen wij naar het artikel van Tjong Tjin Tai.[19] Welke waarde je ook aan code is law zou hechten, duidelijk is dat smart contracts zich niet in een juridisch vacuüm bevinden. De rechtsregels van de jurisdictie die op grond van internationaal privaatrecht van toepassing zijn op de relatie tussen partijen bij een smart contract, zijn in beginsel ook van toepassing op het smart contract zelf, tenzij er andere afspraken zijn gemaakt op dit punt. Op dit punt komen wij in paragraaf 3 terug.

Meer praktisch bezien dwingt de onveranderlijkheid van de code er in ieder geval toe dat alle relevante te automatiseren afspraken in het begin volledig en op de juiste wijze worden opgenomen in het smart contract. Ook moet de maker voor zover mogelijk anticiperen op toekomstige ontwikkelingen. Als de maker in het opstellen van het smart contract steken laat vallen is de onduidelijkheid die hiervan het gevolg is niet eenvoudig te herstellen. Dit vereist een specifieke en hoge standaard aan de opzet en juridische inhoud van het contract.

2.2 Automatische nakoming

Anders dan traditionele overeenkomsten voeren smart contracts zichzelf uit, zuiver op basis van de instructies en zonder tussenkomst van de gebruiker. Dit heeft niet alleen tot gevolg dat contractuele rechten niet hoeven te worden ingeroepen doormiddel van een praktische handeling om ze te effectueren (de vordering tot nakoming) aangezien het contract daarin voorziet, maar ook dat er geen handeling van de desbetreffende partij(en) vereist is om de contractuele verplichtingen uit te voeren (het daadwerkelijke nakomen). Waar je bij een traditionele overeenkomst een onduidelijke bepaling anders in kunt vullen door er praktisch anders mee om te gaan dan er letterlijk zou staan, is dit bij een smart contract niet mogelijk. Althans, deze alternatieve uitleg zal de uitvoering van de letterlijke uitleg niet blokkeren of aantasten. Het smart contract zal de ingevoerde instructies immers naar de letter (of wellichter zuiverder; het cijfer) uitvoeren.

Dit is wat ons betreft wezenlijk nieuw, maar is het wellicht niet direct duidelijk in hoeverre dit verschilt van bijvoorbeeld de geautomatiseerde verplichtingen die in het dagelijkse betaalverkeer voorkomen. Neem een periodieke overschrijding die de gebruiker in zijn online-bankieromgeving heeft ingesteld. Ook in deze situatie is er een event (de gekozen periodieke datum) en een consequentie (het overschrijven van een bepaald bedrag), en ook hiervoor geldt dat de gebruiker niet iedere keer actief de bank hoeft te benaderen om de overschrijving uit te voeren. Het intreden van het event is voor de software van de bank voldoende aanleiding om de daaraan verbonden consequentie uit te voeren. Het wel of niet uitvoeren blijft echter een keuze van de bank, of blijft in ieder geval in de invloedsfeer van de bank. De ingegeven instelling is feitelijk niet meer dan een opdracht die de bank op basis van een afspraak uit zal voeren. Er kunnen echter allerlei redenen of situaties zijn waardoor de bank deze afspraak niet zal kunnen of willen nakomen. Zo kan er een situatie van verhoogd risico zijn met de debiteur, kan het betaalsysteem eruit liggen, kan de bank op basis van zijn zorgplicht besluiten om de opdracht niet uit te voeren of uit te stellen, etc.

Dit is waar het verschil met de smart contract benadering zichtbaar wordt. Als de periodieke overschrijving in een smart contract zou zijn neergelegd zou de software deze simpelweg uitvoeren.[20] Menselijke tussenkomst is hierbij niet alleen onnodig, maar ook onmogelijk. Als de instructies eenduidig zijn vermindert dit de kans op fouten en misbruik, maar tegelijkertijd is er geen ruimte is voor externe factoren, een nadere beschouwing van de bedoeling van partijen of gewijzigde omstandigheden.[21] Dit betekent ook dat eventuele fouten in de code in de blockchain blijven zitten zolang deze bestaat. Het ontbreken van de mogelijkheid van menselijke tussenkomst wordt gezien als een inherent risico van smart contracts en was voor de voorzitter van de Australian Securities and Investments Commission (ASIC) zelfs reden om te pleiten voor de invoering van een kill switch, die het mogelijk zou maken om het vermogen van smart contracts om voorschriften zelf in uitvoering te brengen te stoppen in tijd van nood.[22]

3 Juridische aspecten

Smart contracts moeten worden beoordeeld en uitgelegd aan de hand van de rechtsregels die op grond van internationaal privaatrecht van toepassing zijn. Bij de uitleg van overeenkomsten stelt de Hoge Raad de zogenoemde Haviltex-norm,[23] ofwel de geobjectiveerd subjectieve uitleg, centraal. Hierbij zijn alle omstandigheden van het geval van belang,[24] en worden deze gewaardeerd naar hetgeen de redelijkheid en billijkheid meebrengen.[25] Hoewel ook binnen deze norm plaats kan zijn voor een primair tekstuele (objectieve) uitleg van de overeenkomst, is de drempel hiervoor hoog. Uit de jurisprudentie komt naar voren dat dit niet snel wordt aangenomen als er sprake is van professionele partijen die met deskundige bijstand en na intensieve onderhandelingen tot een bepaalde uitkomst zijn gekomen, en liefst ook een entire agreement clausule zijn overeengekomen. En zelfs in deze omstandigheden blijven de omstandigheden van het geval steeds leidend.[26]

Dit verhoudt zich per definitie slecht met code as law en met smart contracts in het algemeen. Deze passen immers geen andere factoren toe dan de code zelf bij de beoordeling van de inhoud en consequenties van de overeenkomst. De voor de Hoge Raad leidende omstandigheden van het geval worden simpelweg niet meegenomen bij de uitvoering van een smart contract. Het is wel geopperd dat artificial intelligence, ofwel kunstmatige intelligentie, hier een belangrijke rol zou kunnen gaan spelen. Het idee is dat artificial intelligence in staat zou moeten zijn om aanpassingen te doen aan code op basis van ingebedde beginselen van redelijkheid en billijkheid en economische efficiëntie,[27] of de uitvoering van bepaalde events zou kunnen opschorten of aanpassen als de omstandigheden van het geval daartoe aanleiding geven. Vooralsnog is de stand van de techniek echter nog (lang) niet zover.[28]

De vraag is dan ook wat dit betekent voor smart contracts als zodanig. Als je moet vaststellen dat een smart contract per definitie zonder zicht op de omstandigheden van het geval (met mogelijk een verkeerde uitleg als gevolg) en zonder menselijke tussenkomst rechtshandelingen doet, kun je je afvragen of dit de geldigheid van deze rechtshandelingen aantast, een wanprestatie oplevert. Wat ons betreft is dit niet zonder meer het geval. Zeker in de situatie waarin partijen er zelf bewust en met kennis van zaken en de eigenschappen van smart contracts voor kiezen om een smart contract te sluiten, zou dit wat ons betreft moeten worden meegewogen bij het oordeel of de uitkomsten van een smart contract achteraf kunnen worden aangetast. Of in ieder geval tot de situatie dat een rechter een resultaat van een smart contract niet snel als onbedoeld of ongewenst terzijde moet schuiven. In lijn met de opvattingen van de Hoge Raad over het belang van de aard van de overeenkomst bij de uitleg daarvan[29] zou je in de beschreven situatie wat ons betreft kunnen pleiten voor een relatief hoge drempel voor aantastbaarheid van een smart contract, zoals dat bijvoorbeeld ook geldt bij een vaststellingsovereenkomst.[30]

Naast de aard van de overeenkomst kan ook de inhoud daarvan invulling geven aan de uitleg. Als partijen bij een smart contract verklaren dat zij de uitkomsten van het smart contract in beginsel accepteren en dat bijvoorbeeld in de considerans opnemen, is dit een factor die ook voor de rechter relevant zal kunnen zijn.31 Een stap verder is het opnemen van een bepaling waarin partijen overeenkomen dat zij de uitkomsten niet zullen voorleggen aan een rechter, ook als deze ongewenst of oneerlijk zouden zijn. Hoewel zo’n bepaling een duidelijke indicatie is van de oorspronkelijke bedoeling van partijen en hun kennelijke wens om de consequenties te accepteren, geldt ook voor deze bepaling dat deze opzij kan worden gezet aan de hand van de Haviltex norm als de omstandigheden van het geval hiertoe aanleiding geven. Echte bescherming tegen aantasting gaat zo’n bepaling dan ook niet bieden. Een andere mogelijke bescherming tegen ongewenste uitkomsten van een smart contract biedt een beroep op het ontbreken van de wilsovereenstemming. Hiermee zou de benadeelde kunnen betogen dat het smart contract op basis van een door hem nooit bedoelde lezing namens hem een bepaalde rechtshandeling verricht. Dit zou bijvoorbeeld kunnen spelen bij een smart contract dat een koop van een bepaald product tot stand brengt als de prijs onder een bepaald niveau zakt. Een beroep op het ontbreken van wilsovereenstemming zal bij het gebruik van smart contracts, net als bij ambient intelligence oplossingen,32 wat ons betreft niet snel slagen. Dit is in de eerste plaats omdat de geprogrammeerde events uiting geven aan wat wel wordt aangeduid als de geprogrammeerde wil.[33] De gevolgen van de uitvoering van het smart contract komen daarmee in beginsel voor rekening van de partij namens wie het smart contract rechtshandelingen verricht. Voor zover de rechtshandelingen worden verricht jegens een derde, geldt voor deze derde nog het aanvullende argument dat een ruime lezing van art. 3:35 BW inzake het gerechtvaardigd vertrouwen in de weg zou moeten staan aan een beroep op het ontbreken van de wilsverklaring.[34]

We constateren dat ook bij smart contracts toetsing van de inhoud en de gevolgen altijd mogelijk blijft, in lijn met de uitlegjurisprudentie, maar ook dat de gebruiker van een smart contract zich niet eenvoudig achter de handelingen van het smart contract kan verschuilen met een beroep op ontbrekende wilsovereenstemming. Het cruciale punt bij smart contracts is echter dat deze toetsing altijd achteraf plaats zal vinden. Anders dan bij traditionele overeenkomsten zal een wederpartij contractuele nakoming niet vooraf kunnen weigeren met een beroep op de derogerende werking van de redelijkheid en billijkheid of met de stelling dat een bepaling anders moet worden uitgelegd. Een smart contract zal zichzelf immers uitvoeren naar de letter van de code.

4 Conclusie

In dit artikel hebben wij een aantal praktische en juridische aspecten van smart contracts nader belicht. Als smart contracts inderdaad de vlucht nemen die steeds meer auteurs verwachten, breken voor contractjuristen interessante tijden aan. Niet alleen omdat naast de tekstverwerker ook scripting tools zullen moeten worden gebruikt, maar ook omdat de consequenties van een vergissing of onduidelijke formulering groot zijn. Nu bij een smart contract de inhoud bij het sluiten van het smart contract vaststaat én het smart contract automatisch wordt uitgevoerd, is correctie alleen achteraf mogelijk. We hebben geconstateerd dat een rechter ook bij smart contracts de beschikking heeft over zijn gebruikelijke arsenaal aan uitlegjurisprudentie, maar hebben ook betoogd dat een onderbouwde keuze voor smart contracts door partijen een omstandigheid is die moeten worden meegewogen bij een beslissing om het smart contract aan te tasten.

5 Eindnoten

1. Joost Schmaal en Esther van Genuchten zijn IT-advocaat bij Kennedy Van der Laan te Amsterdam.

2. Zie zeer recent: C. Prins, ‘De Blockchain: uitdaging voor het recht’, NJB 2016/1941, E. Tjong Tjin Tai, ‘Smart contracts en het recht’, NJB 2017/146, en M. von Haller Gronbaek, ‘Blockchain 2.0, smart contracts and challenges’, 16 juni 2016, en J.J. Linnemann, ‘Juridische aspecten van (toepassingen van) blockchain’, Computerrecht 2016/218.

3. Kamerstukken I 2016/17, 33009, nr. F.

4. N. Szabo, ‘Smart Contracts: Building Blocks for Digital Markets’, UvA.nl (oorspronkelijke vindplaats onbekend).

5. N. Szabo, ‘Formalizing and Securing Relationships on Public Networks’, First Monday 1997, vol. 2, nr. 9.

6. N. Szabo publiceert door de jaren heen verschillende artikelen over smart contracts, waaronder een drafting guide voor het opstellen van smart contracts. (N. Szabo, ‘A Formal Language for Analyzing Contracts’, 2002.

7. Voor een uiteenzetting van de bronnen over Bitcoin: J.J. Linnemann, ‘Juridische aspecten van (toepassingen van) blockchain’, Computerrecht 2016/218.

8. Zie hierover bijvoorbeeld J. Stark, ‘Making Sense of Blockchain Smart Contracts’, 4 juni 2016.

9. Antony Lewis is de auteur van het blog BitsonBlocks, waarop hij de techniek, toepassingen en mogelijkheden van smart contracts beschrijft.

10. A. Lewis, ‘A gentle introduction to smart contracts’, 1 februari 2016.

11. Etherscripter.com.

12. De website Etherscripter.com heeft verschillende voorbeelden en kent een editor waarmee eigen scripts kunnen worden geschreven. Bovenstaand voorbeeld is, vertaald, gebaseerd op een van de voorbeelden van Etherscripter.

13. Art. 7:1: ‘Koop is de overeenkomst waarbij de een zich verbindt een zaak te geven en de ander om daarvoor een prijs in geld te betalen.’

14. Monax, het bedrijf achter het Eris platform, beschrijft dit principe als volgt: ‘The rat ionale behind dual integrat ion is that for the forseeable future, legal systems are unlikely to resolve disputes stemming from smart contracts solely on the basis of their code. Courts will apply the defaults for similar prose agreements, an end that may not ref lect the intent ion of the smart contract ing part ies. Because of the risks involved in enforcing smart contracts by code alone, we highly encourage all smart contract systems developers to ut ilize dual integrat ion of some kind. Dual integrat ion means that a smart contract will be linked to a document that can be enforced by a court.’

15. Voor de uitleg waarom dit zo is verwijzen we naar J.J. Linnemann, ‘Juridische aspecten van (toepassingen van) blockchain’, Computerrecht 2016/218.

16. Wel is geopperd dat artificiële intelligentie hier een belangrijke rol kan gaan spelen in de toekomst. Zie bijvoorbeeld M. von Haller Gronbaek, ‘Blockchain 2.0, smart contracts and challenges’, 16-06-2016.

17. In real space, we recognize how laws regulate – through const itut ions, statutes, and other legal codes. In cyberspace we must understand how a different ‘code’ regulates – how the software and hardware (i.e., the ‘code’ of cyberspace) that make cyberspace what it is also regulate cyberspace as it is. As William Mitchell puts it, this code is cyberspace’s ‘law.’ ‘Lex Informat ica,’ as Joel Reidenberg first put it, or better, ‘code is law.’ L. Lessig, Code 2.0, Codev2.cc.

18. The DAO was een digitaal en gedecentraliseerd venture capital fonds, dat draaide op Ethereum, Wikipedia.org.

19. E. Tjong Tjin Tai, ‘Smart contracts en het recht’, NJB 2017/146.

20. Om nog dichterbij de smart contract toepassingen te blijven kan in plaats van bank ook ‘Ethereum’ worden gelezen, en in plaats van geld ‘Ether’.

21. J. Eyers & M. Han, ‘Lawyers prepare for ‘driverless M&A’ as smart contracts era dawns’, Financial Review, 19-6-2016.

22. Voorzitter Greg Medcreaft van de Australian Securities and Investments Commission (ASIC).

23. HR 13 maart 1981, ECLI:NL:HR:1981:AG4158, NJ 1981/635 (Ermes/Haviltex).

24. HR 5 april 2013, ECLI:NL:HR:2013:BY8101 (Lundiform/ Mexx). Zie ook HR 21 april 1995, ECLl:NL:HR:1995:ZC1706, RvdW 1995/98 (Kakkenberg/Kakkenberg), HR 20 februari 2004, ECLl:NL:HR:2004:A01427, NJ 2005/493 (DSM/Fox), en HR 22 september 2006, ECLl:NL:HR:2006:AX1571, NJ 2006/521 (samenlevingscontract).

25. HR 20 februari 2004, ECLI:NL:HR:2004:AO1427, NJ 2005/493 (DSM/Fox), HR 2 februari 2007, ECLI:NL:HR:2007:AZ4410, NJ 2008/104 (NBA/ Stichting Meersen), alsmede HR 23 april 2010, ECLI:NL:HR:2010:BL5262 (Halliburton).

26. Zie in het bijzonder HR 5 april 2013, ECLI:NL:HR:2013:BY8101 (Lundiform/Mexx).

27. M. von Haller Gronbaek, ‘Blockchain 2.0, smart contracts and challenges’, 16-06-2016.

28. Een fundamenteel problem met artificial intelligence is daarnaast dat een smart contract dat onbepaalde variaties in de uitkomsten toelaat, niet langer deterministic is. Zie hierover: Why do smart contract languages need to be deterministic?, Ethereum.stackexchange.com.

29. HR 1 juli 1985, ECLI:NL:HR:1985:AB7672, NJ 1986/692 (Frenkel/ KRO).

30. HR 21 december 2007, ECLI:NL:HR:2007:BB9236, evenals de conclusie van A.G. Huydecoper, specifiek over de beperkte aantastbaarheid van een vaststellingsovereenkomst.

31. HR 30 november 1951, NJ 1953/76 (Van Stijverden/Van Olst).

32. Zie over elektronisch contracteren in dit verband M. Voulon, Automat isch contracteren (diss. Leiden), Leiden University Press 2010, p. 241-286 en over ambient intelligence oplossingen J.J. Linnemann en J.B. Schmaal, ‘Intelligent contracteren’, Computerrecht, 2010/6, 175.

33. J.J. Linnemann en J.B. Schmaal, ‘Intelligent contracteren’, Computerrecht, 2010/6, 175.

34. J.J. Linnemann en J.B. Schmaal, ‘Intelligent contracteren’, Computerrecht, 2010/6, 175.