Smart-Contract-Zertifizierung: was Sie verlangen und prüfen können

Die Anfrage kommt schriftlich und in einer Zeile. Ein Vertriebspartner, der einen Token platzieren will, ein Fonds, der eine Investition in ein Protokoll prüft, oder eine Handelsplattform, die die Zulassung eines Vermögenswerts erwägt, verlangen „das Zertifikat der Smart Contracts“, bevor sie weitermachen. Wer die Anfrage erhält, muss entscheiden, was er liefert, und wer eine Prüfung beauftragt, was er verlangen muss, um es später liefern zu können. DieSmart Contractsverwahren und bewegen Werte gemäß ihrem Code, und wer das Zertifikat verlangt, will einen Nachweis, dass dieser Code tut, was er vorgibt, und dass niemand ihn unkontrolliert ändern kann.

Das Wort verspricht mehr, als es tatsächlich gibt. Es gibt keine öffentliche Stelle, die bescheinigt, dass ein Smart Contract sicher ist, und keine amtliche Akkreditierung von Auditoren; was unter diesem Namen kursiert, sind Prüfberichte privater Unternehmen, manchmal ergänzt um ein Siegel. Ihr Wert hängt davon ab, dass sie an eine exakte Version des Codes gebunden sind und jeder überprüfen kann, dass genau diese Version bereitgestellt ist. In der Europäischen Union besteht nur in einem konkreten Fall eine gesetzliche Konformitätspflicht: bei Verträgen, die Vereinbarungen über den Datenaustausch ausführen. Was ein Audit prüft und wie wir es durchführen, beschreibt die SeiteSmart-Contract-Audits; dieser Artikel behandelt, was das Dokument bedeutet und wie es sich überprüfen lässt.

Was hinter dem Wort Zertifizierung steckt

DieAuditist die übliche Prüfung: Ein unabhängiges Team analysiert den Code einer bestimmten Version, dokumentiert die gefundenen Schwachstellen mit ihrem Schweregrad und prüft anschließend die Korrekturen. Geliefert wird ein Bericht, und ihn Zertifikat zu nennen, verleiht ihm keinen rechtlichen Wert. Einen Versuch, dem Wort mit veröffentlichten Kriterien Inhalt zu geben, stellt die SpezifikationEthTrust Security Levelsder Enterprise Ethereum Alliance dar, deren Version 3 im März 2025 veröffentlicht wurde. Sie definiert drei Anforderungsstufen für Verträge in Solidity: [S], ausgelegt auf die Prüfung mit automatisierter statischer Analyse; [M], die eine strengere Analyse und menschliches Urteilsvermögen erfordert; und [Q], die zusätzlich Geschäftslogik und Dokumentation prüft, also ob der Code tut, was er vorgibt.

Auch ihre Grenzen hält EthTrust schriftlich fest. Version 3 schränkt nicht ein, wer die Zertifizierung ausstellen darf, und definiert kein Verfahren zur Akkreditierung der Auditoren oder Tools, die sie vergeben. Zudem verlangt sie, dass jede Zertifizierungserklärung darauf hinweist, dass sie keine Fehlerfreiheit des Codes garantiert. Zertifiziert wird der geprüfte Code, also der Quellcode und der mit bestimmten Parametern kompilierte Bytecode, für die angegebenen Versionen der Ethereum Virtual Machine. Es ist ein nützlicher Rahmen, um eine Prüfung nach veröffentlichten Kriterien zu verlangen, kein amtliches Siegel.

Der einzige Fall mit gesetzlicher Pflicht in der EU: Verträge, die Datenvereinbarungen ausführen

