UNIVERSITEIT VAN AMSTERDAM
M
ASTERSCRIPTIEPrivaatrecht - Commerciële Rechtspraktijk
UITLEG VAN CODETAAL IN SMART CONTRACTS:
VAN HAVILTEX-NORM NAAR SMART CONTRACT-NORM
Een literatuur- en jurisprudentieonderzoek naar (i) de juridische duiding van smart contracts en (ii) de mogelijkheid om de normen met betrekking tot het uitleggen van contractuele bepalingen zoals gecreëerd in de rechtspraak toe te passen op codetaal in smart contracts
N
AAM: Elise StormmesandS
TUDENTNUMMER: 11364556E
-MAIL: elise.stormmesand@student.uva.nlB
EGELEIDER: dhr. mr. C.J.W. BaaijD
ATUM: maandag 8 januari 2018A
BSTRACTMogelijk staan we aan de vooravond van één van de grootste veranderingen in de digitale wereld sinds het ontstaan van het Internet. Blockchain wordt wel beschreven als een technologie die de wereld gaat veranderen. Eén van de mogelijkheden van het gebruik van deze technologie is het uitvoeren en opslaan van afspraken die zijn uitgedrukt in computercodes: als x gebeurt is y de consequentie. Deze toepassing wordt een 'smart contract' genoemd. De juridische duiding van blockchain en smart contracts is tot op heden onduidelijk. In deze scriptie is door middel van een literatuur- en jurisprudentieonderzoek onderzocht wat de mogelijke juridische duiding van smart contracts is en of het mogelijk is om de bestaande normen met betrekking tot uitleg van contractuele bepalingen zoals gecreëerd in de rechtspraak toe te passen op de codetaal in smart contracts. In dit onderzoek wordt geconcludeerd dat een smart contract gekwalificeerd kan worden als een overeenkomst in de zin van afdeling 6.5.1 van het Burgerlijk Wetboek. Vervolgens wordt geconstateerd dat de huidige normen met betrekking tot de uitleg van bepalingen in overeenkomsten niet geschikt lijken te zijn voor toepassing op smart contracts. Daarom wordt gepleit voor een zogenoemde 'smart contract-norm' met passende uitgangspunten en factoren. De twee uitgangspunten zijn de taalkundige betekenis van de codetaal in een smart contract en de partijbedoelingen. Daarnaast zijn er vier factoren denkbaar die een rol kunnen spelen bij de verdeling van het gewicht tussen de taalkundige betekenis van de codetaal en de partijbedoelingen, namelijk (i) of de ‘initiële’ overeenkomst tussen partijen mondeling of schriftelijk was, (ii) of het smart contract onderdeel is van een commerciële transactie of dat het gaat om een commercieel smart contract, (iii) wie het smart contract heeft geprogrammeerd en (iv) of het smart contract op een open blockchain of een gesloten blockchain is geplaatst.
I
NHOUDSOPGAVEInleiding ... 5
1. Blockchain technologie en smart contracts ... 9
1.1 Inleiding ... 9
1.2 Blockchain ... 9
1.2.1. De blockchain technologie ... 9
1.2.2. Open en gesloten blockchain ... 10
1.3 Smart contracts ... 12
1.3.1. Voorbeeld smart contract ... 12
1.4 Conclusie ... 15
2. Smart contract: een overeenkomst in de zin van afdeling 6.5.1 van het Burgerlijk Wetboek? ... 16
2.1 Inleiding ... 16
2.2. Meer dan alleen code ... 16
2.3 Juridische betekenis smart contract ... 17
2.4 Conclusie ... 20
3. Uitleg van codetaal in een smart contract ... 22
3.1 Inleiding ... 22
3.2. Uitleg van codetaal ... 22
3.2.1. Uitlegsituaties ... 22
3.2.2. Tijdens een procedure... 25
3.3 Rechtspraak ... 27
3.3.1 Haviltex-norm... 27
3.3.2. Cao-norm ... 28
3.3.3. Commerciële contracten ... 30
3.4 Conclusie ... 31
4. Effectieve smart contract-norm ... 33
4.1 Inleiding ... 33
4.2. Smart contract-norm ... 33
4.2.1. Effectiviteit smart contracts ... 33
4.2.2. Partijbedoeling of taalkundige betekenis van de codetaal ... 34
4.2.3. Factoren ... 35
4.3 Smart contract-norm in de praktijk ... 36
Conclusie ... 39 Literatuurlijst ... 41
I
NLEIDINGOntwikkeling van digitale technologieën kan de mensheid verder brengen, maar kan ook zorgen voor juridische uitdagingen. Eén van de ontwikkelingen op het gebied van digitale technologie is blockchain. Blockchain kan vergeleken worden met een openbare en decentrale database, waar onveranderbare, chronologische lijsten met álle transacties worden bijgehouden. Deze database wordt niet door een centrale autoriteit beheerd.1 De blockchain technologie biedt onder andere de mogelijkheid om contracten te laten uitvoeren door computercodes.2 Deze contracten worden ‘smart contracts’ genoemd. Een smart contract wordt automatisch geverifieerd en uitgevoerd op de blockchain, zonder tussenkomst van partijen.3 Het uitvoeren van een smart contract gaat daarom sneller en is efficiënter dan wanneer de overeenkomst 'gewoon' wordt uitgevoerd. Een smart contract is geschikt voor meerdere soorten overeenkomsten.4 Een smart contract kan bijvoorbeeld gebruikt worden om automatische betaling te genereren als het juiste product in de juiste hoeveelheid is geleverd: als alle pakketten automatisch zijn gescand en de juiste hoeveelheid pakketten van type x zijn geleverd, wordt er automatisch uitbetaald. Tevens kan een smart contract worden gebruikt in de verzekeringswereld: als x gebeurt, betaalt de verzekeringsmaatschappij uit. Verder kan een smart contract worden gebruikt voor crowdfunding: als voor datum x bedrag y op rekening z staat, wordt bedrag y uitgekeerd aan de beheerder van de rekening.5 Een smart contract kan worden gebruikt door zowel consumenten als bedrijven.
Omdat blockchain en smart contracts niet wettelijk zijn gereguleerd, staan sommige mogelijkheden die deze nieuwe technologieën bieden op gespannen voet met de huidige regelgeving. Alles wat op de blockchain plaatsvindt, vindt in wezen plaats 'buiten de wet'. Er is niets geregeld qua toezicht, regulatie en regelgeving. Het idee achter blockchain is dat overeenstemming wordt bereikt over de cryptografische geldigheid en correctheid van de transactie zonder raadpleging van een gecentraliseerde informatievoorziening, zoals een
bank.6 Bij de goedkeuring van transacties op de blockchain wordt alleen geoordeeld over de
1
Prins, NJB 2016/1941, p. 2817; Raskin, Geo. L. Tech. Rev 2017/305, p. 308.
2 Rizzo, Coindesk 4 augustus 2016; Schmaal en Van Genuchten, IR 2017/1, p. 13; Savelyev, Higher School of Economics Research Paper
14 december 2016, p. 8.
3 Linneman, Computerrecht 2016/28, p. 324; Tjong Tjin Tai, NJB 2017/146, p. 176-177.
4 Van Eijck, Smit & Wong-A-Tjong Kamer van Koophandel oktober 2017, p. 5 en 7; Catalini & Gans, Rotman School of Management Working Paper 21 september 2017, p. 28-29; De Backer & De Boe, Computerrecht 2017/252, p. 357-358. De wet stelt op de dit moment
eisen voor bijvoorbeeld overdracht van eigendom. Als eigendom via smart contracts op de blockchain kan worden overgedragen, moet de wet in de toekomst worden gewijzigd.
5 Werbach & Cornell, 67 Duke Law Journal 18 maart 2017, p. 11.
codes, hashwaardes en bijbehorende algoritmes.7 Er vindt geen goedkeuring plaats met betrekking tot de inhoud van de transactie. Dit betekent dat voor het goedkeuren van een transactie niet relevant is of de inhoud van de transactie legaal of illegaal is.
De juridische positie van de blockchain technologie en smart contracts in het Nederlandse rechtssysteem en dus het privaatrecht is onbepaald.8 In de literatuur wordt gediscussieerd over de vraag of een smart contract binnen de rechtsorde kan vallen en over de vraag of een smart contract een wettelijke overeenkomst kan zijn.9 Enerzijds wordt beargumenteerd dat partijen de wil en intentie hebben om de afspraken te laten uitvoeren door een smart contract op een blockchain, aan de andere kant wordt beargumenteerd dat partijen expliciet voor de blockchain technologie hebben gekozen, terwijl zij weten dat deze technologie niet wettelijk gereguleerd is. Indien een smart contract kan worden gekwalificeerd als een wettelijke overeenkomst, geeft dit partijen de mogelijkheid om de rechter te laten oordelen over de uitleg van de in codetaal vastgelegde overeenkomst op het moment dat partijen er onderling niet uitkomen.
De vraag is wanneer zich een situatie voordoet bij het gebruik van smart contracts die om uitleg vraagt. Het programmeren van een mondelinge of schriftelijke overeenkomst in een smart contract vereist kennis van programmeren, blockchain en smart contracts. Op dit moment zullen partijen daarom genoodzaakt zijn om een programmeur in te schakelen die het smart contract opstelt. Een onjuiste implementatie van de ‘initiële’ bedoeling van partijen door een programmeur in een smart contract kan leiden tot verschil tussen de originele bedoeling van partijen en de uitkomst van het smart contract.10 Naast het verschil in de partijbedoelingen en de uitkomst het smart contract, kunnen computercodes vatbaar zijn voor
bugs en errors.11 De uitkomst van een smart contract kan daardoor niet overeenkomen met wat partijen voor ogen hadden bij het maken van de afspraken. Een voorbeeld hiervan is de 'DAO hack': anders dan de naam doet vermoeden was geen sprake van fraude of hack, maar werd er misbruik gemaakt van een fout in een smart contract. Hierdoor werd 55 miljoen dollar weggesluisd.12 Andere voorbeelden van bugs en errors zijn het verkeerd interpreteren of gebruiken van de functies van de programmeertaal, het op zo'n manier wijzigen van een
7 Raskin, Geo. L. Tech. Rev 2017/305.
8 Kamerstukken 33 009, nr. 30; zie ook de brief van de Minister van Veiligheid en Justitie van 16 november 2016 over toekomst bestendige
wetgeving en wetgevingsproces, kenmerk: 159545.01u.
9 Clack, Bakshi & Braine, Cornell University Library 15 maart 2017, p. 1-2; Schmaal en Van Genuchten, IR 2017/1, p. 78; Tjong Tjin Tai NJB 2017/146, p. 179-182; Stark, Coindesk 4 juni 2016.
10 Van Heukekom, Naves & Van Graafeiland, Pels Rijcken 28 september 2017, p. 6. 11 Delmolino, Arnett, Kosba e.a. IACR Cryptology ePrint Archive 18 november 2015, p. 2. 12 Van Eijck, Smit & Wong-A-Tjong Kamer van Koophandel oktober 2017, p. 6.
gedeelte van de codes in een smart contract zodat er gevolgen zijn voor het andere gedeelte van het smart contract zonder dat dit laatste gedeelte is aangepast, of een typefout tijdens het programmeren van een smart contract. In al deze situaties is uitleg gewenst met betrekking tot de afspraken die in een smart contract zijn uitgedrukt of de uitkomst van een smart contract.
Het is de vraag of de rechter bij beoordeling van de uitleg van smart contracts de bestaande normen met betrekking tot de uitleg van contractuele bepalingen zoals deze zijn geformuleerd in de rechtspraak kan toepassen of dat een nieuwe norm moet worden ontwikkeld. Een smart contract bestaat uit codes en de normen in de huidige rechtspraak hebben betrekking op bewoordingen van bepalingen in overeenkomsten. Daarnaast is het contracteren via de blockchain technologie een nieuwe manier van contracteren waarbij mogelijk een andere weging van factoren past. De tekst van de ‘initiële’ overeenkomst zou wellicht een rol kunnen spelen bij de uitleg van het smart contract, maar zal niet leidend zijn. Kortom, stel dat een nieuwe maatstaf moet worden ontwikkeld, dan moet deze nieuwe maatstaf effectief zijn: de maatstaf moet geschikt zijn voor codetaal in smart contracts.
In deze scriptie wordt onderzocht of de actuele leer zoals ontwikkeld in de rechtspraak met betrekking tot het uitleggen van contractbepalingen kan worden toegepast op de uitleg van codetaal in een smart contract. De onderzoekshypothese van deze scriptie luidt als volgt: Een
smart contract is een wettelijke overeenkomst in de zin van afdeling 6.5.1 van het Burgerlijk Wetboek. Het juridische kader dat in de rechtspraak is gecreëerd met betrekking tot het uitleggen van contractuele bepalingen, lijkt niet passend te zijn voor uitleg van de in codetaal uitgedrukte afspraken in een smart contract. Daarom zal er een effectieve nieuwe norm, een 'smart contract-norm', moeten worden ontwikkeld in de rechtspraak.
Deze hypothese wordt getoetst aan de hand van een literatuur- en jurisprudentieonderzoek. Om de juridische implicaties van blockchain en smart contracts te begrijpen is het van belang om de verschillende technische elementen van blockchain en smart contracts te bespreken. In dit onderzoek wordt een eigen juridische betekenis gegeven aan bepaalde elementen van deze technologieën. In hoofdstuk 1 wordt uitgelegd hoe de blockchain technologie werkt. Daarnaast wordt in dit hoofdstuk ook aandacht besteed aan de werking van smart contracts en wordt er een voorbeeld gegeven van een smart contract. In hoofdstuk 2 wordt uitgelegd waarom een smart contract binnen de rechtsorde kan vallen en wordt uiteengezet waarom een smart contract gezien kan worden als een wettelijke overeenkomt in de zin van afdeling 6.5.1
van het Burgerlijk Wetboek. Vervolgens wordt in hoofdstuk 3 uitgewerkt in welke situaties de codetaal in een smart contract uitgelegd moet worden en op welke manier een rechter over codetaal kan oordelen tijdens een procedure. Aansluitend wordt vastgesteld dat de huidige normen zoals geformuleerd in de rechtspraak met betrekking tot het uitleggen van contractuele bepalingen, niet geschikt lijken te zijn voor de uitleg van codetaal in smart contracts. In hoofdstuk 4 wordt gekeken aan welke vereisten een nieuwe norm zou moeten voldoen en wordt toegelicht hoe deze norm in de praktijk zou kunnen werken.
1.
B
LOCKCHAINT
ECHNOLOGIE ENS
MARTC
ONTRACTS 1.1 InleidingDe term 'smart contract' is voor het eerst gebruikt in een paper van Szabo in 1994.13 In dit paper wordt een smart contract beschreven als een gecomputeriseerd transactieprotocol dat de bepalingen van een contract uitvoert.14 Szabo geeft als voorbeeld de werking van een snoepautomaat: op het moment dat de machine een geldmuntje inslikt, zorgt de achterliggende software dat het gekozen product naar het uitgiftepunt wordt geleid. De transactie kan niet tussentijds worden gestopt en is, wanneer uitgevoerd, onomkeerbaar.15 Het concept dat Szabo beschreef miste een mechanisme om handhaving en het overdragen van waarde te garanderen.16 Pas met de opkomst van blockchain is er opnieuw naar het concept van Szabo gekeken.17 Door de mogelijkheden die blockchain biedt, sluit de definitie van een smart contract zoals door Szabo beschreven niet meer aan bij de betekenis van de term smart contract die in de huidige literatuur wordt gebruikt.18 In dit hoofdstuk wordt uiteengezet hoe de blockchain technologie werkt en wordt een voorbeeld van een smart contract gegeven en toegelicht.
1.2 Blockchain
1.2.1 De blockchain technologie
In de huidige maatschappij houdt elk bedrijf een database bij met een administratie van al zijn transacties. Het bedrijf bepaalt voor wie de database toegankelijk is en wie wat mag veranderen. Blockchain verschilt essentieel van zo’n administratie. Blockchain wordt niet beheert door één centrale autoriteit, er is dus geen beheerder. Blockchain kan worden gezien als een digitale database of een digitaal grootboek waarin informatie op chronologische volgorde wordt opgeslagen.19 Het grootboek wordt niet opgeslagen op één centrale plaats, maar is verspreid over verschillende computers en servers die met elkaar zijn verbonden.20 Deze computers en servers worden nodes genoemd en samen vormen deze nodes een netwerk. In deze context is een node dus een computer (of een ander apparaat) dat is aangesloten op het netwerk. Elke node beschikt over een volledige of een gecomprimeerde versie van de database.
13 Szabo 1994. 14 Szabo 1994.
15 Werbach & Cornell, 67 Duke Law Journal 18 maart 2017, p. 9. 16 Werbach & Cornell, 67 Duke Law Journal 18 maart 2017, p. 7-10. 17 Wright & De Filippi, SSRN 25 juli 2017, p. 4-6.
18 Schmaal en Van Genuchten, IR 2017/1, p. 12; Stark, Coindesk 4 juni 2016; Tjong Tjin Tai, NJB 2017/146, p. 176-77. 19 Linneman, Computerrecht 2016/28, p. 319.
Eén van de essentiële kenmerken van blockchain is dat het wijzigen van blokken vraagt om enorme 'wiskundige' rekenkracht.21 Een uitstapje naar de cryptografie is nodig om uit te leggen waarom dit zo is. Blockchain bestaat uit een keten ('chain') van blokken ('blocks') met informatie. Door middel van een wiskundige functie, de hashfunctie, wordt de
hashwaarde van een blok berekend. De blokken in de blockchain zijn door middel van een
wiskundige formule met elkaar verbonden: deze zogenoemde hashpointer linkt naar het vorige blok in de blockchain en naar de hashwaarde die bij dat vorige blok hoort.22 Een wijziging van een blok zorgt voor een wijziging in de hashwaarde. Dit heeft tot gevolg dat de
hashpointer die naar dit blok verwijst, ook wijzigt. Een wijziging in één blok zorgt ervoor dat
alle hashwaarden van de voorafgaande blokken moeten worden gewijzigd en dit vraagt om grote wiskundige rekenkracht. Een wijziging aanbrengen in één blok is daardoor nagenoeg onmogelijk.23 Het is wel mogelijk om een 'kill-function' te programmeren, waardoor het eindmoment van een smart contract gedefinieerd.24
Het toevoegen van een nieuw blok aan de blockchain gebeurt aan de hand van de toestemming van nodes: de nodes valideren de transactie.25 Dit is echter geen inhoudelijke goedkeuring maar heeft betrekking op de cryptografische geldigheid en correctheid. Op een open blockchain is de meest gebruikte manier van valideren 'Proof of Work'.26 Het valideren van een blok op deze manier wordt ook wel mining genoemd.27 De nodes die meedoen aan de validatie worden miners genoemd. De miners proberen door middel van algoritmes de unieke
hashwaarde van de transactie te raden door steeds een nieuw nummer in te vullen.28 Deze methodiek wordt 'decentrale consensus' genoemd.29 Als één van de nodes het juiste antwoord invult, krijgt deze node een beloning (uitgekeerd in cryptovaluta; een virtuele digitale valuta die niet door een centrale autoriteit wordt gecontroleerd30) omdat hij de hashwaarde heeft geraden.31 Na het ontcijferen van de hashwaarde wordt de (voorgenomen) transactie samen
21 Van Os, TBR 2017/140, p. 926; Catalini & Gans, Rotman School of Management Working Paper 21 september 2017, p. 24-26. 22 Linneman, Computerrecht 2016/28, p. 320.
23 Van Os, TBR 2017/140, p. 926; Catalini & Gans, Rotman School of Management Working Paper 21 september 2017, p. 24-26. 24 Op deze site is uitgelegd hoe een ‘kill-function’ in de Solidity programmeer taal geprogrammeerd moet worden;
http://solidity.readthedocs.io/en/develop/frequently-asked-questions.html.
25 Van Eersel & Van den Bergh, Tijdschrift Financieel Recht in de Praktijk 2017/4, p. 42.
26 Hertig, Coindesk; Cong & He, SSRN 9 oktober 2017, p. 8; Zie voor onderscheid open en gesloten blockchain paragraaf 1.2.2.
27 Voor uitgebreide uitleg over de validatie en goedkeuring van transacties (mining) op de blockchain, verwijs ik naar de volgende bronnen:
R. Böhme, N. Christin, B. Edelman & T. Moore, 'Bitcoin: Economics, Technology, and Governance', Journal of Economic Perspectives Vol. 29, No. 2, p. 213-238. Beschikbaar via: http://pubs.aeaweb.org/doi/pdfplus/10.1257/jep.29.2.213 (laatst bezocht op: 4 januari 2018); Hertig, Coindesk; Cong & He, SSRN 9 oktober 2017, p. 8; Wright & De Filippi, SSRN 25 juli 2017, p. 6-8; Linneman, Computerrecht 2016/28, p. 321-322; Van Os, TBR 2017/140, p. 925-926; Catalini & Gans, Rotman School of Management Working Paper 21 september 2017, p. 24-26; Delmolino, Arnett, Kosba e.a. IACR Cryptology ePrint Archive 18 november 2015, p. 3; Pilkington 2015, p. 6-8; Bonneau, Miller, Clark e.a., IEEE 20 juli 2015, p. 3-5.
28 Linneman, Computerrecht 2016/28, p. 321; Van Os, TBR 2017/140.
29 Linneman, Computerrecht 2016/28, p. 322; Tjong Tjin Tai, NJB 2017/146, p. 177-178; Rikken, Van Heukelom-Verhage, Mul e.a. Dutch
Blokchain Group 17 november 2017, p. 12.
30 De meest bekende cryptovaluata is Bitcoin; Spaas & Van Roey Computerrecht 2015/84, p. 113-114.
met andere transacties verpakt tot een nieuw blok.32 Het blok krijgt een tijdsstempel en wordt vervolgens verzonden naar alle nodes. Daarmee is de transactie erkent en wordt de aanpassing doorgevoerd in alle kopieën van het grootboek.
Er bestaan verschillende blockchains. Elke blockchain maakt gebruik van het internet, maar het is niet mogelijk om via een website rechtstreeks toegang te krijgen tot een blockchain. Het meest bekende blockchain-platform om smart contracts uit te voeren is Ethereum.33 Ethereum kan het best worden vergeleken met een computer. Ethereum is een computer die niet fysiek gelokaliseerd is op één plek, maar verspreid is over de hele wereld. Het paradoxale is dat het maar één 'computer' is. Deze computer heeft geen reset- of uitknop en staat dus altijd aan. Iedereen heeft toegang tot de computer, net zoals iedereen toegang heeft tot internet. Eén persoon kan meerdere accounts hebben. Iedereen kan inloggen en er zijn zoveel gebruikersaccounts als nodig. Alles wat op én door de computer is uitgevoerd kan worden herhaald en bij elke herhaling zal de uitkomst hetzelfde zijn.
1.2.2 Open en gesloten blockchain
Een smart contract kan worden geplaatst op een open blockchain of op een gesloten blockchain. Het is voor iedereen mogelijk om een account te maken voor een open blockchain, de transacties te zien en om deel te nemen aan het netwerk.34 Een voorbeeld van een open blockchain is Ethereum. Bij een gesloten blockchain is dit anders. Het is duidelijk welke partijen de nodes beheren, het is duidelijk wie toegang heeft tot de blockchain en welke informatie te zien is binnen de blockchain.35 Op een open blockchain zijn er ook mogelijkheden om privacy van partijen te waarborgen, zoals het gebruiken van een nieuw adres bij elke transactie of gebruikmaken van anonieme cryptovaluta zoals Zcash.36 Daarnaast kan gevoelige informatie worden geplaatst op een gesloten blockchain in plaats van op een open blockchain. Deze informatie wordt gelinkt aan de open blockchain: de
hashfunctie wordt op de gesloten blockchain geplaatst en de uitkomst daarvan, de hashwaarde, wordt op de open blockchain geplaatst.37
32 Hertig, Coindesk; Van Eersel & Van den Bergh, Tijdschrift Financieel Recht in de Praktijk 2017/4, p. 42. 33 Ethereum is te downloaden via https://ethereum.org/; Luu, Chu, Olickel e.a., CSS 24 oktober 2016, p. 1-6. 34 Pilkington 2015, p. 10.
35 Pilkington 2015, p. 11.
36 De site met betrekking tot deze cryptovaluta is https://explorer.zcha.in/.
37 Catalini & Gans, Rotman School of Management Working Paper 21 september 2017, p. 27; Voor meer informatie over hashfunctie, en hashwaarde, zie paragraaf 1.2.1.
1.3 Smart contracts
De term 'smart contract' kent geen eenduidige definitie.38 Eén van de definities luidt als volgt: een smart contract bestaat uit een reeks afspraken of beloften opschreven in digitale vorm (‘codes’).39
In essentie is een smart contract een code die een ‘oorzaak en gevolg’-verband uitdrukt: als er sprake is van x, dan wordt de consequentie y geactiveerd. De activatie van y kan plaatsvinden door middel van nakomen of vervullen van een positieve of negatieve verplichting, voorwaarde, eis of afspraak. Smart contracts worden uitgevoerd op en door de blockchain.40
1.3.1 Voorbeeld smart contract41
In deze paragraaf wordt een voorbeeld van een smart contract gegeven om de werking en eventuele uitlegsituaties te verhelderen. Het is belangrijk om het kader te schetsen waarin dit voorbeeld wordt geplaatst. Er bestaan verschillende typen blockchains en daarnaast zijn er verschillende programmeertalen. De keuze voor programmeertaal is afhankelijk van het besturingssysteem (in dit geval: afhankelijk van de blockchain) waarin de code wordt geprogrammeerd. Daarnaast heeft elke programmeertaal verschillende eigenschappen. De keuze voor een programmeertaal kan dus ook afhangen van wat men wil bereiken met de code. In dit voorbeeld wordt gekozen voor de Ethereum blockchain en de daarbij behorende taal Serpent, omdat er een programma is ontwikkeld (EtherScripter) waarmee het coderen in Serpent taal kan worden gevisualiseerd. De cryptovaluta waar gebruik van wordt gemaakt op Ethereum heet 'Ether'.
Een boer is gespecialiseerd in het verbouwen van gewassen. De gewassen worden twee keer per jaar geoogst. Om er zeker van te zijn dat er twee keer per jaar een succesvolle oogst plaatsvindt, sluit de boer een 'goed-weer' verzekering af bij een Verzekeringsmaatschappij. De gewassen van de boer zijn namelijk niet bestand tegen veel regen. In een smart contract wordt opgenomen dat een verzekeringsmaatschappij een bedrag van 1000 Ether overmaakt naar het rekeningnummer van de boer 9872017, onder de voorwaarde dat de website van het KNMI bevestigt dat er cumulatief 12 mm regen of meer is gevallen tussen 08:00 uur op de voorafgaande dag en 08:00 uur op de huidige dag, met als begindatum 1 januari 2018 08:00
38 Szabo 1994; Schmaal en Van Genuchten, Tijdschrift voor Internetrecht 1/2017, p. 13; Segers, Tijdschrift voor Compliance 2/2017, p. 78;
Stark 2016; Savelyev, Higher School of Economics Research Paper 14 december 2016, p. 7.
39 Szabo 1994; Schmaal en Van Genuchten, IR 2017/1, p. 13; Segers, Tijdschrift voor Compliance 2017/2, p. 78. 40 Schmaal en Van Genuchten, IR 2017/1, p. 12.
41 Gebaseerd op een voorbeeld dat is gegeven tijdens een webinar van de Loan Market Association:
uur en als einddatum 1 januari 2019 08:00 uur in het dorp Loenen aan de Vecht in Nederland. Tevens zal de verzekering niet worden uitgekeerd als de boer niet heeft voldaan aan de maandelijkse premie.
Smart contracts kunnen alleen refereren aan de hand van de informatie die al op de blockchain vastligt. Dat beperkt de mogelijkheden van een smart contract. Voor dit probleem is een oplossing voor gevonden: er kan gebruik worden gemaakt van 'Oracles'.42 Deze orakelen slaan een brug tussen blockchain en de wereld buiten blockchain. Een orakel is een manier om een smart contract te voorzien van data of informatie die niet op de blockchain vastligt. Partijen kunnen een orakel (laten) programmeren in een smart contract. Een voorbeeld van een orakel is een data bron, bijvoorbeeld een URL naar een website. Een link naar de KNMI-site met deze informatie kan fungeren als orakel. Elke dag wordt er op de KNMI-site een bestand geüpload met de regenval per regio. Elke regio heeft een eigen station nummer. Loenen aan de Vecht heeft station nummer 548.
Figuur 2. Screenshot van een gedeelte van de KNMI-site waarop station nummers worden weergeven.43
Op de site van het KNMI staan bestanden waarin in per station nummer te vinden is hoeveel het op die dag heeft geregend. De aanhef van elk bestand is als volgt:
Figuur 3. Aanhef van bestand waar regenval per weerstation staat genoteerd.44
De eerste drie getallen in figuur 4 zijn het station nummer en vervolgens is de datum genoteerd (JJJJ/MM/DD). Daarna staat er hoeveel regen er op die dag is gevallen in tiende millimeters. Zo is er op 31 augustus 2017 in Loenen aan de Vecht 7,2 mm regen gevallen, zie
42 Op deze site is uitgelegd hoe een orakel geprogrammeerd kan worden: http://docs.oraclize.it/#home.
43 Het KNMI publiceert elke dag de dagwaarden van alle weerstations via https://www.knmi.nl/nederland-nu/klimatologie/monv/reeksen. 44 Het KNMI publiceert elke dag de dagwaarden van alle weerstations via https://www.knmi.nl/nederland-nu/klimatologie/monv/reeksen.
figuur 4.
Figuur 4. Voorbeeld van notatie van regenval op 31 augustus 2017 te Loenen aan de Vecht. 45
Het smart contract, opgesteld door middel van EtherScripter, is te zien in de bijlage 1. Bij deze manier van programmeren bestaat een smart contract bestaat uit init en body. De codes in init worden eenmalig gerund, bij het creëren van het smart contract. Daarna kunnen deze gegevens als 'vaststaande gegevens' worden beschouwd. In de body staan de codes die elke keer worden gerund, dus niet alleen bij het ontstaan van het contract. Bij init wordt het
Ethereum adres van de boer ingevoerd en het Ethereum adres van de
verzekeringsmaatschappij. Tevens wordt de begindatum (1 januari 2018) en de einddatum (1 januari 2019) ingevoerd. Daarnaast wordt de hoogte van de maandelijkse premie die de boer elke maand betaald ingevoerd. Zoals eerder vermeld worden er op de KNMI-site bestanden geüpload waarin te zien is hoeveel regen er op één dag (van 08:00 uur tot 08:00 uur) is gevallen en deze informatie wordt gekoppeld aan het smart contract.
Figuur 5. Inhoud smart contract m.b.t. 'goed-weer verzekering' in stappen
Als
er volgens de data in het bestand op de KNMI-site 12 mm of meer regen is gevallen EN de tijd van het blok, deze transactie dus, gelijk of groter is dan de startdatum (1 januari 2018) van het smart contract EN
de tijd van het blok gelijk of kleiner is dan de einddatum (1 januari 2019) van het smart contract
Dan
wordt er 1000 Ether vanaf het Ethereum adres van de verzekeringsmaatschappij overgemaakt naar het Ethereum adres van de boer
Mits
de boer alle voorafgaande maanden premie heeft betaald
Dit wordt als volgt berekend:
Het aantal maanden dat de boer al premie heeft betaald = ( de tijd van het blok - de startdatum van het smart contract ) / aantal seconden per maand
Het totale bedrag aan premie dat de boer tot nu toe heeft betaald = (tijd van het blok - de startdatum van het smart contract ) * premie die de boer per maand betaald
Het totale bedrag aan premie dat de boer sinds de start heeft betaald gedeeld door het aantal maanden dat de boer al premie heeft betaald moet gelijk zijn (of meer) dan de hoogte van de maandelijkse premie
En
als de tijdstempel van het blok groter is dan de einddatum, dus na 1 januari 2018, wordt het smart contract beëindigd.
1.4 Conclusie
In dit hoofdstuk is op hoofdlijnen de werking van de blockchain technologie uitgelegd. De reden daarvan is dat deze kennis van belang is om smart contracts, die zich van de blockchain technologie bedienen, in het vervolg van deze scriptie in een juridisch perspectief te kunnen zetten. Voorts is de term smart contract in dit hoofdstuk gedefinieerd, nu deze term geen definitie kent. Volgens de definitie die in deze scriptie wordt gehanteerd bestaat een smart contract uit een reeks afspraken of beloften opschreven in digitale vorm (‘codes’).
2.
S
MART CONTRACT:O
VEREENKOMST IN DE ZIN VANA
FDELING 6.5.1VAN HET
B
URGERLIJKW
ETBOEK?2.1 Inleiding
Om te bepalen of én op welke manier de huidige leer met betrekking tot het uitleggen van contractuele bepalingen kan worden toegepast op codetaal in smart contracts, moet eerst worden bepaald wat de juridische duiding van een smart contract is. In het vorige hoofdstuk is geschreven dat een smart contract bestaat uit een reeks afspraken of beloften opgeschreven in digitale vorm.46 Het is niet duidelijk of dit begrip een juridische lading kan hebben. Het gebruik van het woord contract in het begrip smart contract doet dit wel vermoeden. In dit hoofdstuk wordt verklaard waarom een smart contract een juridische lading kan hebben en wordt uitgelegd waarom een smart contract een overeenkomst in de zin van het Burgerlijk Wetboek is.
2.2 Meer dan alleen code
De fundamentele vraag in dit hoofdstuk is of een smart contract kan worden gekwalificeerd als een wettelijke overeenkomst. Om antwoord te vinden op deze vraag, moet eerst worden bepaald of een smart contract überhaupt binnen de rechtsorde kan vallen. Omdat er in de literatuur voor- en tegenstanders zijn met betrekking tot deze vraag, is het relevant om deze standpunten eerst beknopt uiteen te zetten voordat er wordt ingegaan op de vraag met betrekking tot de juridische kwalificatie van een smart contract.47 De tegenstanders zijn van mening dat een smart contract uit louter codetaal bestaat en dat de codetaal de afspraken in een smart contract uitdrukt en uitvoert.48 Dit uitgangspunt sluit aan bij gedachte code is law.49 Volgens de aanhangers van het code is law-principe wordt de fysieke wereld gereguleerd door het recht, maar wordt de cyberspacewereld daarentegen gereguleerd door 'code'.50 Dit zou betekenen dat smart contracts buiten de rechtsorde vallen en dat smart contracts geen overeenkomst in de zin van het Burgerlijk Wetboek kunnen zijn. Een argument voor dit uitgangspunt is dat de taal van de wiskunde een universele taal is.51 Smart contracts worden opgesteld in deze 'taal' en kunnen daarom worden gezien als transnationale contracten,
46 Szabo 1994; Schmaal en Van Genuchten, IR 2017/1, p. 13; Segers, Tijdschrift voor Compliance 2017/2, p. 78. 47 Stark, Coindesk 4 juni 2016; Clack, Bakshi & Braine, Cornell University Library 15 maart 2017, p. 2. 48 Stark, Coindesk 4 juni 2016; Clack, Bakshi & Braine, Cornell University Library 15 maart 2017, p. 2. 49 Lessig 2006, p. 5.
50 Lessig 2006, p. 5.
onafhankelijk van het nationaal recht. 52 Daarnaast maken partijen expliciet de keuze om hun afspraken uit te drukken en uit te voeren in een smart contract op de blockchain.53 Blockchain is op dit moment niet wettelijk gereguleerd en daarvan zijn partijen op de hoogte. Daarom kan worden betoogd dat een smart contract louter codetaal is die op de blockchain wordt uitgevoerd en waar dus geen recht op van toepassing is. Het volgende kan tegen de voorgaande argumenten worden ingebracht. Om te beginnen is het te kort door de bocht om uit de keuze van partijen voor een smart contract op de blockchain af te leiden dat er geen sprake kan zijn van een overeenkomst in de zin van het Burgerlijk Wetboek.54 Het feit dat blockchain op dit moment niet gereguleerd is, heeft niet automatisch tot gevolg dat het recht niet van toepassing is op toepassingen van blockchain, zoals smart contracts. Daarnaast reguleert het recht het gedrag van mensen. Een smart contract ontstaat door menselijk handelen en daarom kan worden gesteld dat het recht ‘gewoon’ van toepassing is op smart contracts, ongeacht in welke (programmeer)taal een smart contract is opgesteld. Een smart contract kan dus wel degelijk binnen de rechtsorde vallen.
2.3 Juridische betekenis smart contract
De vraag is of een smart contract kan voldoen aan de wettelijke vereisten die gelden voor een overeenkomst in de zin van afdeling 6.5.1 van het Burgerlijk Wetboek. Een 'klassieke' overeenkomst komt tot stand door middel van aanbod en aanvaarding.55 De vraag of een overeenkomst tot stand is gekomen wordt getoetst aan de aanwezigheid van wilsovereenstemming tussen de partijen.56 De wilsovereenstemming moet zich hebben geuit door middel van een op een rechtsgevolg gerichte wil die zich uit door een verklaring.57 Een rechtshandeling, ontstaan door samenwerking van twee of meer personen, geeft blijk van de wil van de persoon die handelt, welke is gericht op het ontstaan van een rechtsgevolg.58 Deze rechtshandeling kan ook tot stand komen doordat de persoon die handelt het vertrouwen heeft gewekt dat zijn wil was gericht op deze totstandkoming.59 De wil van partijen is dus nodig om overeenstemming te bereiken met betrekking tot de inhoud van een smart contract.60 Bij een smart contract wordt de wilsverklaring uitgedrukt in codes en algoritmes. Deze wilsverklaring via codes kan worden bestempeld als een (geprogrammeerde) wil van de
52 Savelyev, Higher School of Economics Research Paper 14 december 2016, p. 21.
53 Er zijn ook andere manieren van digitaal contracteren, zie: Werbach & Cornell, 67 Duke Law Journal 18 maart 2017, p. 7. 54 Savelyev, Higher School of Economics Research Paper 14 december 2016, p. 11.
55 Artikel 6:217 BW.
56 Asser/Hartkamp & Sieburgh 6-III* 2014, nr. 110; artikel 3:33 BW. 57 Artikel 3:33 BW.
58 Asser/Hartkamp & Sieburgh 6-III* 2014, nr 2 en 8. 59 Artikel 3:35 BW.
gebruiker(s) van het smart contract.61 Partijen kiezen expliciet voor implementatie en uitvoering van hun afspraken via een smart contract. Deze keuze kan worden beschouwd als extra ‘bewijs’ van de wilsovereenstemming tussen de partijen.62
Het gebruikmaken van een smart contract voor het uitvoeren van een overeenkomst vereist namelijk een extra stap ten opzichte van het sluiten van een gewone overeenkomst: de afspraken tussen partijen moeten worden geïmplementeerd worden in codetaal.
Voordat afspraken tussen partijen in een smart contract in codetaal worden uitgedrukt, moeten partijen onderling overeenstemming bereiken over de inhoud van hun afspraken, over wat ze door het smart contract willen laten uitvoeren en onder welke voorwaarden ze dat willen. Partijen maken in dit stadium de afspraken, bepalen welke afspraken of welke delen van afspraken ze in een smart contract willen laten uitdrukken en bepalen welke voorwaarden vervuld moeten zijn voordat de consequentie die is opgenomen in het smart contract intreedt. Deze ‘initiële’ afspraken zijn te beschouwen als een overeenkomst in de zin van afdeling 6.5.1 van het Burgerlijk Wetboek, ongeacht of deze overeenkomst op papier wordt gezet. De totstandkoming van deze overeenkomst is namelijk vormvrij.63 Een overeenkomst in de zin van afdeling 6.5.1 van het Burgerlijk Wetboek is een meerzijdige rechtshandeling, waarbij een of meer partijen jegens een of meer andere een verbintenis aangaan.64 Op deze ‘initiële’ overeenkomst is het 'traditionele' contractenrecht van toepassing.65 Partijen kunnen een mondelinge óf een schriftelijke overeenkomst (laten) uitdrukken in een smart contract. De vraag is wat de juridische verhouding is tussen deze ‘initiële’ overeenkomst en het smart contract. Partijen kunnen ervoor kiezen om de (mondelinge of schriftelijke) overeenkomst geheel of gedeeltelijk te implementeren in een smart contract. Het kan namelijk zo zijn dat niet alle clausules in codetaal kunnen worden uitgedrukt, denk bijvoorbeeld aan clausules over 'redelijke termijnen'. De taal van de code is (nog) geen gangbare taal in de juridische wereld. Dit betekent dat op dit moment een programmeur moeten worden ingeschakeld om de afspraken tussen partijen in codetaal uit te drukken. In de toekomst kunnen partijen wellicht zelf hun mondelinge of schriftelijke afspraken programmeren in een smart contract. Als de afspraken nog niet in codetaal zijn uitgedrukt, is er logischerwijs nog geen smart contract. Zoals eerder in deze paragraaf is uitgelegd, zijn deze afspraken wel te beschouwen als een overeenkomst in de zin van afdeling 6.5.1 van het Burgerlijk Wetboek. Pas als deze overeenkomst (gedeeltelijk) in codetaal is geprogrammeerd, ontstaat het smart
61 Voulon 2010, p. 54. 62 Voulon 2010 p. 56-57.
63 Artikel 3:37 BW jo. artikel 6:226 BW. 64 Artikel 6:213 BW.
contract.66 Omdat de overeenkomst die (gedeeltelijk) in het smart contract is uitgedrukt al wel bestond voordat het smart contract ontstond, kan een smart contract worden beschouwd als een onderdeel van de wettelijke overeenkomst in de zin van afdeling 6.5.1 van het Burgerlijk Wetboek. De afspraken die in een smart contract zijn uitgedrukt, zijn niet los te zien van de ‘initiële’ schriftelijke of mondelinge overeenkomst die partijen hebben gesloten. Er gaat namelijk altijd een mondelinge of schriftelijke overeenkomst aan het smart contract vooraf. Omdat de ‘initiële’ overeenkomst en het smart contract niet los van elkaar kunnen worden gezien, is een smart contract te beschouwen als een aanvulling op en/of een gedeeltelijke ‘vervanging’ van de ‘initiële’ overeenkomst. Stel dat partijen een uitgebreide en complexe schriftelijke overeenkomst zijn overeengekomen en slechts een aantal van in de overeenkomst opgenomen afspraken implementeren in een smart contract, dan vallen die afspraken in het smart contract dus ook onder de noemer 'wettelijke overeenkomst'. Het is aan partijen hoe zij in de schriftelijke overeenkomst opnemen dat bepaalde bepalingen in een smart contract worden uitgedrukt. Ze kunnen de bepalingen alsnog uitschrijven of noemen dat deze bepalingen wordt uitgedrukt in het smart contract.67
Figuur 6. Onderdelen van de ‘initiële’ overeenkomst tussen partijen worden geïmplementeerd in een smart contract
Een argument dat kan worden aangevoerd tegen het idee dat een smart contract onderdeel is van een overeenkomst, is dat smart contract alleen ziet op de (gedeeltelijke) uitvoering van een al bestaande schriftelijke of mondelinge overeenkomst en dat het smart contract op zichzelf daarom geen wettelijke overeenkomst is. Een smart contract hoeft echter niet alleen betrekking te hebben op de uitvoering van een overeenkomst, maar kan ook zien op de
66 Raskin, Geo. L. Tech. Rev 2017/305, p. 322.
67 Het is mogelijk dat in de toekomst een standaard template voor smart contracts wordt ontwikkeld. Dit template bestaat uit juridische tekst
én variabelen waaraan een bepaalde waarde wordt toegekend, zie Clack, Bakshi & Braine, Cornell University Library 15 maart 2017, p. 7-9.
afspraken en voorwaarden die betrekking hebben op de inhoud van de overeenkomst. Stel dat een smart contract alleen betrekking heeft op de uitvoering van een overeenkomst, dan kan een smart contract alsnog worden beschouwd als onderdeel van een wettelijke overeenkomst, nu dit smart contract en de daarin opgenomen afspraken over uitvoering onderdeel zijn van de afspraken die zijn gemaakt in de ‘initiële’ overeenkomst.
Er zijn juristen die stellen dat een smart contract een elektronische overeenkomst in de zin van artikel 6:227a BW is.68 Op welke manier precies aan de aanvullende vereisten zoals genoemd in artikel 6:227a BW en artikel 6:227b BW kan worden voldaan in geval van een smart contract wordt echter niet duidelijk gemaakt. Eén van de vereisten is dat de identiteit van partijen met voldoende zekerheid moet kunnen worden vastgesteld, iets wat lastiger is om vast te stellen in de cyberspacewereld dan in de fysieke wereld.69 Een voorbeeld van een elektronische overeenkomst is het online aanschaffen van een vliegticket. Een elektronische overeenkomst moet 'langs de elektronische weg gesloten' zijn en daar is sprake van als de gehele overeenkomst per draad, per radio of door middel van optische of andere elektromagnetische middelen wordt verzonden, doorgeleid en ontvangen met behulp van elektronische apparatuur voor de verwerking, met inbegrip van digitale compressie en opslag van gegevens.70 Een smart contract komt niet via de elektronische weg tot stand, maar door middel van het invoeren van codes door mensen.71 Een smart contract moet namelijk geprogrammeerd worden. Het is wel mogelijk dat er in de toekomst standaard templates worden ontwikkeld voor een bepaald type smart contract, bijvoorbeeld een uitbetaling, waarin nog slechts een of enkele gegevens nog moeten worden ingevuld.72 Het invullen van deze gegevens zal moeten gebeuren door menselijk handelen. Of er dan aan de vereisten van artikel 6:227a-b BW kan worden voldaan, zal de toekomst uitwijzen.
2.4 Conclusie
In dit hoofdstuk is ten eerste bepaald dat smart contracts vallen binnen de rechtsorde. Uit het feit dat blockchain en smart contracts niet wettelijke gereguleerd zijn, kan namelijk niet worden afgeleid dat het recht als zodanig helemaal niet van toepassing is of kan zijn op smart contracts. Daarnaast reguleert het recht menselijk handelen en ontstaat een smart contract door menselijk handelen. Ten tweede is in dit hoofdstuk beargumenteerd waarom een smart
68 Tjong Tjin Tai, NJB 2017/146, p. 7 ; Van Eersel & Van den Bergh, Tijdschrift Financieel Recht in de Praktijk 2017/4, p. 46-47; Rikken,
Van Heukelom-Verhage, Mul e.a. Dutch Blokchain Group 17 november 2017, p. 24-29.
69 Valk 2017, art. 6:227a BW lid 1 sub d, nr. 2 sub c
70 Valk 2017, art. 6:227a lid 1 BW, nr. 2 sub b; 3:15d BW tweede volzin. 71 Raskin, Geo. L. Tech. Rev 2017/305, p. 322.
contract een wettelijke overeenkomst in de zin van afdeling 6.5.1 van het Burgerlijk Wetboek is. De partijen hebben wilsovereenstemming bereikt met betrekking tot de inhoud van het smart contract en de codes drukken de wilsverklaring van partijen. Omdat de ‘initiële’ mondelinge of schriftelijke overeenkomst tussen partijen, welke (gedeeltelijk) in het smart contract is uitgedrukt, al bestond voordat het smart contract ontstond, kan een smart contract worden beschouwd als een onderdeel van de wettelijke overeenkomst in de zin van afdeling 6.5.1 van het Burgerlijk Wetboek. Het smart contract is niet los te zien van de ‘initiële’ schriftelijke of mondelinge overeenkomst die partijen sloten.
3.
U
ITLEG VANC
ODETAAL IN EENS
MARTC
ONTRACT 3.1 InleidingDe inhoud van een overeenkomst en de uitleg van de contractuele bepalingen van een overeenkomst komen meestal overeen met hetgeen partijen hebben bedoeld. Op het moment dat dit niet het geval is, behoeven de contractuele bepalingen nadere uitleg. Het uitleggen van contractuele bepalingen is in principe de taak van de partijen bij de overeenkomst.73 Onder het uitleggen van contractuele bepalingen wordt het vaststellen van de privaatrechtelijke rechtsgevolgen van een overeenkomst verstaan.74 Dit betekent dat wordt vastgesteld welke rechten en verplichtingen de partijen over en weer hebben. Indien de partijen onderling van mening blijven verschillen welke rechten en verplichtingen voor welke partijen uit de overeenkomst voortvloeien, kan de rechter worden geraadpleegd. In dat geval zal de rechter bepalen welke uitleg er moet worden verbonden aan de desbetreffende contractuele bepaling. Er is veel rechtspraak en literatuur over de norm waaraan de bepalingen in een overeenkomst moeten worden getoetst in het geval van een situatie die om uitleg vraagt. Indien in de toekomst wordt bepaald dat een smart contract valt binnen de huidige wetgeving en wordt bestempeld als een overeenkomst in de zin van afdeling 6.5.1 van het Burgerlijk Wetboek, dan geeft dit een nieuwe wending aan het huidige contractenrecht. De vraag hoe codetaal als onderdeel van een overeenkomst die wordt uitgevoerd op de blockchain geïnterpreteerd kan worden is tot op heden niet beantwoord. In dit hoofdstuk wordt beoordeeld of de bestaande normen met betrekking tot het uitleggen van contractuele bepalingen geschikt zijn voor toepassing op smart contracts.
3.2 Uitleg van codetaal
3.2.1 Uitlegsituaties
De vraag is wanneer er bij gebruik van een smart contract een situatie ontstaat die om uitleg van de rechter vraagt. Het programmeren van (een gedeelte van) een overeenkomst in een smart contract vereist kennis van programmeren, blockchain en smart contracts. De kwestie met betrekking tot het uitleggen van de codetaal ziet op situaties waarin een verschil is tussen de originele bedoeling zoals partijen die hadden bij de ‘initiële’ overeenkomst en de uitkomst van het smart contract dat (een gedeelte van) de ‘initiële’ overeenkomst zou moeten uitdrukken.
73 Bakker, ORP 2017/167, p. 20.
Waarschijnlijk schakelen zowel consumenten als bedrijven op dit moment een programmeur in met kennis van zaken om een overeenkomst te programmeren in een smart contract, nu zij zelf een smart contract niet kunnen programmeren.75 Deze programmeur programmeert deze overeenkomst of een gedeelte daarvan naar zijn interpretatie in een smart contract. De ingeschakelde programmeur zal waarschijnlijk instructies ontvangen van partij met betrekking tot het te programmeren smart contract. In deze scriptie wordt niet nader ingegaan op de vraagstukken met betrekking tot aansprakelijkheid van de programmeur bij fouten. Als de ‘initiële’ bedoelingen van partijen niet juist worden uitgedrukt in codetaal, kan dit leiden tot een verschil tussen de ‘initiële’ bedoeling van partijen en de implementatie van deze bedoeling in codetaal.76 Dit heeft tot gevolg dat de uitkomst van het smart contract niet overeenkomt met wat partijen hebben bedoeld. Het is mogelijk dat in de toekomst meer mensen opgeleid zijn om te programmeren en coderen, waardoor partijen geen programmeur meer hoeven in te schakelen. Een mogelijk toekomstbeeld is dus dat partijen afspraken maken en deze gemaakte afspraken direct implementeren in een smart contract.
Stel dat partijen in de toekomst zelf de vaardigheden hebben om een wettelijke overeenkomst om te zetten naar een smart contract, dan lijkt de kans klein dat de bedoeling van partijen onjuist wordt uitgedrukt in het smart contract. De kans is echter aanwezig dat de uitkomst van het smart contract alsnog niet strookt met wat partijen voor ogen hadden bij het sluiten van de ‘initiële’ overeenkomst. Het geprogrammeerde smart contract kan ‘bugs’ of ‘errors’ bevatten, ongeacht of de partijen zelf het smart contract in codetaal hebben uitgedrukt of dat zij een programmeur hebben ingeschakeld. Bugs en errors ontstaan doordat diegene die het smart contract programmeert bepaalde functies van de programmeertaal op de verkeerde manier gebruikt, een fout maakt tijdens het programmeren of de werking van de programmeertaal verkeerd interpreteert. Als dat gebeurt, is er sprake van een bug of een error in een smart contract. De uitkomst van het smart contract zal dan niet exact zo zijn als partijen hebben bedoeld. In het ‘klassieke’ contractenrecht wordt in het geval van ambiguïteit of een misverstand met betrekking tot een bepaling van een ‘klassieke’ overeenkomst gekeken naar wat partijen in die omstandigheden uit elkaars verklaringen en gedragingen mochten afleiden.77 Omdat een smart contract een nieuw soort contract is, uit codetaal bestaat en omdat elke codetaal verschillend is (zie bijlage 2, 3 en 4), is het de vraag of het leerstuk dat van toepassing is op het 'klassieke' contractenrecht ook kan worden toegepast op smart
75 Raskin, Geo. L. Tech. Rev 2017/305, p. 325.
76 Van Heukekom, Naves & Van Graafeiland, Pels Rijcken 28 september 2017, p. 6.
77 HR 13 maart 1981, ECLI:NL:HR:1981:AG4158, NJ 1981/635 (Ermes/Haviltex); HR 17 december 1976, ECLI:NL:HR:1976:AC5835, NJ
contracts.
Aan de hand van het voorbeeld van de verzekering voor gewassen (zie paragraaf 1.3.1
en bijlage 1 tot en met 4) worden drie voorbeelden gegeven van situaties die om uitleg vragen. Voorbeeld 1. Als het meerdere dagen achter elkaar 12 mm heeft geregend, zal het smart contract elke keer 1000 Ether betalen aan de boer. De verzekeringsmaatschappij kan het hier niet mee eens zijn, nu zij met dit smart contract heeft bedoeld om eenmalig 1000 Ether uit te keren. De schade kan immers slechts één keer worden geleden. Voorbeeld 2. Het heeft 11,99 mm geregend en de boer heeft schade aan zijn gewassen opgelopen. Het smart contract gaat tot betaling over als er minstens 12 mm regen is gevallen, dat is nu niet het geval. De boer gaat ervan uit dat de verzekeringsmaatschappij uitbetaald, omdat 11,99 mm afgerond 12 mm is. Voorbeeld 3. De programmeur van het smart contract kiest voor één van de programmeertalen voor het programmeren van de verzekering in een smart contract. Tijdens het programmeren van het smart contract maakt de programmeur een typefout bij het invoeren van het Ethereum-adres van de boer, waardoor er een niet-bestaand Ethereum-adres wordt ingevoerd. De verzekering zal dus nooit worden uitgekeerd aan de boer, ongeacht of het 12 mm heeft geregend of niet.
De voorbeelden laten zien dat er situaties kunnen zijn waar de inhoud van het smart contract nadere uitleg door de rechter behoeft. De vraag is waarom uitleg met betrekking tot de inhoud van een smart contract niet kan plaatsvinden aan de hand van de ‘initiële’ overeenkomst die partijen hebben gesloten. Als partijen de ‘initiële’ overeenkomst niet schriftelijk vastleggen, is het onmogelijk om de precieze inhoud van deze overeenkomst te toetsen. Stel dat de ‘initiële’ overeenkomst schriftelijk is vastgelegd, dan is het wel mogelijk om de inhoud van het smart contract te beoordelen op basis van de ‘initiële’ schriftelijke overeenkomst die partijen zijn overeengekomen. Echter, omdat contracteren via de blockchain technologie een totaal nieuwe manier is van contracteren, vraagt dit ook om een nieuwe risicoverdeling. Een ‘klassieke’ overeenkomst verschilt essentieel van een smart contract op de blockchain: de manier van het opstellen van een smart contract, het uitvoeren van een smart contract en het handhaven van een smart contract is totaal verschillend. Als partijen kiezen voor het gebruik van een smart contract via de blockchain technologie, maken zij gebruik van een niet-gereguleerde technologie. Partijen maken bewust de keuze om (een gedeelte van) de ‘initiële’ overeenkomst te implementeren in een smart contract op de blockchain, een technologie die op dit moment niet wettelijk is gereguleerd. Ze nemen hiermee dus een risico: wat de (juridische) consequentie is van een onjuiste implementatie van de ‘initiële’ partijbedoeling in een smart contract of van een bug of een error in een
smart contract is onbepaald. Aangevoerd kan worden dat partijen bij de keuze van een smart contract daarom een andere risicoverdeling aanvaarden, waardoor de tekst van de ‘initiële’ overeenkomst een rol kan spelen bij de uitleg van wat in het smart contract is opgenomen, maar niet leidend zal zijn. Er kan zelfs een stap verder worden gegaan en worden beargumenteerd dat op het moment dat de ‘initiële’ overeenkomst is uitgedrukt in codetaal, vanaf dat moment de ‘initiële’ overeenkomst niet meer leidend kan zijn.
3.2.2 Tijdens een procedure
Als partijen naar de rechter gaan voor uitleg van een smart contract, dan is de vraag wát de rechter gaat interpreteren. Een rechter is niet geschoold of opgeleid om codetaal te 'lezen' en om te oordelen over smart contracts op de blockchain. In bijlage 2, 3 en 4 zijn de voorbeelden zoals beschreven in paragraaf 1.3.1 in drie verschillende programmeertalen uitgewerkt, te weten Serpent, LLL en XML, om zo te laten zien wat de rechter zou moeten ‘lezen’ bij de uitleg van een smart contract.78 De rechter zal bij uitleg van de codetaal in een smart contract, waarschijnlijk om te beginnen kennis willen nemen van de ‘initiële’ overeenkomst. Daarnaast zijn er verschillende manieren waarop de rechter toch kennis kan nemen van de betekenis van de code. Ten eerste heeft de rechter de mogelijkheid om een deskundige een rapport te laten opmaken en deze deskundige aanwezig te laten zijn tijdens de zitting.79 Bewijs kan namelijk op grond van artikel 152 Rv. worden geleverd door alle middelen, tenzij de wet iets anders voorschrijft. Een deskundige zou de verschillende onderdelen van een smart contract kunnen herkennen. Deze deskundige kan de rechter meer informatie geven over de manier van programmeren van het smart contract, de eigenschappen van de gekozen codetaal, de inhoud van het desbetreffende smart contract en de eventuele bugs en errors die in het smart contract zitten. Daarnaast zou het mogelijk kunnen zijn dat bepaalde 'vaste' codes in een smart contract een 'vaste' betekenis krijgen en dat voor die codes geldt dat het redelijk is om ze op één bepaalde manier uit te leggen. Het raadplegen van een deskundige brengt wel kosten met zich mee.80
Ten tweede kan een smart contract worden opgesteld aan de hand van EtherScripter, zie bijlage 1. Dit geeft de rechter de mogelijkheid om de codetaal meer in context te lezen. Er moet echter wel een kanttekening bij deze oplossing worden geplaatst: EtherScripter is alleen geschikt voor één specifieke programmeertaal die slechts gebruikt wordt op één soort
78 Voor een voorbeeld van een andere programmeertaal, verwijs ik naar de website http://solidity.readthedocs.io/en/develop/index.html waar
de programmeertaal Solidity wordt uitgelegd.
79 Art. 194 Rv. 80 Art. 195 Rv.
blockchain, namelijk Ethereum. Idealiter wordt er voor andere blockchains en programmeertalen ook een manier gevonden om de codetaal te 'visualiseren'. Er bestaat een kans dat de rechter bij gebruik van EtherScripter alsnog een deskundige zal inschakelen, omdat het programma een smart contract alleen visualiseert maar verder niet uitlegt wat de betekenis en consequenties van de verschillende onderdelen zijn.
Ten derde bestaat er binnen de blockchain technologie de mogelijkheid tot dual
integration. Bij dual integration wordt het smart contract gelinkt aan de ‘initiële’
overeenkomst door middel van de hashwaardes en algoritmes.81 Dit is alleen mogelijk wanneer de ‘initiële’ overeenkomst schriftelijk is vastgelegd. De overeenkomst kan dan door derden en dus door de rechter worden geraadpleegd. Dual integration is echter geen optimale oplossing: de opbouw van een overeenkomst kan verschillen van de opbouw van een smart contract. Dit zal verschillen per gekozen programmeertaal. Daarnaast hangt het van de gekozen programmeertaal af hoe ‘makkelijk’ de verschillende onderdelen in het smart contract te onderscheiden zijn, zie bijlage 2, 3 en 4. Voorts kan het zo zijn dat de codes in het smart contract niet exact dezelfde betekenis of gevolgen hebben als de juridische begrippen in de overeenkomst. Dual integration is niet meer dan het linken van het smart contract aan de ‘initiële’ overeenkomst. De rechter zal dan nog steeds geen duidelijkheid hebben over de manier van programmeren van het smart contract, de eigenschappen van de gekozen codetaal, de exacte inhoud van het desbetreffende smart contract en de eventuele bugs en errors die in het smart contract zitten. Daarom zal de rechter zich alsnog moeten laten informeren over voorafgaande punten.
Een vierde mogelijkheid is om de programmeur van het smart contract een verslag te laten schrijven tijdens het implementeren van de overeenkomst in de codetaal en het programmeren van het smart contract. Zo zijn de stappen die de programmeur heeft gemaakt makkelijker te achterhalen. De programmeur zou in het verslag ook aandacht kunnen besteden aan het uitleggen van de consequenties van bepaalde keuzes die zijn gemaakt tijdens het programmeren. Het laten schrijven van een verslag door de programmeur is echter niet de ultieme oplossing: de kans is klein dat het verslag zo alomvattend is dat de rechter geen enkele vraag meer heeft over de manier van programmeren, de werking van smart contracts en blockchain en de eventuele verschillen tussen de betekenis van de codetaal en bewoordingen in de ‘initiële’ schriftelijke overeenkomst. Daarbij is een verslag laten opmaken een kostenverhogend proces.
81 Op de volgende site wordt uitgelegd hoe dual integration moet worden geprogrammeerd in een smart contract:
https://monax.io/explainers/dual_integration/; Schmaal en Van Genuchten, Tijdschrift voor Internetrecht 1/2017, p. 13; Christidis & Devetsikiotis 2016, IEEE Access volume 4, p. 2300.
Een ideaal toekomstbeeld zou zijn dat rechters (en wellicht ook advocaten) kennis wordt bijgebracht van de blockchain technologie en dat zij worden opgeleid om codetaal en smart contracts te kunnen programmeren en lezen. Dit is een kostbaar proces, maar zorgt er wel voor dat er op den duur geen deskundige meer hoeft te worden ingeschakeld door de rechter en dat partijen geen gebruik hoeven te maken van EtherScripter of dual integration. Een verslag laten opmaken door de programmeur kan geen kwaad maar of het in elke situatie noodzakelijk is, is de vraag.
3.3 Rechtspraak
3.3.1 Haviltex-norm
De Hoge Raad heeft bepaald dat bij de uitleg van contractuele bepalingen van een mondelinge of schriftelijke overeenkomst, wilsverklaring of mededeling die de contractspartijen aan elkaar hebben gedaan aansluiting moet worden gezocht bij de zin die de partijen in de gegeven omstandigheden over en weer redelijkerwijs van elkaar mochten verwachten.82 Daarnaast moet rekening worden gehouden met alle omstandigheden van het concrete geval en de eisen van redelijkheid en billijkheid.83 De maatstaf uit dit arrest wordt 'de Haviltex-norm' genoemd. De vraag is of de Haviltex-norm kan worden toegepast op smart contracts. De maatstaf lijkt in eerste instantie geschikt te zijn voor toepassing op smart contracts. Dit kan worden aangetoond aan de hand van de voorbeelden zoals geschetst in paragraaf 3.2.1. Stel dat bij voorbeeld 1 de Haviltex-norm wordt toegepast, dan kan de conclusie zijn dat de uitkomst van dit smart contract het doel van de verzekering voorbij gaat. Bij de uitleg van een smart contract zou bij toepassing van de Haviltex-norm aansluiting moeten worden gezocht bij hetgeen de partijen in de gegeven omstandigheden over en weer redelijkerwijs van elkaar mochten verwachten. Deze verzekering vergoedt schade aan gewassen. Als de gewassen na één regenbui van meer dan 12 mm zijn verwoest en deze schade is vergoed door middel van de overboeking van 1000 Ether, dan kan worden beargumenteerd dat partijen in de gegeven omstandigheden redelijkerwijs van elkaar mochten verwachten dat de schade niet nogmaals zou worden vergoed, nu de gewassen niet meer kunnen worden geoogst. Ook bij voorbeeld 2 kan de Haviltex-norm mogelijk worden toegepast: stel dat er in eerdere correspondentie is gesproken over de voorwaarden van de uitkering, dus over het bereiken van 12 mm of over de afronding van 12 mm, dan kan dit meespelen bij de beoordeling van de uitleg van het smart contract. Bij voorbeeld 3 is er
82 HR 13 maart 1981, ECLI:NL:HR:1981:AG4158, NJ 1981/63 (Ermes/Haviltex); Verdam, Contracteren 2010/3, p. 116-117. 83 Artikel 6:248 BW.
sprake van een error in het smart contract. Door een typefout die is gemaakt door de programmeur van het smart contract wordt het bedrag niet overgemaakt op het moment dat het 12 mm heeft geregend. Ook hierbij zou bij de toepassing van de Haviltex-norm aansluiting moeten worden gezocht bij hetgeen de partijen in de gegeven omstandigheden over en weer redelijkerwijs van elkaar mochten verwachten. Dat lijkt in dit geval mogelijk, nu een verzekering een overeenkomst is tussen een verzekerde en een verzekeraar en zij in dit geval hebben afgesproken dat er bij schade een vergoeding wordt betaald aan de boer. Op het moment dat de ingeschakelde programmeur instructies heeft ontvangen over het op te stellen smart contract, dan kan (onder andere) hieruit de partijbedoeling worden opgemaakt.84 Tot nu toe lijkt de toepassing van Haviltex-norm dus mogelijk op codetaal in smart contracts. Er zijn echter enkele obstakels. In het Haviltex arrest wordt gesproken over de uitleg van bepalingen van een contract.85 Een smart contract bestaat niet uit bepalingen, maar uit codes. De opbouw en de volgorde van de codes verschilt per programmeertaal, zie bijlage 2, 3 en 4. Het is niet duidelijk of onder bepalingen ook codes kunnen worden verstaan. Daarnaast kan worden aangevoerd dat de keuze voor een smart contract op de blockchain een nieuwe manier van contracteren is waarbij een andere weging van factoren hoort, op het moment dat (een onderdeel van) een smart contract moet worden uitgelegd. Hier wordt in hoofdstuk 4 nader op in gegaan.
3.3.2 Cao-norm
De volgende vraag is of de ‘cao-norm’ die de Hoge Raad in 1994 heeft gewezen geschikt is voor toepassing op smart contracts.86 De cao-norm kent een doorslaggevende betekenis toe aan de talige betekenis van de bewoordingen van een bepaling van een cao of een sociaal plan, gelezen in het licht van de gehele tekst in de cao of het sociaal plan.87 De uitleg van bewoordingen van een cao verschillen van de uitleg van een gewone overeenkomst, nu een cao geen andere interpretatiebron heeft dan haar bewoordingen. De cao-norm geldt voor overeenkomsten en regelingen die op eenduidige manier de positie van partijen beïnvloeden en regelen, welke niet bij het opstellen van de cao betrokken zijn.88 In het DSM/Fox arrest heeft de Hoge Raad gesteld dat tussen de Haviltex-norm en de cao-norm geen tegenstelling
84 Het vraagstuk omtrent de aansprakelijkheid van de programmeur komt in deze scriptie niet aan bod. 85 HR 13 maart 1981, ECLI:NL:HR:1981:AG4158, NJ 1981/635 (Ermes/Haviltex).
86 HR 17 september 1993, ECLI:NL:HR:1993:ZC1072, NJ 1994/173.
87 HR 17 september 1993, ECLI:NL:HR:1993:ZC1072, NJ 1994/173; HR 26 mei 2000, ECLI:NL:HR:2000:AA5961, NJ 2000/473. 88 HR 20 februari 2004, ECLI:NL:HR:2004:AO1427, NJ 2005/493, m.nt. C.E. du Perron (DSM/Fox); HR 17 september 1993,
bestaat, maar een vloeiende overgang.89 Beide normen kunnen dus worden gezien als verschillende uitgangspunten. Het hangt af van het type overeenkomst en de omstandigheden van het geval of er meer zwaarte ligt op de tekstuele uitleg of op de partijbedoelingen.90 De vraag is of de cao-norm als zodanig geschikt is voor toepassing op smart contracts. Om te beginnen moet worden vastgesteld of een smart contract als een regeling te beschouwen is die de positie van partijen beïnvloedt én regelt, terwijl deze partijen niet bij het opstellen van de regeling betrokken zijn. Een smart contract zal op dit moment niet worden geprogrammeerd door de betrokken partijen, maar de inhoud daarvan wordt wél bepaald door partijen.91 Daarom kan aangevoerd worden dat de cao-norm van toepassing zou kunnen zijn op de uitleg van smart contracts. Daarnaast was in het cao-arrest sprake van een situatie waarin partijen op wie de cao van toepassing was bij het bepalen van de inhoud en strekking van die cao geen andere gegevens voorhanden hadden dan de tekst van de cao.92 Echter, als partijen kiezen om (een gedeelte van) een overeenkomst door een programmeur te laten uitdrukken in een smart contract, hebben partijen wél andere gegevens tot hun beschikking bij het bepalen van inhoud en strekking, namelijk de ‘initiële’ overeenkomst. Dit geldt alleen als de overeenkomst schriftelijk is. Beargumenteerd kan worden dat de cao-norm niet volledig geschikt is voor toepassing op smart contracts, nu partijen bij het bepalen van inhoud en strekking gebruik kunnen maken van meer 'gegevens' dan alleen het smart contract. Daarbij moet wel in gedachte gehouden worden dat, zoals in 3.2.1 Uitlegsituaties is aangevoerd, vanwege het speciale karakter van smart contracts de tekst van de ‘initiële’ overeenkomst slechts een ondergeschikte rol kan spelen. Ook heeft de cao-norm, net zoals de Haviltex-norm, betrekking op de bewoordingen.93 Bij een smart contract kan niet worden gekeken naar de bewoordingen van de bepaling nu een smart contract bestaat uit codes en dus geen woorden en bepalingen kent. Het is onzeker of onder bepalingen ook codes kunnen worden verstaan. In bijlage 2, 3 en 4 is tevens te zien dat de opbouw en volgorde van de codes verschilt per programmeertaal. Tot slot kan, net als bij de Haviltex-norm, het argument worden aangevoerd dat contracteren via de blockchain technologie een nieuwe manier is van contracteren en dat daarom bij uitleg van een onderdeel van een smart contract een andere weging van factoren past. Hier wordt nader op ingegaan in hoofdstuk 4.
89 HR 20 februari 2004, ECLI:NL:HR:2004:AO1427, NJ 2005/493, m.nt. C.E. du Perron (DSM /Fox), r.o. 4.4.; Deze doctrine is bevestigt in
HR 29 juni 2007, ECLI:NL:HR:2007:BA4909, NJ 2007/576 (Derksen/Homburg).
90 HR 20 februari 2004, ECLI:NL:HR:2004:AO1427, NJ 2005/493, m.nt. C.E. du Perron (DSM /Fox); HR 5 maart 2004,
ECLI:NL:HR:2004:AO1974, NJ 2005/494; HR 12 november 2004, ECLI:NL:HR:2004:AP9666, NJ 2005/500, m.nt. C.E. du Perron.
91 Het opstellen van een smart contract is het uitdrukken van de mondelinge of schriftelijke overeenkomst in codetaal. 92 HR 17 september 1993, ECLI:NL:HR:1993:ZC1072, NJ 1994/173, r.o. 3.3.
