Aave-Gründer Stani Kulechov stellt Protocol-Upgrade Aave V3.8 vor
Wichtige Erkenntnisse
- •Aave-Gründer Stani Kulechov hat V3.8, die neueste inkrementelle Version der V3-Architektur des Kreditprotokolls, in einem Beitrag auf X öffentlich vorgestellt.
- •Es wurden keine technischen Spezifikationen, Governance-Vorschläge oder Deployment-Zeitpläne für V3.8 veröffentlicht; das Upgrade befindet sich daher im Offenlegungs- und nicht im Deployment-Stadium.
- •Aave V3 ist auf mehr als einem Dutzend Netzwerke bereitgestellt, darunter eine kürzliche Erweiterung auf BNB Chain; ein V3.8-Rollout dürfte daher eine separate Governance-Zustimmung und Bereitstellung auf jeder Chain erfordern.
- •Frühere V3-Iterationen passten Mechanismen wie Isolation Mode, Efficiency Mode, Supply- und Borrow-Caps, Zinsstrategien und Liquidation Thresholds an; welche Module V3.8 konkret betrifft, bleibt unbestätigt.
- •Aktive Kreditgeber und Kreditnehmer könnten ihre Sicherheitenstrategien überprüfen müssen, falls V3.8 überarbeitete Risikoparameter, Anforderungen zur Positionsübertragung oder aktualisierte Genehmigungsabläufe einführt.

