﻿---
title: "Ordem post-only"
description: "Uma ordem post-only e uma instrucao de ordem limitada especifica da plataforma, destinada a permanecer no livro em vez de tomar liquidez imediatamente; rejeicao, cancelamento, ajuste de preco, prioridade na fila e tarifas dependem das regras exatas de matching."
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.

# Ordem post-only

> Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.

<a id="answer"></a>

## Resposta direta

Uma instrucao post-only, ou somente de adicao de liquidez, e vinculada a uma ordem limitada e testada quando essa ordem chega ao motor de matching. Se qualquer parte fosse executada imediatamente contra liquidez no livro, a plataforma aplica sua propria regra: pode rejeitar a solicitacao, aceitar e cancelar a ordem ou mover seu preco para um nivel nao executavel de imediato. Portanto, post-only expressa uma condicao de entrada, e nao um tipo universal de ordem com resultado unico.

Uma ordem que permanece corretamente no livro pode negociar depois, quando chega uma ordem oposta. Essa execucao costuma ser classificada como liquidez maker, mas prevalecem o registro efetivo da execucao e o lancamento da tarifa. Um reconhecimento, o status `open` ou a marcacao post-only, isoladamente, nao garantem execucao, tratamento maker, rebate nem melhor resultado liquido.

<a id="mechanism"></a>

## Como funciona

A executabilidade imediata e avaliada pelo estado do motor, nao por uma tela desatualizada. Uma compra limitada no melhor ask ou acima dele e uma venda limitada no melhor bid ou abaixo dele normalmente cruzam o livro. Arredondamento ao tick, leiloes, livros travados ou cruzados, liquidez oculta, protecao de preco e prevencao de autonegociacao podem alterar o resultado. O ajuste automatico tambem muda o limite solicitado e a posicao na fila, portanto deve ser uma regra da plataforma aceita explicitamente.

Post-only e independente de outras instrucoes. `GTC`, `GTD`, `IOC` e `FOK` regem a validade; algumas plataformas rejeitam post-only com instrucoes de execucao imediata. `reduce-only`, close-only e os campos do lado da posicao regem a exposicao. Uma ordem stop ou take-profit pode nao entrar no livro antes do disparo, e a ordem filha convertida e entao testada pelas regras post-only vigentes da plataforma.

As regras de fila e ciclo de vida tambem sao especificas. Prioridade preco-tempo e comum, mas nao universal. Alterar o preco, aumentar a quantidade ou cancelar e substituir costuma perder prioridade; uma reducao de quantidade compativel pode preserva-la. A prevencao de autonegociacao pode cancelar ou reduzir a ordem entrante, a ordem no livro ou ambas. Somente eventos publicos e privados ordenados comprovam o que ocorreu.

Use este fluxo:

1. Fixe plataforma, entidade legal, produto, sessao e versao da API; registre tick, lote, nocional minimo, faixa tarifaria e se post-only executavel e rejeitada, cancelada ou ajustada.
2. Capture uma visao do melhor bid, melhor ask e profundidade com timestamp e sequencia coerente; especifique lado, limite, quantidade, validade, modo de posicao, post-only, reduce-only, prevencao de autonegociacao e campos de disparo.
3. Arredonde preco e quantidade exatamente e verifique cruzamento, bandas de preco, saldos, margem, limites de ordens e modos incompativeis, tratando como autoritativo o estado na chegada ao motor.
4. Envie com identificador unico de ordem do cliente; separe sucesso de transporte dos estados aceito, no livro ou terminal e registre identificador do servidor, timestamp e resposta completa.
5. Consuma eventos ordenados de ordens e execucoes; concilie execucao acumulada, quantidade restante, identificador da execucao, preco, nocional, indicador de liquidez, moeda da tarifa ou rebate e qualquer alteracao que mude a fila.
6. Trate alteracao, cancelamento e substituicao como corridas ate chegarem eventos terminais; repita de modo idempotente apos timeouts e ressincronize depois de mensagens duplicadas, ausentes ou fora de ordem.
7. Concilie quantidades executadas, canceladas, rejeitadas ou expiradas com estoque, bloqueios e saldos; avalie tarifas, rebates, selecao adversa e execucoes perdidas reais. Em uma plataforma onchain, verifique separadamente inclusao, execucao pelo protocolo e finalidade exigida.

<a id="example"></a>

## Exemplos

