In dieser Lern- und Experimentieranwendung befinden sich die zugrunde liegenden ERC20-Token im EVM-Konto des Vaults. Auf Midnight halten Nutzer abgeschirmte Vault-Token, die ihren Anspruch auf diesen Pool repräsentieren. Dass native Assets auf Ethereum verbleiben, beantwortet daher die Frage, wo die Assets verbucht sind. Es beantwortet für sich genommen jedoch nicht, wer sie bewegen kann.

Dieser Unterschied erklärt auch das Verbrennen. Mit dem Start einer Auszahlung wird der abgeschirmte Anspruch, der eingelöst wird, vernichtet, nicht aber der zugrunde liegende ERC20-Token. Eine erfolgreiche externe Zahlung schließt die Einlösung ab. Tritt eines der dokumentierten Fehlerergebnisse ein, kann die Anwendung den Anspruch wiederherstellen.

Im Ablauf der Auszahlung gilt das Ausgeben einer Münze durch den Inhaber als Autorisierung. Der Inhaber stellt eine abgeschirmte Vault-Münze bereit, die zum Token und zum exakt angeforderten Auszahlungsbetrag passt, und wählt anschließend eine Zieladresse. Der Circuit weist eine Nulladresse als Ziel zurück.

Der Circuit startWithdraw verbrennt diese Münze und stellt die Anfrage in eine Warteschlange. Bei einem späteren Leeren der Warteschlange wird dem Transaktionszähler des Vault-Kontos eine Sequenznummer zugewiesen, der sogenannte Nonce. Beim Sendeschritt wird dann eine Anfrage für die genaue ERC20-Überweisung erfasst und der MPC-Signierdienst, also der Dienst für Mehrparteienberechnungen, benachrichtigt.

Der Rest besteht aus mehreren klar voneinander getrennten Zuständigkeiten:

Der Signierdienst überträgt die Transaktion nicht an das Netzwerk. Die dApp oder der Relayer stellt sie mit der verifizierten Signatur zusammen und sendet sie an die EVM-Chain.

Eine fehlgeschlagene Überweisung und ein nicht reagierender Dienst sind zwei verschiedene Dinge

Nach dem Signieren hat der Dienst eine zweite Aufgabe. Er stellt eine Bestätigung über das Ergebnis der externen Transaktion bereit, getrennt von der Signatur, die diese Transaktion autorisiert hat. Das Integrationsprotokoll beschreibt, wie dieses Ergebnis an die Anfrage und die zurückgegebenen Daten gebunden wird.

Bevor der Vault die Abwicklung zulässt, prüft er die Bestätigung anhand des konfigurierten MPC-Antwortschlüssels.

Die Auszahlungs-Spezifikation beschreibt drei Fälle, in denen der Anspruch wiederhergestellt werden kann: eine rückgängig gemachte Transaktion, eine Transaktion, die nicht mehr ausgeführt werden kann, weil eine andere ihren Nonce verbraucht hat, oder eine ausgeführte ERC20-Überweisung, die false zurückgegeben hat. Nachdem das bestätigte Ergebnis in die Warteschlange gestellt und diese geleert wurde, schließt der Auszahlende die Anfrage ab und erhält einen neu geprägten abgeschirmten Betrag.

Eine erfolgreiche Überweisung mit dem Rückgabewert true lässt das Verbrennen bestehen und schließt die Anfrage. Im Fehlerfall wird ein Vault-Anspruch auf Midnight wiederhergestellt, anstatt das native Asset erneut an das Ziel zu zahlen.

Der dokumentierte Rückerstattungsweg setzt eine verifizierte und aus der Warteschlange abgerufene Bestätigung voraus. Eine unbeantwortete Signieranfrage oder eine fehlende Antwort zum Ergebnis erfüllt diese Bedingung nicht von selbst.

Der Code des Vaults enthält außerdem einen Notfallmechanismus. Der Deployer kann für eine festgefahrene Vault-Transaktion eine Anfrage zur Ersetzung des Nonce starten. Dabei wird vom Vault-Konto bei demselben Nonce eine Überweisung mit dem Wert null an das Konto selbst gesendet.

Damit soll die ursprüngliche Transaktion unausführbar gemacht werden. Anschließend kann ein bestätigtes Ergebnis die Abwicklung als fehlgeschlagen unterstützen. Diesen Wiederherstellungsvorgang zu starten, ist dem Deployer vorbehalten, obwohl das Senden einer bereits festgelegten Anfrage erlaubnisfrei möglich ist. Es handelt sich um eine weitere signierte Transaktion mit anschließender Bestätigung, nicht um einen Ausstieg, der den MPC-Dienst umgeht.

Der Code enthält auch einen konkreten Warnhinweis: Wird die ursprüngliche Anfrage ersetzt, bevor der MPC sie signiert hat, kann es zu einem Wettlauf mit dieser Anfrage kommen. Dadurch erhält sie möglicherweise keine Bestätigung, während der abgegebene abgeschirmte Anspruch verbrannt bleibt.

Der Deployer legt außerdem die anfängliche Konto-, Chain- und Antwortschlüsselkonfiguration fest und kann die Gas-Einstellungen des Vaults ändern. Für bereits gestartete Anfragen gelten weiterhin die Gaswerte, die bei ihrem Start kopiert wurden.

Der Produktionstest ist der vollständige Auszahlungsweg

Die Mainnet-Unterstützung ist laut Roadmap von SIG weiterhin an Ledger v9 gebunden. Das Repository-Update vom 21. Okt. bereitet Vault-Paket 0.5.0 auf SIG Midnight 0.25.0 vor. In dieser Codeversion enthält das veröffentlichte Adressregister eine Stagenet-Vault-Adresse und einen leeren Mainnet-Eintrag, den die Datei als noch nicht bereitgestellt oder veröffentlicht definiert.

SIGs separate Full-Stack-Demo nutzt Midnight Stagenet und Ethereum Sepolia, beides öffentliche Testnets, sowie einen MPC-Antwortdienst namens „fakenet“. Damit wird ein Anwendungsablauf demonstriert. Es wird damit nicht belegt, dass eine produktive Gruppe unabhängiger Signer diese Demo betreibt.

SIGs Beschreibung des Threshold-Signierens behandelt die Erstellung einer Signatur. Um eine tatsächliche Bereitstellung zu bewerten, muss man außerdem wissen, wie viele Signer zusammenarbeiten müssen, wer sie betreibt, wie diese Vereinbarungen geändert werden können und welche Wiederherstellung möglich ist, wenn der reguläre Dienst nicht verfügbar ist.

Auch der Prüfungsumfang muss ebenso präzise angegeben werden. Hackens Abschlussbericht vom 21. Feb. 2025 behandelt die Chain-Signature-Contracts in Ethereum Solidity. Sein Umfang belegt keine Prüfung des neueren Compact-Vaults oder des vollständigen Nightmode-Systems.

Der nächste Nachweis zur Bereitstellung ist daher bedeutsamer als eine weitere Ankündigung zur Expansion: der genaue Produktionscode und die zugehörigen Adressen, die Signier- und Bestätigungskonfiguration, die Prüfungsabdeckung dieser Komponenten sowie ein Wiederherstellungsweg, der auf einen Dienstausfall abgestimmt ist.