---
title: "RPC für private Transaktionen"
description: "Ein RPC für private Transaktionen leitet eine signierte Transaktion oder ein Bundle vor der Verbreitung im öffentlichen Mempool an eine begrenzte Gruppe von Providern, Relays oder Buildern weiter; er ändert die anfängliche Offenlegung, nicht die Garantien für Gültigkeit, Aufnahme, Preis oder Finalität."
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.
# RPC für private Transaktionen
> Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.
## Direkte Antwort
Ein RPC für private Transaktionen sendet eine signierte Transaktion oder ein geordnetes Bundle über einen begrenzten Dienstpfad, bevor sie im öffentlichen Mempool verbreitet wird. Dieser Pfad kann einen RPC-Provider, ein Relay, ausgewählte Builder und bei offengelegten Hinweisen auch Searcher umfassen. „Privat“ beschreibt somit die anfängliche Verteilung, nicht Verschlüsselung, Anonymität oder Unsichtbarkeit für Intermediäre.
Der Dienst kann die Gefahr von Kopien, Frontrunning oder Sandwich-Angriffen aus dem öffentlichen Mempool verringern, garantiert aber weder Aufnahme noch EVM-Erfolg, bestmögliche Ausführung, MEV-Rückerstattung oder Finalität. Eine Provider-Bestätigung oder ein zurückgegebener Transaktions-Hash belegt nur, dass die Anfrage diese Schnittstelle erreicht hat. Verteilung an Builder, Auswahl des Payloads, Blockaufnahme, `status` des Belegs, Zugehörigkeit zur kanonischen Kette und Finalität sind getrennte Zustände.
Private Methoden sind nicht austauschbar. Eine einzelne `eth_sendPrivateTransaction`, ein älteres `eth_sendBundle` und ein `mev_sendBundle` können sich bei Zielblöcken, geordneten Inhalten, zulässigen Reverts, Ersetzung oder Stornierung, Builder-Auswahl, Privacy Hints und Erstattungsregeln unterscheiden. Entscheidend sind die exakte Chain, der Endpoint, die API-Version und der signierte Payload.
## Funktionsweise
Die Wallet erstellt und signiert zunächst eine gewöhnliche Chain-Transaktion mit Chain-ID, Nonce, Ziel, Wert, Calldata, Gaslimit und EIP-1559-Gebührenobergrenzen. Privates Routing ändert nur den Einreichungsort dieser signierten Bytes; Nonce-Reihenfolge, Saldo- und Allowance-Prüfungen, Vertragsausführung, Base-Fee-Regeln und Konsensvalidierung bleiben bestehen. Dieselben signierten Bytes ergeben beim erneuten Senden denselben Hash; eine Ersetzung mit derselben Nonce, aber anderen Gebühren oder Calldata, hat einen anderen Hash.
Der Provider kann den Payload gegen einen bezeichneten Zustand simulieren und an einen oder mehrere Builder verteilen. Die Simulation gilt nur für diesen Zustand: Salden, Storage, Orakelwerte, konkurrierende Transaktionen und Base Fee können sich vor der Blockerstellung ändern. Ein Builder kann eine gültige Transaktion auslassen, weil sie zu spät kam, zu wenig zahlte, gegen einen wertvolleren Block verlor oder den vom Proposer gewählten Builder nie erreichte.
Bundles ergänzen eine geordnete Ausführungsregel. Ein erforderlicher Revert kann ein Bundle unzulässig machen; ein ausdrücklich erlaubter Revert kann Gas verbrauchen und frühere erfolgreiche Zustandsänderungen des Bundles bestehen lassen. Das ist kein automatischer vollständiger Rollback. Privacy Hints können Transaktions-Hash, Vertragsadresse, Funktionsselektor, Calldata oder Logs offenlegen; ein schneller Modus oder breiter Builder-Fanout erhöht Reichweite sowie meist den Vertrauens- und Offenlegungskreis.
Nonce- und Timeout-Verwaltung benötigen eine ausdrückliche Zustandsmaschine. Eine private Pending-Transaktion kann in der gewöhnlichen Pending-Sicht eines öffentlichen RPC fehlen und spätere Nonces blockieren. Eine Provider-Stornierung beendet nur künftige Übermittlungen auf kontrollierten Pfaden; bereits geteilte, öffentlich gesendete oder aufgenommene Kopien werden nicht zurückgerufen. Eine Same-Nonce-Ersetzung oder ein öffentlicher Fallback konkurriert mit allen verbleibenden Versionen und legt den Orderflow wieder öffentlich offen.
Gehen Sie wie folgt vor:
1. Chain-ID, Provider und API-Version festlegen; Methode für Einzeltransaktion oder Bundle wählen und Logging, Verteilung an Builder oder Searcher, Privacy Hints, Reverts, Erstattung und öffentlichen Fallback dokumentieren.
2. Exakte unsignierte Absicht und signierten Payload dekodieren: Absender, Nonce, Ziel, Wert, Calldata, Allowances, Gaslimit, Gebührenobergrenzen, Deadline, Mindestausgabe, Zielblockbereich und jedes geordnete Bundle-Element.
3. Gegen einen identifizierten Block und Zustand simulieren; Erfolg, Revert, Zustandsänderung, Slippage, Saldoänderungen, zulässige Fehler, Gesamtgas und das schlechteste wirtschaftlich gültige Ergebnis testen.
4. Über den vorgesehenen Endpoint einreichen und Transaktions- oder Bundle-Hash, Request-ID, Authentifizierungsidentität, Zeitstempel, Ziel- oder Maximalblock, Builder, Hints und Original-Payload aufbewahren.
5. Provider-Bestätigung, Simulation, Builder-Verteilung, private Nonce und Ablauf getrennt vom kanonischen Beleg überwachen; Zielblock- und Gebührenannahmen vor erneutem Senden aktualisieren.
6. Zur Deadline ausdrücklich warten, stornieren, mit derselben Nonce ersetzen oder über einen öffentlichen Fallback offenlegen; nie annehmen, dass eine Stornierung Kopien zurückruft, und konkurrierende Versionen nur mit Race-Überwachung senden.
7. Auf der richtigen Chain `status` des Belegs, Logs, Salden, Ausgabe, effektiven Gaspreis und Erstattung abstimmen; danach den benötigten Zustand `safe` oder `finalized` abwarten und Reorgs, Lecks oder unerklärte Ausführungsabweichungen untersuchen.
## Beispiele
- **Ausgabeschutz ist keine bestmögliche Ausführung.** Ein Swap nennt `100,000 USDC` Eingabe und `98,800 USDC` Mindestausgabe. Die öffentliche Ausführung liefert `98,950 USDC`, also `1,050 USDC` oder `1.05%` unter Parität, aber nur `150 USDC` über dem Minimum. Privates Routing kann Beobachtung verringern, garantiert aber keine bessere Ausgabe als ein anderer öffentlicher Handelsplatz oder RFQ.
- **EIP-1559-Aufnahmegrenze.** Eine Transaktion nutzt `180,000 gas`; die Base Fee beträgt `30 gwei`, die Priority-Obergrenze `2 gwei` und die maximale Gebühr `40 gwei`. Der effektive Preis ist `min(40, 30 + 2) = 32 gwei`, die Gebühr somit `180,000 x 32 = 5,760,000 gwei = 0.005760 ETH`. Beträgt die Base Fee eines Kandidatenblocks `42 gwei`, deckt die maximale Gebühr von `40 gwei` sie nicht; privates Routing macht die Transaktion dort nicht aufnahmefähig.
- **Same-Nonce-Fallback-Race.** Privater Payload `A` und öffentlicher Fallback `B` verwenden beide Nonce `42`. Es gibt zwei Einreichungen, doch die kanonische Chain kann Nonce `42` nur einmal verbrauchen. Wird `A` in Block `N + 2` aufgenommen, ist `B` veraltet; landet `B` zuerst, ist `A` veraltet. Eine Stornierungsbestätigung ist kein Undo; jede verbleibende Kopie muss überwacht werden.
- **Erlaubter Revert ist kein atomarer Rollback.** In einem geordneten Bundle nutzt die Genehmigung `45,000 gas`, und ein Swap revertiert nach `120,000 gas` bei effektiv `25 gwei`. Ohne Allowed-Revert-Regel wird das Bundle gemäß dieser Regel ausgeschlossen. Ist der Swap-Revert erlaubt und wird das Bundle aufgenommen, kann die Genehmigung bestehen bleiben, der Swap hat `status = 0`, und die Gaskosten betragen `(45,000 + 120,000) x 25 gwei = 0.004125 ETH`.
## Risiken
- Die Wallet verwendet die falsche Chain, den falschen Provider, Endpoint oder die falsche API-Version.
- DNS, TLS, API-Key oder RPC-Schnittstelle werden durch Phishing oder Kompromittierung angegriffen.
- Der Provider verknüpft IP, Konto, Zeitpunkt und signierte Payload-Daten.
- Ein Relay protokolliert, leakt, kopiert oder sendet die vollständige Transaktion erneut.
- Privacy Hints legen Hash, Selektor, Vertrag, Calldata oder Logs offen.
- Schneller Modus oder breiter Builder-Fanout vergrößern Vertrauens- und Offenlegungskreis.
- Ein Builder oder Searcher zensiert, kopiert oder nutzt privaten Orderflow aus.
- Die Simulation verwendet den falschen Block oder veraltet vor der Blockerstellung.
- Vertragszustand, Salden, Preise oder Reihenfolge ändern sich und verursachen einen Revert.
- Base Fee, Maximal- oder Priority-Gebühr machen den Payload unattraktiv oder ungültig.
- Eine Nonce-Lücke oder unsichtbare private Pending-Transaktion blockiert spätere Nonces.
- Stornierung oder Same-Nonce-Ersetzung verliert ein zeitliches Race.
- Ein stiller öffentlicher Fallback stellt die MEV-Exposition des öffentlichen Mempools wieder her.
- Zielblock, Maximalblock, Zeitstempel oder Dienst-TTL werden missverstanden.
- Bundle-Reihenfolge oder Allowed-Revert-Regel hinterlässt eine unbeabsichtigte Zustandsänderung.
- Builder-, Relay- oder Proposer-Abdeckung beziehungsweise Zensur verhindert die Aufnahme.
- Provider-Ausfall, Rate Limiting oder Latenz verpasst das gültige Zeitfenster.
- Privates Routing wird mit Slippage-Schutz oder bestmöglicher Ausführung verwechselt.
- Belegstatus, Logs, Salden, Gebühren oder Erstattungen werden falsch abgestimmt.
- Ein Reorg, eine verfrühte Finalitätsannahme oder eine L2-Sequencer-Grenze kehrt die Schlussfolgerung um.
## Häufige Irrtümer
- **Privat bedeutet verschlüsselt, anonym und unsichtbar.** Provider und ausgewählte nachgelagerte Parteien können den vollständigen Payload oder offengelegte Hints sehen.
- **Ein privater RPC garantiert kein MEV und den besten Preis.** Er ändert die Verteilung; Vertragsgrenzen, Handelsplatzvergleich und Ausführungsqualität bleiben maßgeblich.
- **RPC-Erfolg oder Transaktions-Hash bedeuten Aufnahme, Erfolg und Finalität.** Bestätigung, Beleg, EVM-Status und Finalität sind getrennte Zustände.
- **Stornierung oder Same-Nonce-Ersetzung sind garantiert.** Kopien und konkurrierende Versionen laufen gegeneinander, bis eine aufgenommen wird oder alle ablaufen.
- **Eine private Transaktion ist automatisch ein atomares Bundle.** Einzeltransaktionen und Bundle-Formate haben unterschiedliche Reihenfolge- und Revert-Semantik.
## Verwandte Themen
- [Mempool](/de/crypto/mempool/)
- [Sandwich-Angriff](/de/crypto/sandwich-attack/)
- [Transaktionssimulation](/de/crypto/transaction-simulation/)
## Quellen
- [Settings Guide](https://docs.flashbots.net/flashbots-protect/settings-guide) - Flashbots Docs (abgerufen: 2026-08-13)
- [JSON-RPC Endpoints](https://docs.flashbots.net/flashbots-auction/advanced/rpc-endpoint) - Flashbots Docs (abgerufen: 2026-08-13)
- [Nonce Management](https://docs.flashbots.net/flashbots-protect/nonce-management) - Flashbots Docs (abgerufen: 2026-08-13)
- [Bundle Inclusion Troubleshooting](https://docs.flashbots.net/flashbots-auction/advanced/troubleshooting) - Flashbots Docs (abgerufen: 2026-08-13)
- [Understanding Bundles](https://docs.flashbots.net/flashbots-mev-share/searchers/understanding-bundles) - Flashbots Docs (abgerufen: 2026-08-13)
- [MEV-Boost Block Proposal](https://docs.flashbots.net/flashbots-mev-boost/architecture-overview/block-proposal) - Flashbots Docs (abgerufen: 2026-08-13)
- [Transactions](https://ethereum.org/en/developers/docs/transactions/) - ethereum.org (abgerufen: 2026-08-13)
- [JSON-RPC API](https://ethereum.org/en/developers/docs/apis/json-rpc/) - ethereum.org (abgerufen: 2026-08-13)
Source: https://wiki.fcontext.com/de/crypto/private-transaction-rpc/index.mdx