--- title: "ERC-4626-Inflationsangriff bei der ersten Einzahlung: Wie Rundung Anteile auslöschen kann" description: "Erfahren Sie, wie eine direkte Spende den Wechselkurs eines leeren ERC-4626-Vaults manipuliert, die Anteile eines Einzahlers auf null abrundet und wie Implementierungen und Nutzer das Risiko begrenzen können." image: "https://wiki.fcontext.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt > Use this file to discover all available pages before exploring further. # ERC-4626-Inflationsangriff bei der ersten Einzahlung: Wie Rundung Anteile auslöschen kann > Nur zu Bildungszwecken; dies ist keine Anlageberatung. Investitionen können zu Verlusten führen. ## Direkte Antwort Ein Inflationsangriff bei der ersten Einzahlung zielt auf einen leeren oder nahezu leeren ERC-4626-Vault. Der Angreifer zahlt einen winzigen Betrag ein, um die ersten Anteile zu erhalten, und überträgt anschließend die zugrunde liegenden Vermögenswerte direkt an den Vault. Diese Spende erhöht `totalAssets()`, ohne `totalSupply()` zu erhöhen, und macht jeden vorhandenen Anteil wertvoller. Wird die Einzahlung des Opfers zu diesem manipulierten Wechselkurs umgerechnet, kann die Ganzzahldivision das Ergebnis auf sehr wenige oder null Anteile abrunden. Die Vermögenswerte des Opfers bleiben im Vault, während der Angreifer als Inhaber der ausstehenden Anteile den aufgeblähten Anspruch einlösen kann. Das ist ein Problem der Wechselkursmanipulation und des Slippage, kein Fehler der ERC-4626-Schnittstelle selbst. ## Funktionsweise In einem einfachen Vault ohne Gebühren oder schützende Offsets entsprechen die für eine Einzahlung geprägten Anteile ungefähr `assets * totalSupply / totalAssets`. ERC-4626 verlangt, dass die Anteilberechnung für einen bestimmten Vermögenswertbetrag zugunsten des Vaults abgerundet wird. Bei normalen Wechselkursen ist der Rundungsverlust gering; wird der Anteilspreis jedoch aufgebläht, kann eine Einzahlung im Wert von weniger als einem Anteil durch Rundung 100% verlieren. Der Angriff hängt von den Implementierungsdetails ab. Eine direkte ERC-20-Übertragung kann die verbuchten Vermögenswerte des Vaults erhöhen, ohne Anteile zu prägen, insbesondere wenn `totalAssets()` den Tokenbestand des Vaults liest. Der Angreifer muss außerdem vor dem Opfer handeln, solange das Angebot an Anteilen sehr klein ist. Vaults mit einer anderen Buchführung oder ausdrücklichen Schutzmaßnahmen sind möglicherweise nicht auf dieselbe Weise anfällig. ## Beispiel Nehmen wir an, ein anfälliger leerer Vault startet mit einem Kurs von 1:1. Der Angreifer zahlt 1 Vermögenseinheit ein und erhält 1 Anteil, anschließend spendet er direkt 999 Einheiten. Nun liegen im Vault 1,000 Vermögenseinheiten als Deckung für 1 Anteil. Das Opfer zahlt 999 Einheiten ein; die einfache Rechnung lautet nach Ganzzahldivision `999 * 1 / 1,000 = 0` Anteile. Danach hält der Vault 1,999 Vermögenseinheiten, während nur der 1 Anteil des Angreifers existiert. Erlaubt die Einzahlung ein Ergebnis von null Anteilen und gibt es keine Gebühren oder anderen Einschränkungen, kann der Angreifer diesen Anteil gegen alle 1,999 Einheiten einlösen: die ursprüngliche Einzahlung von 1 Einheit, die Spende von 999 Einheiten und die Einzahlung des Opfers von 999 Einheiten. Der Bruttogewinn des Angreifers entspricht vor Transaktionskosten den 999 Einheiten des Opfers. ## Risiken und Schutzmaßnahmen Implementierer können das Risiko durch eine angemessene anfängliche Liquidität, das Verbrennen oder Sperren anfänglicher Anteile, eine erzwungene Mindestanzahl von mindestens einem ausgegebenen Anteil oder ein Wechselkursdesign mit virtuellen Vermögenswerten und virtuellen Anteilen verringern. Die OpenZeppelin-Implementierung fügt virtuelle Beträge hinzu und unterstützt über einen Dezimalstellen-Offset eine höhere Anteilspräzision; im dokumentierten Modell vereinnahmen die virtuellen Anteile einen Teil jeder Spende, sodass Manipulationen unrentabel oder deutlich teurer werden. Jede Schutzmaßnahme beruht auf Annahmen und sollte gegen Direktübertragungen, Rundungsgrenzen, Gebühren, Verluste und ungewöhnliches Tokenverhalten getestet werden. Nutzer und Integratoren sollten `previewDeposit()` als Kursnotierung behandeln, nicht als garantiertes Minimum. Einzahlungen sollten über eine Funktion oder einen Router erfolgen, der eine minimal akzeptable Anzahl von Anteilen erzwingt und die Transaktion zurücksetzt, wenn diese Grenze verfehlt wird. Vor einer Einzahlung in einen neuen oder dünn besicherten Vault sollten `totalAssets()`, `totalSupply()`, die Umrechnungsformel der Implementierung und der Einfluss unerwarteter Tokenübertragungen auf die Buchführung geprüft werden. Ein günstiges Frontend-Angebot schützt keine Transaktion, deren Ausführungsreihenfolge verändert werden kann. ## Häufige Irrtümer - **Mythos 1: ERC-4626 selbst garantiert einen sicheren Wechselkurs.** Der Standard definiert eine gemeinsame Schnittstelle und ein Rundungsverhalten, macht aber nicht jede Implementierung immun gegen Wechselkursmanipulation. - **Mythos 2: Ein Aufruf von `previewDeposit()` unmittelbar vor `deposit()` garantiert dieses Ergebnis.** Der On-Chain-Zustand kann sich zwischen den Aufrufen oder vor der Ausführung ändern. Der Einzahlungspfad benötigt eine erzwingbare Mindestgrenze für Anteile. - **Mythos 3: Die Ablehnung von Einzahlungen mit null Anteilen beseitigt den Angriff.** Sie verhindert das extremste Ergebnis, doch ein Angreifer kann weiterhin eine Einzahlung auf wenige Anteile begrenzen und einen großen Rundungsverlust verursachen. Schutzmaßnahmen sollten die zulässige Slippage begrenzen und nicht nur ein Ergebnis ungleich null verlangen. ## Verwandte Themen - [ERC-4626-Vault-Standard](/de/crypto/erc4626-vault/) - [Betrugsnachweis](/de/crypto/fraud-proof/) - [Übernahme des Initializers eines aktualisierbaren Vertrags](/de/crypto/initializer-takeover/) - [Smart Contract](/de/crypto/smart-contract/) - [Transaktionssimulation](/de/crypto/transaction-simulation/) ## Quellen - [ERC-4626: Tokenisierte Vaults](https://eips.ethereum.org/EIPS/eip-4626) - Ethereum Improvement Proposals (abgerufen am: 2026-08-20) - [ERC-4626-Standard für tokenisierte Vaults](https://docs.openzeppelin.com/contracts/4.x/erc4626) - OpenZeppelin (abgerufen am: 2026-08-20) - [OpenZeppelin-Implementierung von ERC4626](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/extensions/ERC4626.sol) - OpenZeppelin (abgerufen am: 2026-08-20) Source: https://wiki.fcontext.com/de/crypto/erc4626-inflation-attack/index.mdx