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 Schlüssel, deren Kooperation für jede Transaktion zwingend erforderlich ist. Zwei davon betreibt derzeit Firefish selbst – was das bedeutet und was nicht, steht im Sicherheits-Axiom weiter unten.
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 Dienst, der den aktuellen Bitcoin-Marktpreis überwacht. Die Spezifikation lässt dafür eine vertrauenswürdige Institution, ein öffentliches Oracle oder einen Schwellenwert aus mehreren zu; betrieben wird das Price Oracle derzeit von Firefish. 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. Auch dieses Oracle betreibt derzeit Firefish.
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 Schlüssel.
Dass darüber hinaus auch das Gegenparteirisiko entfällt, gilt nur, solange die beiden Oracles unabhängig operieren. Das ist die Bedingung des Protokolls, nicht sein heutiger Zustand: Die Spezifikation nennt Price Oracle und Payment Oracle ausdrücklich als derzeit von Firefish betrieben. Ein Zusammenwirken beider Firefish-Schlüssel bewegt trotzdem nichts, weil deiner fehlt – die Konstruktion schützt gegen einen kompromittierten Schlüssel und gegen einseitigen Zugriff der Plattform. Was sie heute nicht leistet, ist die Verteilung auf drei voneinander unabhängige Häuser.
Quelle: Firefish Protocol – technische Spezifikation, Abschnitte „Participants“ und „Escrow Contract“ – dort auch der Satz, dass Price Oracle und Payment Oracle derzeit von Firefish betrieben werden | Firefish-io/firefish-protocol | Stand: 08.09.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.
Das 3-of-3 Multisig setzt voraus, dass dein Signing-Key auf einer Hardware-Wallet isoliert ist. Unser Operation Cold Storage Guide zeigt den vollständigen Pfad zur Hardware-Souveränität.
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 | 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 – technische Spezifikation, Abschnitt „Escrow Contract“ | Firefish-io/firefish-protocol | Stand: 08.09.2026
Vorab-konstruierte Closing-Transaktionen
Bevor der B-EPH verworfen wird, signiert er alle Transaktionen, die das Kollateral je wieder aus dem Escrow bewegen können. Die Spezifikation nennt fünf Ausgänge, und jeder hat seine eigene, vorab konstruierte Transaktion.
Ausgang
Kollateral geht an
Letzte Signatur
Quelle: Firefish Protocol – technische Spezifikation, Abschnitte „Loan outcomes“ und „Summary of closing transactions“ | Stand: 08.09.2026
Wie die letzte Signatur zustande kommt. Jede dieser Transaktionen ist doppelt vorsigniert: von dir mit dem B-EPH und von dem Oracle, das für diesen Ausgang nicht zuständig ist. Tritt der Fall ein, setzt das zuständige Oracle die fehlende Signatur und sendet die Transaktion. Bei der Liquidation fehlen beide, weil dort beide Oracles zusammen entscheiden.
Zwei Ausgänge tragen zusätzlich eine Sperrfrist. Die Ausfall-Transaktion wird erst zum Fälligkeitsdatum gültig, weil vorher kein Ausfall festgestellt werden kann. Und tx_recover wird einen Monat nach Fälligkeit gültig, weil das Kollateral bis dahin längst über einen der anderen Wege bewegt wäre, wenn die Oracles antworten.
Der fünfte Pfad ist der, der ohne Firefish auskommt. Bei tx_recover fehlt keine Signatur – beide Oracles haben sie vorab geleistet, bevor dein Bitcoin überhaupt im Escrow lag. Zurück hält sie allein die Sperrfrist. Antworten die Oracles nicht mehr, sendest du diese Transaktion selbst und bekommst das gesamte Kollateral zurück. Das ist der Grund, warum die Abhängigkeit von zwei Diensten desselben Hauses aus § 01 nicht in einen Totalverlust führen kann: Der Ausweg kostet Zeit, keine Erlaubnis.
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.
Die LTV-Mathematik ist nur die halbe Wahrheit. Unser Firefish Select Report analysiert Zinskonditionen, Gebührenstruktur und den Vergleich mit traditionellen Bitcoin-Lending-Alternativen.
CLI-Audit und Regtest
Firefish hat die Implementierung seines Protokolls auf GitHub veröffentlicht – eine Rust-Bibliothek mit einer Beispiel-CLI und einem Testskript für den Regtest-Betrieb. Die Spezifikation liegt getrennt davon in der Dokumentation. Damit kannst du die Escrow-Logik lokal nachvollziehen, ohne echte Bitcoin zu riskieren. Das Repository ist ausdrücklich zum Prüfen freigegeben, nicht zum Weiterentwickeln.
# Repository klonen
git clone https://github.com/Firefish-io/firefish-protocol.git
cd firefish-protocol
# CLI bauen (Rust ab 1.63, C-Compiler erforderlich)
cargo build
# Regtest-Knoten separat starten, dann das mitgelieferte Testskript
./test.sh
Was du im Regtest verifizieren kannst
Prefund-Transaktion: Das Testskript nennt dir eine Funding-Adresse, du bespielst sie im Regtest und fügst die Rohtransaktion ein. Danach lässt sich die Script-Struktur des Prefund-Outputs prüfen. Beachte dabei: Das Skript setzt eine relative Sperrfrist von 42 Blöcken, damit der Test in vertretbarer Zeit durchläuft. Die 7 Tage der Spezifikation findest du im Protokolldokument, nicht im Regtest-Lauf.
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: Das Skript spielt Rückzahlung, Ausfall und Liquidation durch, dazu die Stornierung aus dem Prefund. Verifiziere, dass die Signaturen korrekt sind und die Transaktionen valide.
Du brauchst eine Rust-Toolchain ab 1.63, einen C-Compiler, Bitcoin Core im Regtest-Modus und grundlegende Kommandozeilen-Kenntnisse. Alternativ baut das Repository über Nix. Wenn du das 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 (tx_repayment), ein Margin Call wurde ausgelöst (tx_liquidation), 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 im Test → 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.