---
title: "„replacement transaction underpriced“ beheben"
description: "Dieser RPC-Fehler bedeutet, dass eine Transaktion desselben Absenders und Nonce die Gebührenerhöhungsregel des Knotens nicht erfüllt. So prüfen, beschleunigen oder stornieren Sie sie sicher."
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.
# „replacement transaction underpriced“ beheben
> Nur zu Bildungszwecken; keine Finanz- oder Sicherheitsberatung. Eine Ersetzung oder Stornierung kann eine unbeabsichtigte Transaktion ausführen, und Netzwerkgebühren sind unumkehrbar.
## Direkte Antwort
`replacement transaction underpriced` ist eine Ablehnung durch RPC oder Transaktionspool, kein Revert eines EVM-Vertrags. Meist kennt der Knoten bereits eine Transaktion desselben Absenders mit derselben Nonce, aber die neue Transaktion erhöht die maßgeblichen Gebührenfelder nicht genug für seine Ersetzungsrichtlinie.
Prüfen Sie zuerst Chain, Absender, Nonce und Status aller bekannten Hashes. Ist das Original noch ausstehend und soll ersetzt werden, verwenden Sie exakt dieselbe Nonce und erhöhen die Gebühren gemäß Wallet- oder Knotenrichtlinie. Nur `gasLimit` zu erhöhen, Slippage zu ändern oder dieselbe signierte Transaktion erneut zu senden erfüllt die Regel nicht.
## Funktionsweise
1. **Die Nonce kennzeichnet die Position.** Transaktionen eines externen Kontos nutzen fortlaufende Nonces. Kennt ein Knoten bereits eine Transaktion dieses Absenders und dieser Nonce, gilt eine weitere an derselben Position als Ersatzkandidat. Spätere Nonces können warten, bis frühere einbezogen oder anders gelöst sind.
2. **Ersetzung ist lokale Pool-Richtlinie.** Ethereum-Konsens schreibt keinen einheitlichen Prozentsatz vor. Clients, RPC-Anbieter und private Relays können andere Regeln oder andere ausstehende Transaktionen kennen. Geths Legacy Pool nutzt derzeit standardmäßig `10%`; Betreiber können dies ändern und andere Clients müssen nicht übereinstimmen.
3. **EIP-1559 hat zwei Ausführungsobergrenzen.** `maxPriorityFeePerGas` begrenzt das Trinkgeld und `maxFeePerGas` den Gesamtpreis je Gas inklusive Basisgebühr. In Geths Legacy Pool müssen neuer Fee Cap und Tip Cap alte Werte und konfigurierte Prozentschwellen übersteigen. Das Wallet sollte beide berechnen.
4. **Pool-Annahme ist keine Bestätigung.** Ein Knoten kann den Ersatz annehmen, während andere das Original behalten. Nur eine Transaktion dieses Absenders und dieser Nonce kann in die kanonische Kontosequenz gelangen. Der zuerst aufgenommene gültige Kandidat macht andere auf dieser Chain unbrauchbar; Anzeigen können später aktualisieren.
5. **Obergrenze und Zahlung sind verschieden.** Der effektive EIP-1559-Gaspreis ist durch den Fee Cap begrenzt; ungenutztes Gas wird nicht berechnet. Ein höheres `maxFeePerGas` erhöht das Maximalrisiko, nicht zwingend den Endpreis, kann aber bei entsprechender Basisgebühr und Tip tatsächlich ausgeschöpft werden.
## Lösungsablauf und Beispiel
Angenommen, die ausstehende Transaktion hat Nonce `42`, `maxFeePerGas = 30 gwei` und `maxPriorityFeePerGas = 2 gwei`. Ein Knoten mit `10%` Mindestaufschlag kann `31 gwei` und `2.1 gwei` ablehnen; `35 gwei` und `2.5 gwei` überschreiten diese Beispielschwellen. Sie kann dennoch warten, wenn die aktuelle Basisgebühr unter dem Fee Cap von `35 gwei` zu wenig effektiven Tip lässt. Der Prozentsatz ist kein netzweites Versprechen.
Gehen Sie so vor:
1. Prüfen Sie Netzwerk und Absender. Fragen Sie Original- und Ersatz-Hashes über Wallet und einen unabhängigen RPC oder Explorer ab.
2. Vergleichen Sie bestätigten Transaktionszähler und Pending-Ansicht. Ist Nonce `42` bestätigt, erstellen Sie keine weitere Transaktion unter der Annahme, sie sei noch offen.
3. Dekodieren Sie `to`, `value` und `data`. Beim Beschleunigen bleiben Vorgang und Nonce gleich. Zum Stornieren senden Wallets oft `0 ETH` mit derselben Nonce an den Absender selbst; das ist konkurrierender Ersatz, kein Protokoll-Widerruf.
4. Nutzen Sie möglichst die Wallet-Funktion. Sonst ermitteln Sie aktuelle Richtlinie und Gebühren, erhöhen beide EIP-1559-Caps mit Rundungsspielraum und prüfen die Deckung von `value + gasLimit x maxFeePerGas`.
5. Prüfen Sie alles vor dem Signieren. Senden Sie einmal, behalten Sie alle Hashes und beobachten Sie alle Belege. Ein Pending-Hash hat keinen Beleg; ein Beleg auf richtiger Chain und richtigem Block ist der Ausführungsnachweis.
## Risiken
- Stornierung ist nicht garantiert. Das Original kann vorher aufgenommen werden; private oder schlecht verbreitete Transaktionen können für Ihren RPC unsichtbar sein.
- Eine falsche Nonce kann eine neue Zahlung oder einen neuen Aufruf erzeugen. Veraltete Calldata können eine Aktion mit verändertem Preis, Allowance, Ablauf oder Protokollstatus ausführen.
- Ein Endpoint kann den Ersatz annehmen, ein anderer ablehnen. Häufige RPC-Wechsel können Kandidaten in verschiedenen Pools und verwirrende Wallet-Anzeigen hinterlassen.
- Ein höheres `gasLimit` erhöht nicht die Priorität. Blinde Fee-Cap-Erhöhungen schaffen unnötige Maximalkosten; Slippage- oder Calldata-Änderungen ändern die Ausführung, nicht die Pool-Regel.
- Blob-Transaktionen, Account-Abstraction User Operations, L2 und private Relays können andere Pools und Regeln verwenden. Geths normale EVM-Richtlinie gilt nicht automatisch.
Stoppen Sie, wenn Absender oder Nonce unbekannt sind, Calldata nicht dekodierbar sind, die Transaktion bestätigt sein könnte, das Wallet anderen Empfänger oder Betrag vorschlägt oder ein RPC Seed-Phrase oder Private Key verlangt. Seriöse Fehlersuche erfordert nie geheime Wiederherstellungsdaten.
## Häufige Irrtümer
- **„Das Konto hat zu wenig Guthaben.“** Das ist ein anderer Fehler. Diese Meldung betrifft den konkurrierenden Kandidaten und dessen Ersatzpreis.
- **„10% mehr funktioniert immer.“** Das ist ein verbreiteter Geth-Standard, keine Konsensregel. Konfiguration, Client, Typ und Rundung können mehr erfordern.
- **„Die teurere Transaktion hat das Original überall ersetzt.“** Pools sind lokal. Annahme durch einen RPC löscht das Original nicht überall und garantiert keine Reihenfolge.
- **„Stornieren macht eine bestätigte Transaktion rückgängig.“** Nein. Es konkurriert nur bei ungelöster Nonce; bestätigte Änderungen brauchen, falls vorhanden, eine Lösung auf Anwendungsebene.
## Verwandte Themen
- [Gasgebühr](/de/crypto/gas-fee/)
- [EIP-1559-Basisgebühr](/de/crypto/eip1559-base-fee/)
- [Transaktionsersetzung](/de/crypto/mempool-replacement/)
- [Nonce](/de/crypto/nonce-crypto/)
- [Prioritätsgebühr](/de/crypto/priority-fee/)
## Quellen
- [Transaktionen](https://ethereum.org/developers/docs/transactions/) - ethereum.org (abgerufen: 2026-08-21)
- [EIP-1559: Änderung des Gebührenmarkts der ETH-1.0-Chain](https://eips.ethereum.org/EIPS/eip-1559) - Ethereum Improvement Proposals (abgerufen: 2026-08-21)
- [Ersetzungslogik des go-ethereum Legacy Pools](https://github.com/ethereum/go-ethereum/blob/master/core/txpool/legacypool/list.go) - go-ethereum (abgerufen: 2026-08-21)
- [txpool-Namespace](https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-txpool) - go-ethereum (abgerufen: 2026-08-21)
Source: https://wiki.fcontext.com/de/crypto/replacement-transaction-underpriced/index.mdx