Aave-Gründer Stani Kulechov hat Aave V3.8 vorgestellt, die neueste inkrementelle Version der V3-Architektur des Kreditprotokolls. Aave ist ein dezentrales, nicht-verwahrendes Kreditprotokoll – eines der größten im Bereich der dezentralen Finanzen –, bei dem Nutzer digitale Vermögenswerte einbringen, um Renditen zu erzielen, und gegen Sicherheiten Kredite aufnehmen. Die Ankündigung, die in einem Beitrag auf X erfolgte, signalisiert, dass die Entwicklung der V3-Codebasis fortgesetzt wird, obwohl die vollständigen technischen Spezifikationen, Governance-Vorschläge und Deployment-Zeitpläne noch nicht veröffentlicht wurden.
Was die Vorstellung von V3.8 bedeutet
Kulechovs Beitrag auf X markiert die erste öffentliche Nennung des Versionslabels V3.8. Die V3-Serie von Aave dient als architektonische Grundlage des Protokolls über seine Multi-Chain-Deployments hinweg, und jedes kleinere Versionsinkrement innerhalb dieser Serie hat historisch gesehen bestimmte Risikoparameter, Effizienzeinstellungen oder Feature-Module adressiert. Für V3.8 sind diese Details in der verfügbaren Dokumentation noch nicht bestätigt, und das Versionslabel allein lässt keinen Rückschluss auf den Umfang zu.
Der Schritt von V3.x auf V3.8 ordnet die Veröffentlichung als iteratives Upgrade ein und nicht als vollständige architektonische Neuentwicklung. Aave hat V3 zuvor auf mehr als einem Dutzend Netzwerke bereitgestellt, und inkrementelle Versionen haben Mechanismen wie den Isolation Mode, den Efficiency Mode (eMode) sowie Supply- und Borrow-Caps auf Pool-Ebene angepasst. Ob V3.8 speziell eines dieser Systeme betrifft, ist aus den offiziellen Release Notes nicht ersichtlich.
Aaves Multi-Chain-Präsenz, die kürzlich auf BNB Chain erweitert wurde, bedeutet, dass jedes V3.8-Upgrade wahrscheinlich eine separate Bereitstellung und Governance-Zustimmung in jedem Netzwerk erfordern wird – statt eines einzigen koordinierten Rollouts, eine Einschränkung, die für Multi-Chain-DeFi-Protokolle typisch ist. Da die Genehmigungen netzwerkspezifisch sind, gelten Parameteränderungen in einem Deployment nicht automatisch für andere, und Liquiditätsanbieter sowie Kreditnehmer auf jeder Chain müssen die jeweiligen chainspezifischen Governance-Vorschläge verfolgen, sobald diese entstehen.
Was V3. für Nutzer des Protokolls ändern könnte
Mögliche Änderungen auf Produktebene
Ohne veröffentlichte technische Dokumentation lässt sich nicht bestätigen, welche Aave-Module V3.8 betrifft. Frühere V3-Iterationen haben die Zinsstrategie, Oracle-Konfigurationen und die Parameter für Flash Loans und Liquidation Thresholds angepasst. Derartige Änderungen in V3.8 würden die Kreditkosten, die Effizienz der Sicherheiten und das Liquidationsrisikoprofil bestehender Positionen beeinflussen, doch diese Details müssen aus offiziellen Aave Improvement Proposals stammen und nicht allein aus dem Versionslabel.
Governance und Rollout
Die Governance von Aave funktioniert über On-Chain-Abstimmungen, bei denen AAVE- und stkAAVE-Inhaber Vorschläge genehmigen oder ablehnen. Ein Protocol-Upgrade im Umfang von V3.8 würde typischerweise einen formalen Aave Request for Comment im Governance-Forum erfordern, gefolgt von einem On-Chain-Snapshot und anschließend einem ausführbaren Vorschlag. Keiner dieser Schritte wurde auf Basis der zum Zeitpunkt der Veröffentlichung verfügbaren Informationen als abgeschlossen oder geplant bestätigt, sodass sich V3.8 im Offenlegungsstadium und nicht im Deployment-Stadium befindet.
Die kürzliche Integration der Aave-Unterstützung in die MetaMask Agent Wallet über MCP, einen offenen Standard, der es KI-Agenten ermöglicht, sich mit externen Diensten zu verbinden, veranschaulicht, wie Governance-Aktionen des Protokolls nachgelagerte Auswirkungen auf Integrationen Dritter haben – womit der Governance-Zeitplan für V3.8 auch über den Kreis der Kern-Nutzer von Aave hinaus relevant ist.
Auswirkungen für Nutzer
Für aktive Kreditgeber und Kreditnehmer stellt sich die praktische Frage, ob V3.8 Änderungen mit sich bringt, die eine Positionsübertragung, aktualisierte Genehmigungsabläufe oder überarbeitete Risikoparameter bei bestehenden Sicherheitenarten erfordern. V3-Upgrades, die eMode-Kategorien oder Supply Caps anpassten, haben historisch dazu geführt, dass Nutzer ihre Sicherheitenstrategien überprüfen mussten. Bis offizielle Migrationshinweise veröffentlicht werden, sollten bestehende Positionen im Hinblick auf etwaige Parameteränderungen überwacht werden, die mit der endgültigen Bereitstellung einhergehen.
Was bei V3.8 zu beobachten ist
Das Aave-Governance-Forum ist die zentrale Anlaufstelle, über die die technischen Spezifikationen für V3.8 vor einer On-Chain-Abstimmung veröffentlicht werden. Ein Governance-Vorschlag, falls erforderlich, würde die genauen Vertragsänderungen, Auditor-Freigaben und den Aktivierungszeitplan im Detail darlegen. Leser sollten die Vorstellung durch den Gründer als den Beginn des Offenlegungsprozesses und nicht als Bestätigung der Deploy-Bereitschaft betrachten.
Der Zeitpunkt der Bereitstellung und die Reihenfolge der Netzwerke sind ebenfalls unbestätigt. Aave hat Rollouts zuvor gestaffelt, indem Upgrades zunächst auf Märkten miteringerer Liquidität vor dem Ethereum-Mainnet bereitgestellt wurden, um der Community Zeit zu geben, das Verhalten unter Live-Bedingungen zu beobachten. Ob V3.8 diesem Muster folgt, hängt von seinem Umfang ab, der weiterhin unveröffentlicht ist. Das Protocol-TVL und die Verteilung der Liquidität über die Chains lassen sich in Echtzeit über DeFiLlamas Aave-Protokollseite verfolgen, die etwaige Kapitalbewegungen im Anschluss an ein Deployment widerspiegeln wird.
Smart-Contract-Risiken sind die grundsätzliche Überlegung bei jedem Aave-Upgrade. Die Aave-Codebasis durchläuft vor größeren Deployments formale Audits, und das Bug-Bounty-Programm der Community ist weiterhin aktiv. Bis die Auditberichte für V3.8 veröffentlicht sind, gilt die übliche Vorsicht beim Umgang mit neu bereitgestellten Vertragsversionen. Governance-Teilnehmer sollten außerdem prüfen, ob V3.8 mit der GHO-Stablecoin-Infrastruktur oder dem Aave Safety Module interagiert, das durch gestaktes AAVE abgesichert ist – beide bringen eigene Risikoflächen mit sich. Token-Fundamentaldaten, einschließlich Marktpreis und Handelsvolumen, lassen sich über CoinGeckos AAVE-Token-Seite verfolgen, während sich die Governance-Entwicklungen entfalten.
Weitere Details werden voraussichtlich über Aaves offizielle Governance- und Kommunikationskanäle bekannt gegeben.