Berechtigungen und Austausch
CUBIT unterscheidet zwischen einem Kern mit festen Identitäten, einem auf Wartung beschränkten Guardian und einem Team, das die Peripheriemodule verwaltet. Der Ablauf des Guardians hebt die Austauschbefugnis des Teams nicht auf.
Was fest bleibt
Token, Haupthook, PoolManager, poolId, Prämien-WETH und Registry-Anker werden durch die Peripherie-Setter nicht ersetzt.
Der Token autorisiert seinen Hook über eine einmalige Anbindung. In den gelesenen Quellen haben die Sätze des Kerns keinen Setter. Neue Regeln, die den Kern ändern, erfordern eine neue Version, ihre Validierung und ihr Deployment; sie aktualisieren einen früheren Pool nicht automatisch.
Der Wartungs-Guardian
Der Guardian kann pause() und unpause() aufrufen, solange seine Befugnis nicht abgelaufen ist. Die Pause verhindert raiseFloor() und rebalance(); sie setzt Swaps nicht aus.
GUARDIAN_LIFETIME beträgt 14 Tage. Im Code wird guardianExpiry auf den Zeitstempel der Hook-Erstellung + 14 Tage gesetzt. Der Startplan kann von Tag +14 sprechen, aber die Integration muss den tatsächlichen Ablaufzeitpunkt des Vertrags abfragen.
Nach diesem Zeitpunkt ist eine frühere Wartungspause nicht mehr wirksam. burnAbsorbed() bleibt unabhängig von dieser Pause zugänglich.
Der historische Name isImmutable() beschreibt diesen Ablauf in den Kernansichten; er bestätigt nicht die Abwesenheit jeglicher Administration im Ökosystem.
Die Rolle des Teams
Das Team ist authority() in CubitV2. Es behält die Administration der Peripheriemodule und kann die folgenden vier Adressen austauschen:
| Setter | Wesentliche Anbindungsprüfungen | Folge |
|---|---|---|
setVault(next) |
Code vorhanden, gleicher Hook/Token/WETH, neuer Vault, keine ausstehende Vault-Abrechnung | Neuer Referenzvertrag für zukünftige Einlagen |
setRouter(next) |
Code vorhanden, gleicher Hook/PoolManager/poolId | Aktueller Router ausgetauscht |
setLens(next) |
Code vorhanden, gleicher Hook/PoolManager/poolId/Token | Aktueller Abfragevertrag ausgetauscht |
setForge(next) |
Code vorhanden, gleicher Hook und Team als Curator | Referenz-Factory für zukünftige Starts ausgetauscht |
Jede Änderung emittiert ModuleUpdated und erhöht moduleRevision. Prüfen Sie vor einem Vorgang die neue Adresse und ihren Code.
Die Grenzen der Kompatibilitätsprüfungen
Getter, die die richtigen Adressen zurückgeben, belegen eine erwartete Anbindung, nicht die Sicherheit des gesamten Kandidatencodes. Sie beweisen weder die Abwesenheit eines Proxys noch bösartigen Verhaltens in einer zukünftigen Implementierung.
Das Team wählt somit den für zukünftige Vorgänge verwendeten Peripheriecode. Diese Befugnis macht es erforderlich, jeden Austausch, seinen Bytecode und seine Wechselwirkungen zu prüfen.
Bereits hinterlegte Mittel
Ein Vault-Austausch überträgt weder CUBIT noch Prämien aus dem früheren Vertrag. Seine Positionen, Fristen und Auszahlungswege bleiben in diesem früheren Vault. Die Registry bewahrt die Liste der Vaults, und das Frontend muss diese Positionen weiterhin anzeigen.
First-Bound-Verbindungen und bereits aufgelaufene Referral-Ansprüche bleiben erhalten. Ein früherer Router verliert das Recht, neue Referrals zuzuweisen, unterliegt aber weiterhin den Hook-Steuern.
Der Austausch von Forge betrifft zukünftige Starts; bereits erstellte Kindmärkte behalten ihre Verträge.
Diese Setter reparieren einen fehlerhaften Vertrag nicht rückwirkend und verschieben keine Mittel, die er halten könnte. Die Möglichkeit, eine Auszahlung On-Chain aufzurufen, und ihre Verfügbarkeit im Frontend müssen getrennt geprüft werden.
Freigaben und Signaturen
Eine Freigabe ist an einen bestimmten Spender gebunden. Sie folgt nicht der aktuellen Adresse der Registry. Das Frontend muss den Vorgang erneut validieren, wenn sich Revision oder Module ändern, insbesondere zwischen einer Freigabe und einem Swap.
Eine Links-Signatur bindet die Registry und die Blockchain der EIP-712-Domain. Sie darf nicht ohne erneute Prüfung der signierten Daten an einen anderen Vertrag umgeleitet werden.
Quellen: CubitV2.sol, CubitHook.pause, isPaused, isImmutable, contracts/docs/MODULE_SETTERS.md und die Frontend-Prüfungen releases.ts / vault.ts.