Kryptografischer Audit-Proof.
Wie wir Widerrufe gerichtsfest machen.

Das Problem: Vertrauen skaliert nicht

Ein Widerruf ist ein rechtlich bindender Vorgang. Wer behauptet, widerrufen zu haben, braucht einen Beleg. Wer behauptet, einen Widerruf empfangen zu haben, ebenfalls. Im klassischen Setup legst du die Einträge in deiner Datenbank ab, dazu eine Log-Datei, und hoffst, dass niemand behauptet, du habest etwas verändert.

Das Problem: Der Betreiber der Datenbank, also wir, könnten theoretisch alles nachträglich editieren. Ein Anwalt, der deinen Beleg anzweifelt, hat leichtes Spiel. „Wie wissen wir, dass dieser Datenbank-Eintrag wirklich vom Zeitpunkt des Eingangs stammt?“

Die Lösung in einem Satz

Jeder Widerruf bekommt einen Fingerabdruck. Am Ende des Tages fassen wir alle Fingerabdrücke zu einem Baum zusammen. Wir veröffentlichen die Wurzel dieses Baums. Jeder kann später prüfen, ob sein Widerruf wirklich in dem Baum war, ohne Zugriff auf die anderen Widerrufe zu bekommen.

Wer den Rest dieses Artikels nicht liest, hat das Wesentliche verstanden.

Der Fingerabdruck: SHA-256

SHA-256 ist eine kryptografische Hash-Funktion. Du wirfst beliebig viel Text rein, du bekommst 64 Zeichen raus. Diese 64 Zeichen sind eindeutig für den Text. Änderst du ein einziges Komma, ändert sich der komplette Hash. Es ist praktisch unmöglich, zwei unterschiedliche Texte zu finden, die denselben Hash ergeben.

Jeder Widerruf bei uns wird beim Eingang in einen definierten Text-Block serialisiert: Name, Kontakt, Bestellreferenz, Freitext, Zeitstempel bis zur Millisekunde, Shop-ID. Dieser Block wird durch SHA-256 gejagt. Ergebnis: ein 64-Zeichen-Hash.

Der Hash ist wie ein Versiegelter-Umschlag-Nachweis. Wenn wir später den Inhalt zeigen und jemand den Hash nachrechnet, muss er exakt wieder passen. Weicht ein Zeichen ab, zum Beispiel weil wir nachträglich den Namen gekürzt haben, passt der Hash nicht mehr. Manipulation wird sichtbar.

Der Baum: Merkle-Tree

Ein Hash pro Widerruf ist gut, aber noch nicht genug. Wir müssten jeden Hash einzeln veröffentlichen, um sie prüfbar zu machen. Das wäre ein Datenschutz-Albtraum, weil aus den Hashes plus der Information „dieser Hash war zur Zeit X auf dem Server“ Rückschlüsse möglich wären.

Merkle-Trees lösen das elegant. Du nimmst zwei Hashes, kombinierst sie und hashst das Ergebnis erneut. Dieses neue Hash-Paar nimmst du wieder mit dem nächsten Paar zusammen, bis am Ende ein einziger Hash übrig bleibt: die Wurzel des Baums.

Widerruf A → hash_A ─┬───── hash_AB ─┬──────────┐
Widerruf B → hash_B ─┘              │             │
                                         │             Wurzel
Widerruf C → hash_C ─┬───── hash_CD ─┘
Widerruf D → hash_D ─┘

Die Wurzel ist nur dann exakt dieselbe, wenn jeder einzelne Widerruf darunter unverändert ist. Ein einziger geänderter Buchstabe in einem einzigen Widerruf würde dessen Hash kippen, dann das Paar-Hash darüber, dann das nächste, bis hoch zur Wurzel. Die Wurzel würde nicht mehr passen.

Die Notar-Analogie

Stell dir einen Notar vor. Jeden Tag um Mitternacht sammelt er alle Widerrufe des Tages, schreibt sie in ein Buch, siegelt das Buch und legt es in einen Tresor. Am nächsten Morgen veröffentlicht er auf einer Plakatwand vor seinem Haus einen kurzen Code, der nur zu diesem Buch passt.

Kommt später jemand und beansprucht, sein Widerruf sei im Buch, kann der Notar ihm zeigen: „Ja, schau, hier auf Seite 47, Zeile 12. Der Code auf der Plakatwand passt genau zu diesem Buch. Wenn ich irgendwas verändert hätte, würde der Code nicht mehr passen, und das würde jeder am Plakat sehen.“

Das Buch ist die Datenbank. Das Siegel ist der SHA-256-Hash. Die Plakatwand ist unser öffentlicher Endpoint. Der Code ist die Merkle-Wurzel.

