Geactualiseerd op 28 september 2026.
Een leverancier krijgt automatisch betaald zodra een sensor registreert dat goederen zijn afgeleverd. Een verzekeringsuitkering volgt zodra een databron een afgesproken gebeurtenis bevestigt. Zulke toepassingen van smart contracts kunnen transacties versnellen. Maar wat gebeurt er wanneer de sensor verkeerd meet, de software een fout bevat of de betaling plaatsvindt terwijl de levering ondeugdelijk is?
Voor een ondernemer is de belangrijkste vraag niet alleen of de code werkt. Beslissend is wie juridisch verantwoordelijk is voor de uitkomst en hoe u kunt ingrijpen wanneer de uitvoering afwijkt van de afspraak. Een smart contract vraagt daarom om een zorgvuldig contract én een controleerbaar uitvoeringsproces.
Een smart contract is niet vanzelf een overeenkomst
Een smart contract is software die vooraf geprogrammeerde handelingen uitvoert zodra bepaalde voorwaarden zijn vervuld. Vaak draait die software op een blockchain, maar geautomatiseerde contractuitvoering is ook zonder blockchain mogelijk. Het programma kan bijvoorbeeld een betaling vrijgeven of toegang tot gegevens verlenen.
Dat technische mechanisme moet worden onderscheiden van de juridische overeenkomst. Naar Nederlands recht blijven onder meer aanbod en aanvaarding, wil en verklaring en vertegenwoordigingsbevoegdheid van belang. De basisregels staan in artikel 6:217 BW en artikel 3:33 BW. Een uitgevoerde transactie bewijst niet zonder meer dat iemand bevoegd was namens uw onderneming te handelen.
Wat gaat voor: de tekst of de code?
Leg vast welke documenten de overeenkomst vormen en welke rangorde geldt bij tegenstrijdigheden. Wanneer een Nederlands contract een betaling koppelt aan aanvaarding van de prestatie, maar de code alleen aflevering controleert, bestaat een wezenlijk verschil. Een pakket kan zijn bezorgd zonder dat de geleverde machine de overeengekomen capaciteit haalt.
In Lundiform/Mexx bevestigde de Hoge Raad dat ook bij commerciële contracten de omstandigheden rond de afspraken van belang kunnen zijn voor de uitleg. Dit was geen zaak over smart contracts, maar het interpretatievraagstuk is ook hier relevant. Programmeercode neemt de juridische beoordeling niet over. Lees hierover ook onze uitleg van de entire agreement-clausule.
De zwakke plek zit vaak in de aangeleverde gegevens
Veel toepassingen zijn afhankelijk van informatie van buiten het programma: meetgegevens, een koers, een leveringsbevestiging of een verklaring van een derde. Een dergelijke gegevensbron wordt vaak een oracle genoemd. De software kan technisch precies doen wat is geprogrammeerd en toch een onjuiste uitkomst produceren doordat de invoer niet klopt.
Regel daarom wie de bron kiest, wie haar betrouwbaarheid controleert en welke procedure geldt bij uitval of tegenstrijdige gegevens. Spreek af of één foutsignaal voldoende is om een betaling op te schorten, wanneer een tweede controle nodig is en wie de kosten daarvan draagt. Bewaar de oorspronkelijke gegevens en de gebruikte programmaversie. Zonder die informatie is achteraf moeilijk vast te stellen waar het misging.
Automatische uitvoering laat juridische remedies bestaan
Een automatisch uitgevoerde betaling is niet per definitie definitief verschuldigd. Afhankelijk van de omstandigheden kunnen nakoming, terugbetaling, schadevergoeding, ontbinding of vernietiging aan de orde zijn. Welke route past, hangt onder meer af van de overeenkomst, de tekortkoming, eventuele toerekenbaarheid en de vereisten voor verzuim.
Technische onomkeerbaarheid kan wel betekenen dat herstel een nieuwe transactie of medewerking van een andere partij vergt. Een recht op terugbetaling helpt bovendien weinig als de ontvanger onvindbaar of insolvent is. Denk daarom vooraf na over zekerheden, betalingslimieten en een betwistingsprocedure. Voor de vraag wanneer u eerst een hersteltermijn moet geven, verwijzen wij naar onze blog over de ingebrekestelling aan een leverancier.
Zorg dat iemand verantwoord kan ingrijpen
Bij bedrijfskritische toepassingen verdient een voorziening voor pauzeren, beëindigen of corrigeren serieuze aandacht. Bepaal wie deze bevoegdheid heeft en onder welke voorwaarden. Volledige afhankelijkheid van één ontwikkelaar of één verloren toegangssleutel maakt uw onderneming kwetsbaar. Een ingreep mag tegelijkertijd niet ongemerkt nieuwe risico’s of eenzijdige wijzigingen introduceren.
Werk met duidelijke bevoegdheden, vastlegging van wijzigingen en een escalatieprocedure. Test ook uitzonderingssituaties: een dubbele levering, een fout bedrag, een betwiste prestatie en uitval van een externe dienst. Onze blog over continuïteit bij een SaaS-leverancier behandelt vergelijkbare vragen over herstel, toegang en afhankelijkheid.
De Data Act stelt specifieke eisen aan bepaalde toepassingen
Artikel 36 van de Data Act bevat essentiële eisen voor smart contracts die worden gebruikt voor de uitvoering van overeenkomsten over het beschikbaar stellen van gegevens. Het betreft dus geen algemene regeling voor ieder blockchaincontract. Onder meer robuustheid, toegangscontrole, veilige beëindiging of onderbreking en bewaring van relevante gegevens spelen een rol.
Het voorstel voor de Digital Omnibus voorziet in wijzigingen van dit stelsel. Volgens het Europese wetgevingsdossier is die procedure op de actualisatiedatum nog niet afgerond. Een aangekondigde vereenvoudiging is daarom geen reden om geldende verplichtingen alvast buiten toepassing te laten.
Verdeel aansprakelijkheid over de betrokken partijen
Bij één toepassing kunnen een softwareontwikkelaar, platformbeheerder, gegevensleverancier en commerciële wederpartij betrokken zijn. Hun contracten moeten op elkaar aansluiten. Anders belooft uw onderneming beschikbaarheid aan klanten terwijl uw eigen leverancier vrijwel iedere verantwoordelijkheid uitsluit.
Onderzoek aansprakelijkheidslimieten, herstelverplichtingen, garanties over bevoegdheden en gebruiksrechten en de dekking van schade door foutieve transacties. Laat beoordelen of een beveiligingsaudit ook juridische risico’s afdekt: technische controle zegt niet automatisch iets over een geldig contract of een werkbare schadeclaim. Maak tevens afspraken over wijzigingen en beëindiging van de samenwerking.
Privacy en internationale geschillen vragen afzonderlijke keuzes
Gegevens op een blockchain zijn niet vanzelf anoniem. Als personen identificeerbaar zijn, kan de AVG van toepassing zijn. Het blijvend vastleggen van persoonsgegevens kan botsen met bewaartermijnen of correctie- en verwijderingsverzoeken. Onderzoek welke informatie werkelijk op de blockchain moet staan en welke beter daarbuiten kan worden bewaard.
Leg ook toepasselijk recht en geschillenbeslechting vast. De plaats van een server of blockchainnode geeft niet vanzelf een bruikbare oplossing. Een passende forumkeuzeclausule maakt duidelijk waar u terechtkunt als ingrijpen nodig is.
Van werkende code naar een houdbare afspraak
Breng vóór ingebruikname de juridische afspraak, gegevensstromen, bevoegdheden en herstelmogelijkheden samen in één beoordeling. De beste contractuele bescherming ontstaat wanneer juristen en technische specialisten dezelfde uitzonderingssituaties doorlopen. Wilt u een smart contract inzetten of is discussie ontstaan over een automatische transactie? Sascha Lang denkt met u mee over de overeenkomst, de risicoverdeling en een uitvoerbare oplossing bij een geschil.
