---
title: "Ordine post-only"
description: "Un ordine post-only e un'istruzione di limite specifica della sede di negoziazione, destinata a restare nel book anziche assorbire subito liquidita; rifiuto, cancellazione, riprezzamento, priorita in coda e commissioni dipendono dalle regole di matching applicabili."
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.
# Ordine post-only
> Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.
## Risposta diretta
Un'istruzione post-only, o add-liquidity-only, viene associata a un ordine limite e verificata quando l'ordine raggiunge il motore di matching. Se una sua parte fosse immediatamente eseguibile contro liquidita presente nel book, la sede applica la propria regola: puo rifiutare la richiesta, accettare e cancellare l'ordine oppure spostarne il prezzo a un livello non immediatamente eseguibile. Post-only esprime quindi una condizione d'ingresso, non un tipo d'ordine universale con un solo esito.
Un ordine correttamente inserito nel book puo essere eseguito in seguito all'arrivo di un ordine opposto. L'eseguito e normalmente classificato come liquidita maker, ma fanno fede il record effettivo dell'esecuzione e il relativo addebito commissionale. Una conferma, lo stato `open` o il flag post-only da soli non garantiscono esecuzione, trattamento maker, rebate o un risultato netto migliore.
## Come funziona
L'immediata eseguibilita viene valutata sullo stato del motore, non su una schermata obsoleta. Un limite di acquisto pari o superiore al miglior ask e un limite di vendita pari o inferiore al miglior bid normalmente incrociano il book. Arrotondamento al tick, aste, book bloccati o incrociati, liquidita nascosta, protezioni di prezzo e self-trade prevention possono cambiare l'esito. Anche il riprezzamento automatico modifica il limite richiesto e la posizione in coda, quindi deve essere una regola della sede accettata esplicitamente.
Post-only e indipendente dalle altre istruzioni. `GTC`, `GTD`, `IOC` e `FOK` regolano la validita; alcune sedi rifiutano post-only insieme a istruzioni di esecuzione immediata. `reduce-only`, close-only e i campi relativi al lato della posizione regolano l'esposizione. Un ordine stop o take-profit puo entrare nel book solo all'attivazione; l'ordine figlio generato viene allora verificato secondo le regole post-only correnti della sede.
Anche coda e ciclo di vita dipendono dalla sede. La priorita prezzo-tempo e comune, non universale. Modificare il prezzo, aumentare la quantita o cancellare e sostituire spesso fa perdere priorita; una riduzione supportata puo conservarla. La self-trade prevention puo cancellare o ridurre l'ordine in ingresso, quello nel book o entrambi. Solo eventi pubblici e privati correttamente ordinati attestano cio che e realmente accaduto.
Usare questo processo:
1. Fissare sede, entita giuridica, prodotto, sessione e versione API; registrare tick, lotto, nozionale minimo, fascia commissionale e se gli ordini post-only eseguibili vengono rifiutati, cancellati o riprezzati.
2. Acquisire miglior bid, miglior ask e profondita con timestamp e sequenza coerente; specificare lato, limite, quantita, validita, modalita di posizione, post-only, reduce-only, self-trade prevention e campi trigger.
3. Arrotondare esattamente prezzo e quantita e verificare incrocio, bande di prezzo, saldi, margine, limiti agli ordini e modalita incompatibili, considerando autorevole lo stato all'arrivo nel motore.
4. Inviare con un identificativo cliente univoco; distinguere il successo del trasporto dagli stati accettato, nel book o terminale e registrare identificativo server, timestamp e risposta completa.
5. Elaborare eventi ordinati di ordini ed eseguiti; riconciliare quantita cumulativa eseguita, residuo, ID eseguito, prezzo, nozionale, indicatore di liquidita, valuta di commissione o rebate e ogni modifica che incida sulla coda.
6. Trattare modifica, cancellazione e sostituzione come corse fino agli eventi terminali; riprovare in modo idempotente dopo timeout e risincronizzare dopo messaggi duplicati, mancanti o fuori ordine.
7. Riconciliare quantita eseguite, cancellate, rifiutate o scadute con inventario, importi bloccati e saldi, quindi valutare commissioni, rebate, selezione avversa ed esecuzioni mancate effettivi; per una sede onchain verificare separatamente inclusione, esecuzione del protocollo e finalita richiesta.
## Esempi
- **Comportamento in caso di incrocio.** Miglior bid e ask sono `99.90 / 100.00` e il tick e `0.01`. Un acquisto post-only di `2 BTC at 100.00` incontrerebbe subito l'ask. Una sede reject rifiuta la richiesta; una sede cancel non registra eseguiti e cancella l'ordine. Una sede reprice potrebbe spostarlo a `99.99`, ma solo se e stato richiesto quel comportamento documentato. Un acquisto a `99.99` puo restare nel book se lo stato del motore non cambia; l'esecuzione non e garantita.
- **Eseguito maker nel book e commissioni.** Una vendita di `3 ETH at 99.90` resta nel book con bid e ask a `99.80 / 100.00`, poi viene eseguita da un acquisto aggressivo. Il nozionale e `3 x 99.90 = 299.70`. Con tasso maker `-1 bp`, la commissione e `299.70 x -0.0001 = -0.02997`, cioe un rebate. Classificarla erroneamente al tasso taker `5 bp` genera un addebito di `0.14985`, con differenza di `0.17982`. Usare l'indicatore di liquidita e il record commissionale effettivi.
- **Eseguito parziale e corsa alla cancellazione.** Una vendita post-only nel book e `10 units at 100`. Ne vengono eseguite `4`, poi il client invia la cancellazione. Prima della cancellazione terminale viene eseguita un'altra `1`, lasciandone `5` cancellate. La quantita totale eseguita e `5`, non `4`; il nozionale eseguito e `500` e un rebate di `2 bp` equivale a `0.10`. Una conferma di cancellazione non e il record terminale dell'inventario.
- **Commissioni inferiori possono comunque costare di piu.** Acquistare subito `10` a `100.00` con commissione taker `8 bp` costa `1,000.80`. Perdere quel prezzo e restare poi nel book a `100.20` con commissione maker `2 bp` costa `1,002.2004`. Il percorso maker risparmia `0.5996` in commissioni, ma costa `1.4004` in piu nel complesso. Post-only gestisce il comportamento esecutivo; non ottimizza automaticamente l'intera operazione.
## Rischi
- Si presume la regola post-only della sede o del prodotto sbagliato.
- Un ordine eseguibile viene inaspettatamente rifiutato, cancellato o riprezzato.
- La latenza fa incrociare all'arrivo un prezzo che non incrociava lato client.
- L'arrotondamento al tick cambia il prezzo inviato o il test di incrocio.
- Un book bloccato, un'asta o una modalita speciale cambia il comportamento.
- Un ordine nel book non viene mai eseguito.
- La selezione avversa supera qualsiasi rebate maker.
- Cambiano fascia, segno del rebate o valuta commissionale.
- Lo stato maker viene dedotto dalla richiesta anziche da ogni eseguito.
- Profondita in coda o liquidita nascosta vengono sottostimate.
- Una modifica azzera la priorita in coda.
- Un eseguito parziale viene omesso dall'inventario o dalla cassa.
- Una corsa di cancellazione o sostituzione crea un altro eseguito o ordine sovrapposto.
- Un timeout o retry non idempotente crea uno stato incerto o duplicato.
- Lacune, duplicati o eventi WebSocket fuori ordine corrompono la vista locale.
- La self-trade prevention cancella o riduce un lato inatteso.
- Post-only e incompatibile con `IOC`, `FOK` o un'altra regola di validita.
- Reduce-only, close-only o la modalita di posizione rifiuta, riduce o inverte l'intento.
- Un ordine figlio attivato diventa eseguibile e viene cancellato o rifiutato.
- Un guasto di sede, custodia, API o regole, oppure ordinamento onchain, gas, riorganizzazione o finalita, impedisce la riconciliazione.
## Errori comuni
- **Post-only garantisce un eseguito.** L'ordine puo essere rifiutato, cancellato, restare ineseguito o scadere.
- **Una risposta API positiva prova che l'ordine e nel book.** Conferma di trasporto e stato del motore sono record diversi.
- **Ogni eseguito post-only riceve un rebate.** Classificazione maker, fascia, valuta e tasso dipendono dall'eseguito e dalla sede.
- **Modificare o cancellare impedisce ogni eseguito successivo.** La priorita puo azzerarsi e un eseguito puo vincere la corsa prima della conferma terminale.
- **Un hash di transazione o l'inclusione in un blocco prova che un ordine onchain e diventato liquidita maker ed e stato negoziato con finalita.** Inclusione, esecuzione del protocollo, stato nel book, eseguito e finalita della catena sono eventi separati.
## Argomenti correlati
- [Ordine limite in criptoattivita](/it/crypto/limit-order-crypto/)
- [Commissioni maker e taker](/it/crypto/maker-taker-fee/)
- [Book degli ordini cripto](/it/crypto/order-book-crypto/)
## Fonti
- [Coinbase Markets Trading Rules](https://www.coinbase.com/legal/trading_rules) - Coinbase (consultato: 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 (consultato: 2026-08-13)
- [Exchange Matching Engine](https://docs.cdp.coinbase.com/exchange/concepts/matching-engine) - Coinbase Developer Documentation (consultato: 2026-08-13)
- [Order Management Best Practices](https://docs.deribit.com/articles/order-management-best-practices) - Deribit Documentation (consultato: 2026-08-13)
- [Post-Only Order](https://www.bybit.com/en/help-center/article/Post-Only-Order) - Bybit (consultato: 2026-08-13)
- [Basic Order Types](https://www.okx.com/en-us/help/x-basic-order-types) - OKX (consultato: 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 (consultato: 2026-08-13)
- [Exchange endpoint](https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/exchange-endpoint) - Hyperliquid Docs (consultato: 2026-08-13)
Source: https://wiki.fcontext.com/it/crypto/post-only-order/index.mdx