Ich habe die Sicherheitsseite, den Audit-Backlog und die Hinweise zur Berechtigung von @TermMax zusammen angesehen und festgestellt, dass „auditiert“ in Wahrheit nur die äußerste Schicht ist. Was letztlich entscheidet, wie das System reagiert, wenn etwas schiefgeht, sind welche Verträge sich ändern können, wer sie anhalten darf und wie zentrale Rechte gemeinsam kontrolliert werden.#TermMax
Das öffentliche Repository listet derzeit die Berichte von ABDK in mehreren Phasen, den TMX-Report sowie den Cantina-Wettbewerbsbericht. Außerdem gibt es bei Immunefi auch noch laufende Vulnerability-Bounties. Die Dokumentation erwähnt außerdem ein 24‑Stunden‑Monitoring on Chain und Mechanismen zum automatischen Pausieren. Diese Informationen zeigen, dass das Projekt mehrschichtige Schutzmaßnahmen umgesetzt hat. Sie lösen jedoch das Problem des Erkennens und verkürzen die Reaktionszeit—sie bedeuten nicht, dass die Verträge nie wieder Probleme bekommen.
Wenn man weiter in die Berechtigungsebene zerlegt: TermMax übergibt kritische Verwaltungsaktionen an ein 4‑of‑6‑Multi‑Sig, Märkte werden voneinander isoliert, und die Vault‑Parameter werden durch ein Zusammenspiel aus Timelock und Guardian ausbalanciert. Gleichzeitig hält die offizielle Stelle ausdrücklich die Fähigkeit zum Not‑Stopp vor und trifft für bestimmte Komponenten zudem Vorkehrungen für Upgrade‑Pfadierungen. Anders gesagt: Dieses System garantiert Sicherheit nicht dadurch, dass „niemand etwas kontrollieren kann“, sondern dadurch, dass Isolierung, Verzögerung, gemeinsame Autorisierung mehrerer Parteien und Notfallaktionen Single‑Point‑Risiken begrenzen.
Die Markt‑Isolation nehme ich mir als Punkt separat vor. Eine einzelne Markt‑Deployment ist zwar nicht automatisch gleichbedeutend damit, dass ein Verlust nicht passieren kann, aber sie bedeutet, dass die Fehlergrenze so weit wie möglich nicht auf andere Märkte übergreift. Bei Sicherheitsdesign geht es oft nicht darum, Risiken komplett auszuschalten, sondern zunächst den Umfang zu begrenzen, in den sich ein einmaliger Fehler auswirken kann.
Ich finde das sogar überzeugender als den Satz „Code ist Gesetz“, denn wenn DeFi tatsächlich auf Anomalien stößt, müssen am Ende zwei konkrete Fragen beantwortet werden: Reichen die Berechtigungen aus, um schnell genug zu handeln—und ist die Grenze breit genug, aber nicht zu breit? Wenn es zu langsam ist, ist möglicherweise keine Zeit mehr, um rechtzeitig zu stoppen; wenn es zu weit ist, kann die Governance selbst zu einer Fehlerquelle werden.
Deshalb werde ich im Folgenden weiterhin prüfen, ob sich die Multi‑Sig‑Mitglieder ändern, wie weit der Umfang der Upgrade‑Komponenten reicht, welche Pause‑Events auftreten und welche Reparaturen nach einem Audit dokumentiert sind. Der Audit‑Report zeigt, dass sich jemand ernsthaft auf die Suche nach Problemen gemacht hat; die Audit‑Berechtigungshistorie wird mir dann sagen, wie das System in der Realität mit Problemen umgeht.
Das öffentliche Repository listet derzeit die Berichte von ABDK in mehreren Phasen, den TMX-Report sowie den Cantina-Wettbewerbsbericht. Außerdem gibt es bei Immunefi auch noch laufende Vulnerability-Bounties. Die Dokumentation erwähnt außerdem ein 24‑Stunden‑Monitoring on Chain und Mechanismen zum automatischen Pausieren. Diese Informationen zeigen, dass das Projekt mehrschichtige Schutzmaßnahmen umgesetzt hat. Sie lösen jedoch das Problem des Erkennens und verkürzen die Reaktionszeit—sie bedeuten nicht, dass die Verträge nie wieder Probleme bekommen.
Wenn man weiter in die Berechtigungsebene zerlegt: TermMax übergibt kritische Verwaltungsaktionen an ein 4‑of‑6‑Multi‑Sig, Märkte werden voneinander isoliert, und die Vault‑Parameter werden durch ein Zusammenspiel aus Timelock und Guardian ausbalanciert. Gleichzeitig hält die offizielle Stelle ausdrücklich die Fähigkeit zum Not‑Stopp vor und trifft für bestimmte Komponenten zudem Vorkehrungen für Upgrade‑Pfadierungen. Anders gesagt: Dieses System garantiert Sicherheit nicht dadurch, dass „niemand etwas kontrollieren kann“, sondern dadurch, dass Isolierung, Verzögerung, gemeinsame Autorisierung mehrerer Parteien und Notfallaktionen Single‑Point‑Risiken begrenzen.
Die Markt‑Isolation nehme ich mir als Punkt separat vor. Eine einzelne Markt‑Deployment ist zwar nicht automatisch gleichbedeutend damit, dass ein Verlust nicht passieren kann, aber sie bedeutet, dass die Fehlergrenze so weit wie möglich nicht auf andere Märkte übergreift. Bei Sicherheitsdesign geht es oft nicht darum, Risiken komplett auszuschalten, sondern zunächst den Umfang zu begrenzen, in den sich ein einmaliger Fehler auswirken kann.
Ich finde das sogar überzeugender als den Satz „Code ist Gesetz“, denn wenn DeFi tatsächlich auf Anomalien stößt, müssen am Ende zwei konkrete Fragen beantwortet werden: Reichen die Berechtigungen aus, um schnell genug zu handeln—und ist die Grenze breit genug, aber nicht zu breit? Wenn es zu langsam ist, ist möglicherweise keine Zeit mehr, um rechtzeitig zu stoppen; wenn es zu weit ist, kann die Governance selbst zu einer Fehlerquelle werden.
Deshalb werde ich im Folgenden weiterhin prüfen, ob sich die Multi‑Sig‑Mitglieder ändern, wie weit der Umfang der Upgrade‑Komponenten reicht, welche Pause‑Events auftreten und welche Reparaturen nach einem Audit dokumentiert sind. Der Audit‑Report zeigt, dass sich jemand ernsthaft auf die Suche nach Problemen gemacht hat; die Audit‑Berechtigungshistorie wird mir dann sagen, wie das System in der Realität mit Problemen umgeht.