Firefish: Multisig-Forensik On-Chain Verifizierung deines Kollaterals
Firefish verspricht nicht-custodiales Bitcoin-Lending. Aber wie verifizierst du, dass dein Kollateral tatsächlich in einem 3-of-3 Multisig liegt und nicht heimlich abgezogen werden kann? Dieser Guide befähigt dich zur unabhängigen On-Chain-Forensik. Du lernst die Oracle-Architektur zu verstehen, den Prefund-Notausgang zu identifizieren und einen Watch-Only-Account einzurichten, der bei jeder unautorisierten Bewegung Alarm schlägt.
Firefish – Vollständiger Testbericht
Dieses Technical Layer ist ein Deep-Dive in die Kollateral-Verifizierung. Für die vollständige Bewertung, Zinskonditionen und den Vergleich mit Alternativen lies unseren Select Report.
Das 3-of-3 Oracle-Modell
Die Architektur von Firefish basiert auf einem fundamentalen Prinzip: Kein einzelner Akteur kann dein Kollateral bewegen. Das System verteilt die Signatur-Autorität auf drei unabhängige Parteien, deren Kooperation für jede Transaktion zwingend erforderlich ist.
Im Zentrum steht ein 3-of-3 Multisignatur-Escrow. Das bedeutet: Drei Schlüssel existieren, und alle drei müssen eine Transaktion signieren, bevor das Kollateral bewegt werden kann. Es gibt keinen Master-Key, keine Hintertür, keine administrative Override-Funktion.
Die drei Schlüsselhalter
Price Oracle: Dieser Schlüssel gehört einem unabhängigen Dienst, der den aktuellen Bitcoin-Marktpreis überwacht. Das Oracle signiert nur, wenn der Preis innerhalb definierter Parameter liegt. Bei einem Margin Call wird die Signatur verweigert, bis der Borrower nachschießt oder die Liquidation eingeleitet wird.
Payment Oracle: Dieser Schlüssel bestätigt Fiat-Zahlungen. Hat der Borrower seine Zinsen bezahlt? Wurde der Kredit vollständig zurückgeführt? Das Payment Oracle verifiziert den Off-Chain-Geldfluss und gibt seine Signatur erst frei, wenn die Fiat-Seite erfüllt ist.
Borrower Ephemeral Key (B-EPH): Dein Schlüssel. Aber nicht irgendein Schlüssel. Ein ephemerer Schlüssel, der speziell für diese eine Transaktion generiert wird. Warum ephemer? Weil er nach der initialen Signatur der Closing-Transaktionen verworfen wird. Mehr dazu in § 04.
Einzelne Kompromittierung = Null Risiko.
Selbst wenn ein Oracle gehackt wird, kann der Angreifer dein Kollateral nicht bewegen. Er bräuchte die Kooperation der anderen beiden Parteien. Solange die Oracles unabhängig operieren und keine Absprachen treffen, ist das Gegenparteirisiko auf Protokollebene eliminiert.
Quelle: Firefish Protocol Documentation | firefish-protocol GitHub Repository | Stand: Januar 2026
Das Vertrauensmodell setzt voraus, dass Price Oracle und Payment Oracle tatsächlich unabhängig sind. Prüfe, ob die Oracles von verschiedenen juristischen Entitäten betrieben werden. Eine Konzentration beider Oracles bei Firefish selbst würde das Sicherheitsmodell untergraben. Die aktuelle Architektur nutzt externe Oracle-Provider.
Prefund-Forensik: Der Notausgang
Was passiert, wenn die Oracles plötzlich nicht mehr kooperieren? Server-Ausfall, Insolvenz, regulatorische Beschlagnahme. Dein Kollateral wäre dann in einem Escrow eingefroren, das niemand mehr öffnen kann. Firefish hat für dieses Szenario einen eingebauten Notausgang konstruiert.
Der Prozess ist zweistufig. Bevor dein Kollateral in das finale 3-of-3 Escrow wandert, durchläuft es einen Prefund-Output. Und genau hier liegt dein Sicherheitsnetz.
Stufe 1: Prefund
Dein BTC landet zunächst im Prefund-Output. Dieses Script hat zwei Ausgabepfade.
Stufe 2: Escrow
Aus dem Prefund wird die tx_escrow gebaut, die das finale 3-of-3 Multisig erzeugt.
Pfad A: 3-of-3 Multisig (Borrower-Prefund-Key + Price Oracle + Payment Oracle)
Pfad B: Borrower-Prefund-Key + Relativer Timelock (7 Tage)
Das Script ist ein OP_IF / OP_ELSE Konstrukt. Entweder alle drei signieren sofort (Normalfall), oder du wartest 7 Tage und kannst dann alleine mit deinem Prefund-Key ausgeben.
Quelle: Firefish Protocol Specification | docs.firefish.io | Stand: Januar 2026
Der 7-Tage-Timelock: Deine Versicherung
Der relative Timelock von 7 Tagen (1.008 Blöcke bei durchschnittlich 10-Minuten-Blockzeit) ist kein Bug, sondern ein Feature. Er gibt den Oracles Zeit, ihre Signatur zu liefern. Aber wenn nach 7 Tagen keine Kooperation erfolgt, kannst du dein Kollateral unilateral zurückholen.
Wichtig: Dieser Notausgang existiert nur im Prefund-Stadium. Sobald die tx_escrow gesendet wurde und dein BTC im finalen 3-of-3 Escrow liegt, greift dieser Mechanismus nicht mehr. Das ist der Grund, warum Firefish die Closing-Transaktionen vorab konstruiert und signieren lässt.
Wenn du einen Kredit aufnimmst, hast du nach dem Prefund ein kurzes Zeitfenster, bevor die tx_escrow broadcasted wird. In dieser Phase kannst du die Transaktion noch abbrechen. Sobald die tx_escrow in einem Block konfirmiert ist, bist du im Lending-Vertrag gebunden.
Script-Level Identifikation
Du willst nicht der Firefish-UI vertrauen, sondern die Blockchain selbst befragen. Das erfordert die Identifikation der relevanten Transaktionen auf Script-Ebene. Hier ist der methodische Ansatz.
TXID aus dem Dashboard
Firefish zeigt dir die Escrow-TXID im Dashboard. Kopiere diese ID. Sie ist dein Ausgangspunkt für die On-Chain-Analyse.
Block-Explorer aufrufen
Nutze mempool.space oder blockstream.info. Füge die TXID in die Suche ein. Du siehst jetzt die Transaktion mit allen Inputs und Outputs.
Output-Typ prüfen
Der Escrow-Output ist ein P2WSH (Pay-to-Witness-Script-Hash). Die Adresse beginnt mit bc1q... und hat eine Länge von 62 Zeichen.
Betrag verifizieren
Der Output-Betrag muss exakt deinem hinterlegten Kollateral entsprechen (abzüglich Mining-Fees). Jede Abweichung ist ein Red Flag.
Das Witness-Script dekodieren
Beim Ausgeben eines P2WSH-Outputs muss das ursprüngliche Script offengelegt werden. Erst dann siehst du die tatsächliche Multisig-Struktur. Solange der Output unausgegeben ist, siehst du nur den Hash. Das ist beabsichtigt: Privacy by Design.
Um das Script vor dem Ausgeben zu verifizieren, brauchst du entweder Zugang zum Firefish-Backend oder du nutzt das CLI-Tool aus dem firefish-protocol Repository. Letzteres ist der souveräne Weg.
Vergleiche die Escrow-Adresse mit der im Firefish-Dashboard angezeigten. Sie müssen identisch sein. Wenn Firefish eine andere Adresse anzeigt als die, die on-chain sichtbar ist, stimmt etwas fundamental nicht.
Der B-EPH Lebenszyklus
Der Borrower Ephemeral Key (B-EPH) ist das kryptographische Herzstück deiner Souveränität im Firefish-System. Sein Lebenszyklus ist präzise definiert und bewusst limitiert.
Ephemer bedeutet kurzlebig. Der B-EPH wird für genau einen Zweck generiert: Die Signatur der vorab konstruierten Closing-Transaktionen. Danach wird er verworfen. Unwiderruflich.
Generierung
Neuer Key für jeden Loan. Keine Wiederverwendung.
Signatur
Signiert alle Closing-Pfade vorab.
Verwerfung
Key wird nach Signatur gelöscht.
Pfad-Lock
Nur vordefinierte Ausgabepfade möglich.
Quelle: Firefish Protocol Specification | GitHub firefish-protocol | Stand: Januar 2026
Vorab-konstruierte Closing-Transaktionen
Bevor der B-EPH verworfen wird, signiert er mehrere Transaktionen, die unterschiedliche Ausgabepfade abdecken:
Borrower Path: Diese Transaktion gibt das Kollateral an dich zurück, sobald du den Kredit vollständig zurückgezahlt hast. Das Payment Oracle bestätigt die Fiat-Rückzahlung, das Price Oracle gibt grünes Licht, deine vorab signierte Transaktion wird broadcastet.
Lender/Liquidator Path: Falls du nicht zahlst oder der Margin Call ausgelöst wird, existiert eine vorab signierte Transaktion, die das Kollateral an den Lender oder Liquidator überträgt. Die Oracles aktivieren diesen Pfad nur unter definierten Bedingungen.
Weil der B-EPH nach der Signatur vernichtet wird, kann niemand neue Ausgabepfade konstruieren. Die Zukunft des Kollaterals ist zum Zeitpunkt des Loan-Starts vollständig determiniert. Es gibt keine nachträglichen Änderungen, keine neuen Transaktionen, keine Überraschungen.
Die Vernichtung des B-EPH ist ein Feature, kein Bug. Würde der Key weiter existieren, könnte er kompromittiert werden. Ein Angreifer mit Zugang zum B-EPH könnte in Kombination mit einem kompromittierten Oracle das Escrow leeren. Die Vernichtung eliminiert diesen Angriffsvektor.
Die Pfand-Mathematik: Real LTV
Das Firefish-Dashboard zeigt dir einen LTV-Wert (Loan-to-Value). Aber woher weißt du, dass diese Zahl stimmt? Die Antwort: Du rechnest selbst nach. On-Chain.
$$\text{Actual LTV} = \frac{\text{Loan Principal (USD)}}{\text{Locked BTC (On-Chain)} \times \text{Spot Price}}$$
Diese Formel ist die Wahrheit. Alles andere ist Interpretation.
Verifizierbar über: mempool.space (BTC-Betrag) | Spot-Preis von Referenz-Exchange | Loan Principal aus Vertrag
Die drei Variablen
Loan Principal (USD): Der Betrag, den du dir geliehen hast. Steht in deinem Kreditvertrag. Diese Zahl ist fix für die Laufzeit.
Locked BTC (On-Chain): Der Betrag, der tatsächlich im Escrow liegt. Nicht was Firefish sagt. Sondern was die Blockchain sagt. Du nimmst die TXID, gehst zum Block-Explorer, liest den Output-Betrag ab.
Spot Price: Der aktuelle Bitcoin-Preis. Nutze eine Referenz-Exchange wie Kraken, Bitstamp oder den CME Bitcoin Reference Rate. Wichtig: Verwende denselben Preis-Feed, den das Price Oracle nutzt.
Das Dashboard ist ein Spiegel der Blockchain, nicht die Wahrheit selbst. Wenn deine On-Chain-Berechnung einen anderen LTV ergibt als das Dashboard anzeigt, hast du entweder einen Rechenfehler gemacht oder das Dashboard lügt. Prüfe beide Möglichkeiten methodisch.
CLI-Audit und Regtest
Firefish hat sein Protokoll auf GitHub veröffentlicht. Das Repository firefish-protocol enthält nicht nur die Spezifikation, sondern auch ein CLI-Tool und Regtest-Skripte. Damit kannst du die gesamte Escrow-Logik lokal nachvollziehen, ohne echte Bitcoin zu riskieren.
# Repository klonen
git clone https://github.com/nicehash/firefish-protocol.git
cd firefish-protocol
# Dependencies installieren
npm install
# Regtest-Umgebung starten
npm run regtest:start
# Beispiel-Escrow generieren
npm run cli -- create-escrow --amount 1.0 --ltv 50
Was du im Regtest verifizieren kannst
Prefund-Transaktion: Generiere eine Test-Prefund-Transaktion und prüfe die Script-Struktur. Verifiziere, dass der 7-Tage-Timelock korrekt implementiert ist.
Escrow-Transaktion: Baue die tx_escrow und dekodiere das Witness-Script. Prüfe, dass es sich um ein echtes 3-of-3 Multisig handelt.
Closing-Transaktionen: Simuliere beide Pfade. Borrower Path und Lender Path. Verifiziere, dass die Signaturen korrekt sind und die Transaktionen valide.
Du brauchst Node.js (v18+), Bitcoin Core im Regtest-Modus und grundlegende Kommandozeilen-Kenntnisse. Wenn du diese Tools nicht hast, ist das CLI-Audit vielleicht nicht der richtige Einstiegspunkt. Starte mit der Block-Explorer-Analyse in § 03.
Unauthorized Spend Detection
Du willst sofort wissen, wenn jemand versucht, dein Kollateral zu bewegen. Die Lösung: Ein Watch-Only-Account in Sparrow Wallet, der die Escrow-Adresse überwacht und bei jeder Aktivität Alarm schlägt.
Sparrow Wallet installieren
Download von sparrowwallet.com. Verifiziere die GPG-Signatur. Sparrow ist Open Source und verbindet sich standardmäßig mit deiner eigenen Node oder öffentlichen Electrum-Servern.
Neues Watch-Only Wallet erstellen
File → New Wallet → Name: Firefish Monitor. Wähle Single Signature. Script Type: Native SegWit (P2WPKH).
Adresse importieren
Gehe zu Keystore → Import → Watch-Only Address. Füge die Escrow-Adresse ein, die du aus dem Block-Explorer kopiert hast.
Benachrichtigung einrichten
Sparrow zeigt dir den aktuellen Balance und alle Transaktionen. Für Push-Benachrichtigungen verbinde Sparrow mit einem Notification-Service oder checke regelmäßig manuell.
Watch-Only
Keine Private Keys nötig. Du beobachtest nur. Kein Risiko.
Instant Alert
Jede Bewegung wird sofort sichtbar. Unauthorized Spend erkennst du in Sekunden.
Was du überwachen solltest
Unconfirmed Transactions: Sobald jemand versucht, den Escrow auszugeben, erscheint die Transaktion im Mempool. Sparrow zeigt sie als Pending an.
Balance Changes: Wenn der Balance von deinem erwarteten Kollateral-Betrag abweicht, ist etwas passiert. Entweder eine legitime Closing-Transaktion oder ein Unauthorized Spend.
Nicht jede Bewegung ist ein Angriff. Legitime Szenarien: Du hast den Kredit zurückgezahlt (Borrower Path), ein Margin Call wurde ausgelöst (Lender Path), oder du hast selbst eine Rückzahlung initiiert. Prüfe den Kontext, bevor du Alarm schlägst.
Vertraue der Mathematik, nicht dem Interface.
Firefish bietet ein transparentes Lending-Protokoll. Aber Transparenz ist nur wertvoll, wenn du sie nutzt. Verifiziere dein Kollateral. On-Chain.
Firefish Audit starten → Vollständigen Testbericht lesen
Affiliate-Hinweis: Der Link zu Firefish ist ein Affiliate-Link. Bei Registrierung über diesen Link erhält BitAtlas eine Provision. Dies finanziert unsere Mission für werbefreie, unabhängige Dossiers. Dein Vorteil: Mit Code BITATLAS erhältst du bevorzugte Konditionen (prüfe aktuelle Verfügbarkeit).
BitAtlas ist unabhängig, gibt aber kuratierte Empfehlungen für Tools und Hardware, die den höchsten Sicherheitsstandards entsprechen. Souveränität durch Wissen.