--- title: "Post-only-Order" description: "Eine Post-only-Order ist eine handelsplatzspezifische Limitorder-Anweisung, die Liquiditaet einstellen statt sofort entnehmen soll; Ablehnung, Stornierung, Preisanpassung, Warteschlangenprioritaet und Gebuehren richten sich nach den konkreten Matching-Regeln." 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. # Post-only-Order > Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen. ## Direkte Antwort Eine Post-only- oder Add-liquidity-only-Anweisung wird einer Limitorder hinzugefuegt und geprueft, sobald diese die Matching Engine erreicht. Wuerde ein Teil sofort gegen ruhende Liquiditaet ausgefuehrt, wendet der Handelsplatz seine eigene Regel an: Er kann die Anfrage ablehnen, die Order annehmen und stornieren oder ihren Preis auf ein nicht sofort ausfuehrbares Niveau verschieben. Post-only bezeichnet daher eine Eintrittsbedingung, keinen universellen Ordertyp mit einheitlichem Ergebnis. Eine erfolgreich ins Orderbuch eingestellte Order kann spaeter handeln, sobald eine Gegenorder eintrifft. Diese Ausfuehrung wird ueblicherweise als Maker-Liquiditaet eingestuft; massgeblich sind jedoch der tatsaechliche Ausfuehrungsdatensatz und die Gebuehrenbuchung. Weder eine Empfangsbestaetigung noch der Status `open` oder das Post-only-Flag garantieren allein Ausfuehrung, Maker-Behandlung, Rabatt oder ein besseres Nettoergebnis. ## Funktionsweise Die sofortige Ausfuehrbarkeit wird anhand des Engine-Zustands beurteilt, nicht anhand einer veralteten Anzeige. Ein Kauflimit auf oder ueber dem besten Ask und ein Verkaufslimit auf oder unter dem besten Bid kreuzen normalerweise das Orderbuch. Tick-Rundung, Auktionen, gesperrte oder gekreuzte Buecher, verdeckte Liquiditaet, Preisschutz und Self-Trade Prevention koennen das Ergebnis aendern. Automatische Preisanpassung veraendert zudem das angeforderte Limit und die Warteschlangenposition und muss deshalb eine ausdruecklich akzeptierte Handelsplatzregel sein. Post-only ist von anderen Anweisungen unabhaengig. `GTC`, `GTD`, `IOC` und `FOK` bestimmen die Gueltigkeitsdauer; manche Handelsplaetze lehnen Post-only zusammen mit Sofortausfuehrungsanweisungen ab. `reduce-only`, Close-only und Positionsseitenfelder steuern das Exposure. Eine Stop- oder Take-Profit-Order gelangt gegebenenfalls erst nach Ausloesung ins Orderbuch; die daraus erzeugte Order wird dann nach den aktuellen Post-only-Regeln des Handelsplatzes geprueft. Auch Warteschlangen- und Lebenszyklusregeln sind spezifisch. Preis-Zeit-Prioritaet ist ueblich, aber nicht universell. Eine Preisaenderung, Mengenerhoehung oder Cancel-and-replace verliert oft Prioritaet; eine unterstuetzte Mengenreduzierung kann sie behalten. Self-Trade Prevention kann die eingehende Order, die ruhende Order oder beide stornieren oder reduzieren. Nur geordnete oeffentliche und private Ereignisse belegen den tatsaechlichen Ablauf. Verwenden Sie diesen Ablauf: 1. Legen Sie Handelsplatz, Rechtstraeger, Produkt, Sitzung und API-Version fest; erfassen Sie Tick, Los, Mindestnominal, Gebuehrenstufe und ob ausfuehrbare Post-only-Orders abgelehnt, storniert oder preislich angepasst werden. 2. Erfassen Sie Best Bid, Best Ask und Markttiefe mit Zeitstempel und konsistenter Sequenz; bestimmen Sie Seite, Limit, Menge, Gueltigkeit, Positionsmodus, Post-only, Reduce-only, Self-Trade Prevention und Triggerfelder. 3. Runden Sie Preis und Menge exakt und pruefen Sie Kreuzung, Preisbaender, Guthaben, Margin, Orderlimits und inkompatible Modi vorab; massgeblich bleibt der Zustand bei Ankunft in der Engine. 4. Senden Sie mit eindeutiger Client-Order-ID; trennen Sie Transporterfolg von angenommenem, ruhendem oder terminalem Status und protokollieren Sie Server-Order-ID, Zeitstempel und vollstaendige Antwort. 5. Verarbeiten Sie geordnete Order- und Fill-Ereignisse; stimmen Sie kumulierte Ausfuehrung, Restmenge, Fill-ID, Preis, Nominal, Liquiditaetskennzeichen, Gebuehren- oder Rabattwaehrung und jede warteschlangenwirksame Aenderung ab. 6. Behandeln Sie Aendern, Stornieren und Ersetzen bis zu terminalen Ereignissen als Rennen; wiederholen Sie nach Timeouts idempotent und synchronisieren Sie nach doppelten, fehlenden oder ungeordneten Nachrichten neu. 7. Stimmen Sie ausgefuehrte, stornierte, abgelehnte oder verfallene Mengen mit Bestand, Reservierungen und Salden ab; bewerten Sie tatsaechliche Gebuehren, Rabatte, adverse Selektion und verpasste Ausfuehrungen. Pruefen Sie bei einem Onchain-Handelsplatz zusaetzlich Inklusion, Protokollausfuehrung und erforderliche Finalitaet. ## Beispiele - **Kreuzungsverhalten.** Best Bid und Ask stehen bei `99.90 / 100.00`, der Tick betraegt `0.01`. Ein Post-only-Kauf ueber `2 BTC at 100.00` wuerde sofort auf den Ask treffen. Ein Reject-Handelsplatz lehnt die Anfrage ab; ein Cancel-Handelsplatz verbucht keine Ausfuehrung und storniert sie. Ein Reprice-Handelsplatz koennte sie auf `99.99` verschieben, jedoch nur bei angeforderter dokumentierter Regel. Ein Kauf zu `99.99` kann ruhen, wenn sich der Engine-Zustand nicht aendert; eine Ausfuehrung ist nicht garantiert. - **Ruhende Maker-Ausfuehrung und Gebuehren.** Ein Verkauf ueber `3 ETH at 99.90` ruht bei Bid und Ask von `99.80 / 100.00`; danach fuehrt ihn ein aggressiver Kauf aus. Das Nominal betraegt `3 x 99.90 = 299.70`. Bei einem Maker-Satz von `-1 bp` ist die Gebuehr `299.70 x -0.0001 = -0.02997`, also ein Rabatt. Eine falsche Einstufung zum Taker-Satz von `5 bp` ergibt eine Belastung von `0.14985`, eine Differenz von `0.17982`. Verwenden Sie das tatsaechliche Liquiditaetskennzeichen und die Gebuehrenbuchung. - **Teilausfuehrung und Stornierungsrennen.** Eine ruhende Post-only-Verkaufsorder lautet `10 units at 100`. Davon werden `4` ausgefuehrt, dann sendet der Client die Stornierung. Vor der terminalen Stornierung wird eine weitere `1` ausgefuehrt, sodass `5` storniert werden. Insgesamt wurden `5` statt `4` ausgefuehrt; das Ausfuehrungsnominal ist `500`, und ein Rabatt von `2 bp` betraegt `0.10`. Eine Stornierungsbestaetigung ist nicht der terminale Bestandsdatensatz. - **Niedrigere Gebuehren koennen dennoch mehr kosten.** Ein sofortiger Kauf von `10` zu `100.00` bei `8 bp` Taker-Gebuehr kostet `1,000.80`. Wird dieser Preis verpasst und die Order spaeter zu `100.20` bei `2 bp` Maker-Gebuehr eingestellt, kostet sie `1,002.2004`. Der Maker-Weg spart `0.5996` Gebuehren, kostet insgesamt aber `1.4004` mehr. Post-only steuert das Ausfuehrungsverhalten; es optimiert nicht automatisch den gesamten Handel. ## Risiken - Es wird die Post-only-Regel des falschen Handelsplatzes oder Produkts angenommen. - Eine ausfuehrbare Order wird unerwartet abgelehnt, storniert oder angepasst. - Kurslatenz laesst einen beim Client nicht kreuzenden Preis bei Engine-Ankunft kreuzen. - Tick-Rundung aendert den eingereichten Preis oder die Kreuzungspruefung. - Ein gesperrtes Buch, eine Auktion oder ein besonderer Handelsmodus aendert das Verhalten. - Eine ruhende Order wird nie ausgefuehrt. - Adverse Selektion uebersteigt jeden Maker-Rabatt. - Gebuehrenstufe, Vorzeichen des Rabatts oder Gebuehrenwaehrung aendern sich. - Der Maker-Status wird aus der Anfrage statt aus jeder Ausfuehrung abgeleitet. - Warteschlangentiefe oder verdeckte Liquiditaet werden unterschaetzt. - Eine Aenderung setzt die Warteschlangenprioritaet zurueck. - Eine Teilausfuehrung fehlt im Bestand oder Cash-Bestand. - Ein Stornierungs- oder Ersetzungsrennen erzeugt eine weitere Ausfuehrung oder ueberlappende Order. - Timeout oder nicht idempotente Wiederholung erzeugt unklaren oder doppelten Status. - WebSocket-Luecken, Duplikate oder ungeordnete Ereignisse verfaelschen die lokale Sicht. - Self-Trade Prevention storniert oder reduziert eine unerwartete Seite. - Post-only kollidiert mit `IOC`, `FOK` oder einer anderen Gueltigkeitsregel. - Reduce-only, Close-only oder Positionsmodus lehnt ab, reduziert oder kehrt die Absicht um. - Eine ausgeloeste Folgeorder wird ausfuehrbar und storniert oder abgelehnt. - Handelsplatz-, Verwahrungs-, API- oder Regelversagen oder Onchain-Reihenfolge, Gas, Reorganisation oder Finalitaet verhindern die Abstimmung. ## Haeufige Irrtuemer - **Post-only garantiert eine Ausfuehrung.** Die Order kann abgelehnt, storniert, unausgefuehrt ruhen oder verfallen. - **Eine erfolgreiche API-Antwort beweist, dass die Order im Buch ruht.** Transportbestaetigung und Matching-Engine-Status sind verschiedene Datensaetze. - **Jede Post-only-Ausfuehrung erhaelt einen Rabatt.** Maker-Einstufung, Stufe, Waehrung und Satz sind fill- und handelsplatzspezifisch. - **Aendern oder Stornieren verhindert jede spaetere Ausfuehrung.** Prioritaet kann zurueckgesetzt werden, und eine Ausfuehrung kann das Rennen vor der terminalen Bestaetigung gewinnen. - **Transaktionshash oder Blockinklusion beweisen, dass eine Onchain-Order Maker-Liquiditaet wurde und final gehandelt hat.** Inklusion, Protokollausfuehrung, Ruhezustand, Fill und Chain-Finalitaet sind getrennte Ereignisse. ## Verwandte Themen - [Krypto-Limitorder](/de/crypto/limit-order-crypto/) - [Maker- und Taker-Gebuehren](/de/crypto/maker-taker-fee/) - [Krypto-Orderbuch](/de/crypto/order-book-crypto/) ## Quellen - [Coinbase Markets Trading Rules](https://www.coinbase.com/legal/trading_rules) - Coinbase (abgerufen: 2026-08-13) - [Create a new order](https://docs.cdp.coinbase.com/api-reference/exchange-api/rest-api/orders/create-new-order) - Coinbase Developer Documentation (abgerufen: 2026-08-13) - [Exchange Matching Engine](https://docs.cdp.coinbase.com/exchange/concepts/matching-engine) - Coinbase Developer Documentation (abgerufen: 2026-08-13) - [Order Management Best Practices](https://docs.deribit.com/articles/order-management-best-practices) - Deribit Documentation (abgerufen: 2026-08-13) - [Post-Only Order](https://www.bybit.com/en/help-center/article/Post-Only-Order) - Bybit (abgerufen: 2026-08-13) - [Basic Order Types](https://www.okx.com/en-us/help/x-basic-order-types) - OKX (abgerufen: 2026-08-13) - [Order Amend Keep Priority](https://github.com/binance/binance-spot-api-docs/blob/master/faqs/order_amend_keep_priority.md) - Binance Spot API Documentation (abgerufen: 2026-08-13) - [Exchange endpoint](https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/exchange-endpoint) - Hyperliquid Docs (abgerufen: 2026-08-13) Source: https://wiki.fcontext.com/de/crypto/post-only-order/index.mdx