- **Comportamento ao cruzar.** O melhor bid e ask sao `99.90 / 100.00`, e o tick e `0.01`. Uma compra post-only de `2 BTC at 100.00` encontraria o ask imediatamente. Uma plataforma do tipo reject rejeita a solicitacao; uma do tipo cancel nao registra execucao e cancela a ordem. Uma do tipo reprice poderia move-la para `99.99`, mas somente se esse comportamento documentado tivesse sido solicitado. Uma compra a `99.99` pode permanecer no livro se o estado do motor nao mudar; a execucao nao e garantida.
- **Execucao maker no livro e tarifas.** Uma venda de `3 ETH at 99.90` permanece no livro enquanto bid e ask sao `99.80 / 100.00`; depois, uma compra agressiva a executa. O nocional e `3 x 99.90 = 299.70`. Com taxa maker de `-1 bp`, a tarifa e `299.70 x -0.0001 = -0.02997`, um rebate. Classifica-la incorretamente a uma taxa taker de `5 bp` gera cobranca de `0.14985`, diferenca de `0.17982`. Use o indicador de liquidez e o registro de tarifa efetivos.
- **Execucao parcial e corrida de cancelamento.** Uma venda post-only no livro e de `10 units at 100`. Ela executa `4`, e o cliente envia o cancelamento. Antes do cancelamento terminal, outra `1` executa, deixando `5` canceladas. A quantidade total executada e `5`, nao `4`; o nocional executado e `500`, e um rebate de `2 bp` e `0.10`. Um reconhecimento de cancelamento nao e o registro terminal do estoque.
- **Tarifas menores ainda podem custar mais.** Comprar `10` imediatamente a `100.00` com tarifa taker de `8 bp` custa `1,000.80`. Perder esse preco e depois permanecer no livro a `100.20` com tarifa maker de `2 bp` custa `1,002.2004`. A rota maker economiza `0.5996` em tarifas, mas custa `1.4004` a mais no total. Post-only administra o comportamento de execucao; nao otimiza automaticamente a operacao completa.

<a id="risks"></a>

## Riscos

- Pressupoe-se a regra post-only da plataforma ou produto errado.
- Uma ordem executavel e inesperadamente rejeitada, cancelada ou ajustada.
- A latencia faz um preco nao cruzado no cliente cruzar ao chegar ao motor.
- O arredondamento ao tick muda o preco enviado ou o teste de cruzamento.
- Livro travado, leilao ou modo especial de negociacao altera o comportamento.
- Uma ordem no livro nunca e executada.
- A selecao adversa supera qualquer rebate maker.
- Mudam a faixa, o sinal do rebate ou a moeda da tarifa.
- O status maker e inferido da solicitacao, em vez de cada execucao.
- A profundidade na fila ou a liquidez oculta e subestimada.
- Uma alteracao reinicia a prioridade na fila.
- Uma execucao parcial e omitida do estoque ou do caixa.
- Uma corrida de cancelamento ou substituicao cria execucao adicional ou ordem sobreposta.
- Um timeout ou retry nao idempotente cria estado incerto ou duplicado.
- Lacunas, duplicatas ou eventos fora de ordem no WebSocket corrompem a visao local.
- A prevencao de autonegociacao cancela ou reduz um lado inesperado.
- Post-only conflita com `IOC`, `FOK` ou outra regra de validade.
- Reduce-only, close-only ou o modo de posicao rejeita, reduz ou inverte a intencao.
- Uma ordem filha disparada torna-se executavel e e cancelada ou rejeitada.
- Falha da plataforma, custodia, API ou regra, ou ordenacao onchain, gas, reorganizacao ou finalidade, impede a conciliacao.

<a id="misconceptions"></a>

## Erros comuns

- **Post-only garante execucao.** A ordem pode ser rejeitada, cancelada, permanecer sem negociar ou expirar.
- **Uma resposta bem-sucedida da API prova que a ordem esta no livro.** O reconhecimento de transporte e o estado do motor sao registros distintos.
- **Toda execucao post-only recebe rebate.** Classificacao maker, faixa, moeda e taxa dependem da execucao e da plataforma.
- **Alterar ou cancelar impede qualquer execucao posterior.** A prioridade pode ser reiniciada, e uma execucao pode vencer a corrida antes da confirmacao terminal.
- **Um hash de transacao ou a inclusao em bloco prova que uma ordem onchain virou liquidez maker e foi negociada com finalidade.** Inclusao, execucao pelo protocolo, estado no livro, execucao e finalidade da cadeia sao eventos distintos.

<a id="related"></a>

## Topicos relacionados

- [Ordem limitada de criptoativos](/pt-br/crypto/limit-order-crypto/)
- [Tarifas maker e taker](/pt-br/crypto/maker-taker-fee/)
- [Livro de ordens de criptoativos](/pt-br/crypto/order-book-crypto/)

<a id="sources"></a>

## Fontes

- [Coinbase Markets Trading Rules](https://www.coinbase.com/legal/trading_rules) - Coinbase (acesso: 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 (acesso: 2026-08-13)
- [Exchange Matching Engine](https://docs.cdp.coinbase.com/exchange/concepts/matching-engine) - Coinbase Developer Documentation (acesso: 2026-08-13)
- [Order Management Best Practices](https://docs.deribit.com/articles/order-management-best-practices) - Deribit Documentation (acesso: 2026-08-13)
- [Post-Only Order](https://www.bybit.com/en/help-center/article/Post-Only-Order) - Bybit (acesso: 2026-08-13)
- [Basic Order Types](https://www.okx.com/en-us/help/x-basic-order-types) - OKX (acesso: 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 (acesso: 2026-08-13)
- [Exchange endpoint](https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/exchange-endpoint) - Hyperliquid Docs (acesso: 2026-08-13)

Source: https://wiki.fcontext.com/pt-br/crypto/post-only-order/index.mdx
