v1.37.0, veröffentlicht am 2026-04-06, fügt eine Funktion hinzu, die kleiner klingt, als sie ist: Single-Key-Schnorr-Signatur für Enterprise-Tresore. Wo der Standard-Tresorpfad zwei Signaturen von zwei Geräten einsammelt, gibt ein 1-aus-1-Tresor nun mit einer direkten Schnorr-Signatur aus einem einzigen konfigurierten Schlüssel aus. Die Schlagzeile ist Policy, nicht Protokoll — Enterprise-Teams können je Tresor entscheiden, welches Risikoprofil jeder Geldtopf verdient. Dieselbe Release bringt Unterstützung für das Starten von Enterprise-FluxNodes, eine Korrektur der EVM-Gasgebühren-Mathematik, strengere Zahlenpräzision in Formatierung und CSV-Export sowie stabilere SSP-Connect-Socket-Verarbeitung.
Die 1-aus-1-Tresor-Signatur kommt
Der neue Modus heißt 1-aus-1 — in der Tresor-Konfiguration wallet_only oder key_only etikettiert, je nachdem, welchen Schlüssel die Organisation als Ausgeber bestimmt. Ein so eingestellter Tresor braucht genau eine Signatur von genau einem Schlüssel, um eine Transaktion zu autorisieren. Keine Co-Signer-Aufforderung, kein zweiter Geräte-Handshake, keine Hin-und-Rückreise durch den Multisig-Ablauf. Der Nutzer prüft die Transaktion in derselben tresorbewussten UI, die in SSP Enterprise startet: Multisig-Tresore für Unternehmen eingeführt wurde, bestätigt auf dem gewählten Gerät, und das Wallet sendet.
Was das in der Praxis freischaltet, ist ein schnellerer Pfad für die Arten von Ausgaben, die nicht jedes Mal eine Zwei-Geräte-Zeremonie rechtfertigen: eine kleine Rechnung bezahlen, einen operativen Float aufstocken, eine wiederkehrende API-Rechnung begleichen, Mittel innerhalb eines org-kontrollierten Adress-Sets bewegen. Die Arbeit, die zwei Menschen an zwei Geräten für Auszahlungen unter zehn Dollar erforderte, wird zu einem Tipp auf einen konfigurierten Schlüssel.
Multisig ist nicht weg — es ist jetzt eine Policy-Entscheidung
Es ist wichtig, die Änderung richtig zu lesen. SSP hat Multisig nicht geschwächt und keinen Standard umgestellt. Die 2-aus-2-Architektur, die das Wallet seit Vorstellung von SSP Wallet — echtes 2-aus-2-Multisig geht live absichert, bleibt der Standard und bleibt die richtige Antwort für hochwertige Tresore. Was v1.37.0 hinzufügt, ist die auf Enterprise begrenzte Option, die Schwelle bei einem bestimmten Tresor abzusenken, wenn die Organisation entscheidet, dass dieser Tresor den Zwei-aus-zwei-Schutz nicht benötigt.
Die Rahmung zählt, weil Risiko innerhalb einer Treasury nicht einheitlich ist. Der Tresor mit der Unternehmensreserve und der Tresor mit zwanzig Dollar heißem Float sollten nicht unter derselben Reibung stehen. Bis v1.37.0 standen sie es. Jetzt nicht mehr, und die Wahl liegt bei denen, die das Risiko kennen: der Organisation, die ihre eigenen Schlüssel verwaltet.
Direkte Schnorr-Signaturen
Unter der Haube nutzt der 1-aus-1-Modus dieselbe Schnorr-Primitive, die SSP in Ethereum kommt zu SSP — Schnorr-Multisig auf ERC-4337 auf die EVM-Seite gebracht hat — nur wird die Signatur jetzt von einem einzelnen Schlüssel erzeugt, statt eine 2-aus-2-aggregierte Schnorr-Signatur über ERC-4337 zu sein. Die Transaktion sieht on-chain normal aus. Es gibt keinen speziellen Opcode zu parsen, keinen Multisig-Vertrags-Handshake, auf den zu warten wäre. Wo der 2-aus-2-Pfad zwei Teilsignaturen zu einer Schnorr-Signatur aggregiert und sie einreicht, erzeugt der 1-aus-1-Pfad genau diese Art von Signatur direkt aus einem Schlüssel.
Die Folge für die Verifikation ist sauber: Externe Indexer, Block-Explorer und Gegenparteien müssen nicht wissen, welchen Modus ein Tresor benutzt. Sie sehen eine gültige Schnorr-Signatur, die Kette akzeptiert sie, und die Mittel bewegen sich. Der Policy-Unterschied lebt, wo er sollte — innerhalb der Autorisierungslogik des Wallets, nicht auf der Leitung.
Enterprise-FluxNode-Start
Die andere Enterprise-förmige Änderung in v1.37.0 ist operativ. Enterprise-Tresore können nun Flux-Nodes direkt aus dem Tresor heraus starten — die Sicherheits-Transaktion und die Delegate-Konfiguration im selben Fluss signieren, den du bereits zum Signieren von Zahlungen verwendest. Für Organisationen, die Flux-Infrastruktur betreiben, schließt das eine Lücke: Sicherheit, die in einem Tresor liegt, muss nicht mehr über ein persönliches Wallet umgeleitet werden, um eingesetzt zu werden.
Zusammen mit den Flux-Delegierten und dem „alle Nodes starten" aus Flux-Delegierte und Node-Management kommen zu SSP haben Enterprise-Betreiber jetzt einen End-zu-End-Node-Lebenszyklus innerhalb des Wallets — Sicherheit aus dem Tresor signiert, Delegate aus dem Tresor konfiguriert, Flotte aus dem Wallet verwaltet.
EVM-Gasmathematik + CSV-Präzision
Zwei leisere Korrekturen runden die Release ab. Der EVM-Gasgebührenschätzer hatte maxPriorityFeePerGas doppelt gezählt — es auf maxFeePerGas aufaddiert, obwohl maxFeePerGas die Priority-Fee bereits enthält. v1.37.0 entfernt das Duplikat, sodass die Schätzung auf dem Bildschirm mit dem übereinstimmt, was das Wallet tatsächlich zahlt. Betroffene Ketten überquotieren nicht mehr; Quittungen passen zu Vorschauen.
Auch die Zahlenformatierung wurde gestrafft. Krypto- und Fiat-Werte sowie der CSV-Export, eingeführt in Mehr ETH-Token, CSV-Export und Brave-Unterstützung, laufen jetzt durch toFixed() plus parseFloat() statt durch das rohe toNumber(). Der Gleitkomma-Staub, der sich gelegentlich in präzise Salden schlich, verschwindet. Darunter erhielt der SSP-Connect-Socket-Kontext stabilere Nachrichtenverarbeitung — weniger verlorene Ereignisse, wenn ein dApp-Tab beschäftigt ist.
Keine davon ändert die Policy-Geschichte, aber zusammen verhindern sie, dass die neue Flexibilität laut wird.