Die öffentliche Wurzel: /proof

Jeden Tag um Mitternacht berechnen wir den Merkle-Tree aller an diesem Tag eingegangenen Widerrufe. Die Wurzel schreiben wir in einen öffentlichen Endpoint unter /proof/root/YYYY-MM-DD. Dieser Endpoint ist read-only und wird zusätzlich auf ein unabhängiges, schreib-einmal-Speichermedium geschrieben.

Jeder Shop-Betreiber bekommt zu jedem Widerruf ein proof_token. Das ist der komplette Pfad durch den Baum, von seinem eigenen Widerruf bis zur Wurzel. Mit diesem Token kann jeder Dritte, auch ein Richter, auch der Kunde selbst, die Echtheit prüfen.

GET /proof/{token}

Response 200:
{
  "revocationHash": "9f86d081884c7d659a2feaa0c55ad015...",
  "merkleProof": ["a3f5...", "b2e8...", "c1d4..."],
  "merkleRoot": "5d41402abc4b2a76b9719d911017c592...",
  "publishedAt": "2026-04-13T00:00:00Z",
  "verifiable": true
}

Wer die Logik prüfen will, nimmt den revocationHash, kombiniert ihn nach den Spielregeln von Merkle-Trees mit den Elementen aus merkleProof, und sollte am Ende exakt den merkleRoot bekommen. Das lässt sich in jeder Programmiersprache in zehn Zeilen Code nachrechnen.

Datenschutz: Warum das DSGVO-kompatibel bleibt

Der Clou am Merkle-Tree ist, dass die Wurzel keine Rückschlüsse auf einzelne Widerrufe zulässt. Wir veröffentlichen nicht die Namen, nicht die E-Mails, nicht einmal die einzelnen Hashes. Nur die Wurzel und, pro Widerruf, den individuellen Pfad-Proof.

Den Pfad-Proof bekommt nur, wer den proof_token kennt. Und den bekommen nur der Shop-Betreiber, der Kunde, und wer auch immer den Token von einem der beiden übergeben bekommt. Es gibt keine öffentliche Liste.

Damit erfüllt die Konstruktion gleichzeitig zwei scheinbar widersprüchliche Anforderungen: öffentliche Nachweisbarkeit und DSGVO-konformen Datenschutz der Einzelvorgänge.

Warum das vor Gericht hält

Ein Richter muss nicht verstehen, wie SHA-256 funktioniert, um ein Gutachten zu akzeptieren, das auf SHA-256 basiert. Die Funktion ist seit 2001 standardisiert, wird weltweit von Banken, Regierungen und Blockchains genutzt, und ist kryptografisch nicht gebrochen.

Wichtig ist, dass die Merkle-Wurzel zu einem Zeitpunkt veröffentlicht wurde, an dem noch niemand nachträglich Einfluss nehmen konnte. Deshalb die Midnight-Schreibung, und deshalb die unveränderliche Ablage. Wer behauptet, wir hätten einen Eintrag nachträglich hinzugefügt, müsste erklären, wie wir gleichzeitig die am Folgetag bereits öffentlich gewordene Wurzel verändert haben. Diese Erklärung gibt es nicht, solange SHA-256 nicht gebrochen wird.

Praxis: Was du im Dashboard siehst

Im Dashboard bekommt jeder Widerruf einen Link zu /proof/{token}. Du kannst diesen Link an einen Anwalt weitergeben oder ihn selbst prüfen. In einem eventuellen Rechtsstreit ist das deine technische-neutrale Verifikation, unabhängig von uns.

Und weil wir selbst nicht in den Baum eingreifen können, ohne die öffentliche Wurzel zu zerstören, sind auch wir an den Nachweis gebunden. Das ist kein Werbeversprechen, sondern ein strukturelles Limit des Systems.

Warum andere Anbieter das nicht haben

Die meisten Widerrufsbutton-Anbieter schreiben den Eintrag einfach in ihre Datenbank und verlassen sich auf Backups plus ein gutes Gewissen. Das reicht, bis der erste Streit eskaliert. Dann stehst du mit einer Datenbank-Zeile da, die ein technischer Gutachter in zehn Sekunden als manipulations-fähig klassifiziert.

Wir haben uns für den Mehraufwand entschieden, weil die Pflicht nach § 356a BGB zu neu ist, um auf Gewohnheit zu bauen. Die ersten Gerichtsentscheidungen kommen erst noch. Wenn sie kommen, willst du auf der Seite stehen, auf der die Mathematik ist.

Details zur Umsetzung in unserer Anleitung oder auf der Produktseite.