DerDie Datenverordnung (Data Act), seit dem 12. September 2025 anwendbar, ist die europäische Norm, die Smart Contracts als solchen Anforderungen auferlegt. Ihr Artikel 36 verpflichtet den Anbieter einer Anwendung, die Smart Contracts zur Ausführung von Vereinbarungen über die Bereitstellung von Daten nutzt, oder denjenigen, der sie in diesem Zusammenhang für andere einsetzt, ihre Robustheit und Zugangskontrolle, ihre sichere Beendigung und Unterbrechung, die Archivierung und Kontinuität der Daten sowie die Übereinstimmung mit der ausgeführten Vereinbarung zu gewährleisten. Dazu muss er eine Konformitätsbewertung durchführen und eine EU-Konformitätserklärung ausstellen, mit der er die Verantwortung für die Einhaltung übernimmt.

Der Anwendungsbereich ist eng. Ein Anleihe-Token, ein Fonds im DeFi-Bereich oder ein Vertrag für den Weiterverkauf von Eintrittskarten führen keine Vereinbarung über den Datenaustausch im Sinne der Verordnung aus. Die Erklärung gilt für sie daher nicht und kann nicht als allgemeines Sicherheitszertifikat ausgegeben werden. Zudem hat die Kommission im November 2025 vorgeschlagen, Artikel 36 im Rahmen des PaketsDigital Omnibuszu streichen, mit der Begründung, seine Abschaffung würde neue Geschäftsmodelle begünstigen; solange dieser Vorschlag nicht angenommen ist, bleibt der Artikel in Kraft.

Ein Bericht gilt für eine Version des Codes

Ein Prüfbericht beschreibt einen Stand des Codes, der durch einen Commit im Repository identifiziert wird, also die eindeutige Referenz, die genau festlegt, welche Dateien geprüft wurden. Wird danach eine Zeile geändert, bezieht sich der Bericht nicht mehr auf diesen Code. Deshalb wird als Erstes geprüft, ob der im Bericht genannte Commit mit dem kompilierten und bereitgestellten übereinstimmt, eine Prüfung, für die man kein Solidity lesen muss.

Diese Prüfung kann dank der öffentlichen Code-Verifizierung jeder vornehmen. Dienste wie Sourcify oder Block-Explorer kompilieren den veröffentlichten Quellcode neu und vergleichen ihn mit dem Bytecode an der Vertragsadresse.Sourcify unterscheidet zwei Ergebnisse: eine exakte Übereinstimmung, bei der der bereitgestellte Bytecode Byte für Byte mit dem neu kompilierten identisch ist (abgesehen von Bibliotheken und Immutables), und eine einfache Übereinstimmung, bei der das Verhalten gleich ist, die Metadaten aber abweichen, etwa weil ein Kommentar oder ein Variablenname geändert wurde. Ist der Code verifiziert, vergleicht der Empfänger des Berichts den bereitgestellten Quellcode mit dem des geprüften Commits.

Die Verträgeaktualisierbarfügen eine weitere Ebene hinzu. Die Adresse, die die Kunden nutzen, ist ein Proxy, der an eine austauschbare Implementierung delegiert, und EthTrust stellt klar, dass die Zertifizierung des Proxys die Logik der Implementierung nicht abdeckt; diese wird gesondert geprüft. Ein korrekter Bericht über die Implementierung vom Januar sagt nichts über diejenige aus, die der Administrator im Juni installiert. Ein brauchbares Dokument benennt daher auch, wer die Implementierung ändern kann und mit welchen Kontrollen.

Wenn der Bericht den bereitgestellten Vertrag nicht abdeckt: ein Beispielfall

Nehmen wir als hypothetischen Fall an, dass ein Unternehmen einen Anleihe-Token emittiert und ein Vertriebspartner ein Zertifikat für dessen Smart Contracts verlangt, bevor er ihn seinen Kunden anbietet. Das Unternehmen schickt den Auditbericht, datiert auf März und ohne offene schwerwiegende Befunde. Das Compliance-Team des Vertriebspartners nimmt drei Prüfungen vor: Es sucht den im Bericht genannten Commit, öffnet die Adresse des Tokens im Explorer, um zu sehen, ob sein Code verifiziert ist, und vergleicht beide Versionen.

