Screening, bevor die
Transaktion signiert wird.
Seit den Tornado-Cash-Listungen tragen Oberflächen, die Transaktionen vermitteln, eigenes Sanktionsrisiko. ChainEvidence prüft die Zieladresse, bevor der Wallet-Dialog erscheint — ohne Konto-Zwang für Nutzer.
Exposure an der Oberfläche
Sanktionsrisiko
Die Vollzugspraxis seit Tornado Cash zeigt: Frontends, die Transaktionen mit gelisteten Adressen vermitteln, tragen eigenes regulatorisches Risiko.
Die Permissionless-Randbedingung
Kontrollen, die Registrierung oder KYC-Hürden verlangen, widersprechen der Funktionsweise dieser Plattformen. Screening muss inline geschehen, ohne den Ablauf zu verändern.
Kleine Engineering-Teams
Integrationen, die Monate und ein eigenes Team kosten, sind für Plattformen mit einer Handvoll Entwickler nicht tragfähig. Die Kontrolle muss leicht einzuführen und leicht zu betreiben sein.
Risikohaltung ist eine Policy-Frage
Ob gewarnt, nur Gelistetes blockiert oder auch Hochrisiko gestoppt wird, entscheidet Ihre Policy — das Werkzeug soll sie abbilden, nicht diktieren.
Inline-Screening für Ihr Frontend
Ein Script-Tag
Ein einzelnes Script-Tag im Frontend — keine Build-Änderungen, keine Backend-Integration. Funktioniert mit React, Vue, Svelte oder reinem HTML.
Screening vor der Transaktion
Ausgehende Transaktionen werden abgefangen und die Zieladresse gegen Sanktionslisten und Risikodaten geprüft, bevor der Wallet-Dialog erscheint.
Drei Durchsetzungsmodi
Warn, Block-Sanctioned oder Strict — Sie wählen die Haltung. Gelistete Adressen lassen sich hart blockieren, riskante erhalten eine wegklickbare Warnung.
Nutzungsbasierter Zugang
Abrechnung je Prüfung mit Guthaben und Client-Cache — passend für Frontends. Plattform-Pläne ergänzen Monitoring, Prüfprotokoll und Reporting, sobald Nachweise gefordert sind.
Ein Tag im Frontend
<script
src="https://chainevidence.net/api/v1/sdk.js"
data-key="YOUR_API_KEY"
data-mode="block-sanctioned"
></script>Was Nutzer sehen, wenn eine Zieladresse geprüft wird:
Die Transaktion läuft normal weiter. Kein Dialog, keine Verzögerung.
Eine Warnung mit Begründung erscheint. Nutzer können prüfen und fortfahren oder abbrechen.
In blockierenden Modi wird die Transaktion gestoppt, bevor sie die Wallet erreicht.
Von der Evaluierung in die Produktion
In der Sandbox evaluieren
Ihre Entwickler prüfen Abdeckung, Latenz und Verdict-Semantik noch am selben Tag gegen die produktive API — ganz ohne Beschaffungsprozess.
Pilot zu Monatskonditionen
Produktivverkehr läuft zu monatlichen Konditionen, während interne Prüfung und Beschaffung abgeschlossen werden.
Übergang in den Enterprise-Vertrag
Verhandeltes Volumen, vertragliches SLA, Self-Hosting bzw. EU-Datenhaltung und Auftragsverarbeitungsvertrag für die Lieferantenprüfung.
Screening an der Oberfläche.
Fügen Sie Screening vor der Transaktion mit einem Script-Tag hinzu — Monitoring und Prüfnachweise kommen dazu, wenn Ihre Pflichten wachsen.