Sie stimmen nicht überein. Nach dem Audit hat das Entwicklungsteam die Berechnung der Zinsverteilung auf Wunsch des Vertriebs geändert, und diese Änderung wurde ohne erneute Prüfung bereitgestellt. Der Bericht ist echt und korrekt, beschreibt aber einen Code, der nicht im Netzwerk läuft. Außerdem ist der Token upgradefähig, und die Befugnis, die Implementierung zu ändern, liegt bei einem einzigen Schlüssel des technischen Teams. Der Bericht hatte dies als „akzeptierten“ Befund aufgeführt: Das Unternehmen hatte das Risiko anerkannt und beschlossen, es beizubehalten.

Das Unternehmen beauftragt die Prüfung der Änderung, die die neue Berechnung bestätigt, überträgt die Upgrade-Befugnis auf ein Konto, das mehrere Signaturen verschiedener Personen erfordert, und übergibt dem Vertriebspartner ein vollständiges Paket: beide Berichte, den finalen Commit, die verifizierte Adresse mit exakter Übereinstimmung und die Beschreibung, wer den Vertrag aktualisieren kann. Der Vertriebspartner hat kein Zertifikat erhalten, sondern eine Dokumentation, die er selbst überprüfen kann.

Zertifizierung von Smart Contracts: Sie ist so viel wert, wie sich überprüfen lässt

Ein Prüfbericht verringert das Risiko bekannter Fehler und von Logikfehlern in einer Version des Codes, innerhalb des angegebenen Umfangs. Sein Wert steigt, wenn er die Methodik nennt, reproduzierbare Tests enthält, behobene, akzeptierte und offene Befunde trennt und an einen Commit gebunden ist, der mit dem bereitgestellten Code übereinstimmt. Ein Siegel ohne Bericht, ohne Datum und ohne Bezug zum Code erlaubt keinerlei Überprüfung, und auch die Zahl der Befunde eignet sich nicht zum Vergleich von Anbietern, wenn der Umfang der Prüfungen unterschiedlich ist.

Was kein Bericht belegt, ist ebenfalls konkret. Er garantiert nicht, dass der Code frei von Schwachstellen ist, wie die EthTrust-Spezifikation selbst festhält; er deckt weder spätere Änderungen noch die Verwahrung der Administratorschlüssel ab; und er sagt nichts über die Compliance des Produkts aus, die vom Recht abhängt, das der Token verkörpert, und davon, wo er angeboten wird. Bei einer Anfrage nach einem Zertifikat gilt es herauszufinden, was der Anfragende überprüfen will. Die Antwort kombiniert den Bericht mit der Verifizierung des Deployments und der Beschreibung der Berechtigungen.

Was Sie dem Anfragenden übergeben sollten

Auf dieser Grundlage wird die Übergabe vorab vorbereitet und eignet sich für jede Gegenpartei:

• Der oder die Prüfberichte mit Umfang, Ausschlüssen und Datum.
• Der geprüfte und der bereitgestellte Commit, mit Erläuterung und Prüfung etwaiger Abweichungen.
• Die Adressen der Verträge in jedem Netzwerk, mit öffentlich verifiziertem Code.
• Wer die Befugnisse zur Administration, zum Upgrade oder zum Pausieren hat und mit welchen Kontrollen.
• Der Status jedes Befunds: behoben, akzeptiert mit Begründung oder offen.
• Die EU-Konformitätserklärung, nur wenn das Produkt unter den Tatbestand der Datenverordnung fällt.

Metlabs entwickeltSmart Contractsund bereitet die Prüfung mit dieser Rückverfolgbarkeit ab dem ersten Commit vor, sodass Bericht, verifizierter Code und dokumentierte Berechtigungen dem System entsprechen, das in Produktion ist. Wenn der Vertrag Teil einer vollständigen Anwendung ist, erläutert der Artikelzur Entwicklung einer dApp, welche Designentscheidungen vor dem Audit feststehen müssen.