Aller au contenu
Financial Context Wiki

Ordre post-only

Un ordre post-only est une instruction d'ordre a cours limite propre a la plateforme, concue pour rester dans le carnet plutot que prendre immediatement de la liquidite ; rejet, annulation, revalorisation, priorite dans la file et frais dependent des regles exactes d'appariement.

Mis à jour

À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

Reponse directe

Une instruction post-only, ou add-liquidity-only, est jointe a un ordre a cours limite et testee lorsque celui-ci atteint le moteur d’appariement. Si une partie devait s’executer immediatement contre une liquidite deja presente, la plateforme applique sa propre regle : elle peut rejeter la demande, accepter puis annuler l’ordre, ou deplacer son prix vers un niveau non immediatement executable. Post-only exprime donc une condition d’entree, pas un type d’ordre universel produisant un resultat unique.

Un ordre correctement inscrit au carnet peut ensuite etre execute lorsqu’un ordre oppose arrive. Cette execution est souvent classee comme liquidite maker, mais le releve d’execution et l’ecriture de frais reels font foi. Un accuse de reception, un statut open ou le seul indicateur post-only ne garantissent ni execution, ni traitement maker, ni rebate, ni meilleur resultat net.

Fonctionnement

Le caractere immediatement executable est evalue selon l’etat du moteur, pas selon un ecran perime. Une limite d’achat au meilleur ask ou au-dessus, et une limite de vente au meilleur bid ou en dessous, croisent normalement le carnet. Arrondi au tick, encheres, carnets bloques ou croises, liquidite cachee, protections de prix et prevention de l’auto-negociation peuvent modifier le resultat. La revalorisation automatique change aussi la limite demandee et la position dans la file ; elle doit donc constituer une regle de plateforme explicitement acceptee.

Post-only est independant des autres instructions. GTC, GTD, IOC et FOK regissent la duree de validite ; certaines plateformes refusent post-only avec des instructions d’execution immediate. reduce-only, close-only et les champs de sens de position regissent l’exposition. Un ordre stop ou take-profit peut ne rejoindre le carnet qu’apres declenchement ; l’ordre enfant cree est alors controle selon les regles post-only courantes de la plateforme.

Les regles de file et de cycle de vie sont tout aussi specifiques. La priorite prix-temps est courante, mais pas universelle. Un changement de prix, une hausse de quantite ou une annulation-remplacement font souvent perdre la priorite ; une reduction de quantite prise en charge peut la conserver. La prevention de l’auto-negociation peut annuler ou reduire l’ordre entrant, l’ordre au carnet ou les deux. Seuls des evenements publics et prives ordonnes etablissent ce qui s’est effectivement produit.

Suivez ce processus :

  1. Fixer la plateforme, l’entite juridique, le produit, la session et la version d’API ; relever le tick, le lot, le notionnel minimal, la tranche tarifaire et le traitement des ordres post-only executables : rejet, annulation ou revalorisation.
  2. Capturer le meilleur bid, le meilleur ask et la profondeur avec horodatage et sequence coherente ; preciser sens, limite, quantite, validite, mode de position, post-only, reduce-only, prevention de l’auto-negociation et champs de declenchement.
  3. Arrondir exactement prix et quantite, puis controler croisement, bandes de prix, soldes, marge, plafonds d’ordres et modes incompatibles, tout en considerant l’etat a l’arrivee dans le moteur comme faisant foi.
  4. Envoyer avec un identifiant d’ordre client unique ; distinguer le succes du transport des statuts accepte, au carnet ou terminal, et consigner identifiant serveur, horodatage et reponse complete.
  5. Consommer les evenements ordonnes d’ordres et d’executions ; rapprocher cumul execute, quantite restante, identifiant d’execution, prix, notionnel, indicateur de liquidite, devise des frais ou du rebate et toute modification affectant la file.
  6. Traiter modification, annulation et remplacement comme des courses jusqu’aux evenements terminaux ; reessayer de maniere idempotente apres les timeouts et resynchroniser apres messages doubles, manquants ou desordonnes.
  7. Rapprocher les quantites executees, annulees, rejetees ou expirees avec stocks, montants bloques et soldes, puis evaluer frais, rebates, selection adverse et executions manquees reels ; pour une plateforme onchain, verifier separement inclusion, execution du protocole et finalite requise.

Exemples

  • Comportement en cas de croisement. Le meilleur bid et ask valent 99.90 / 100.00 et le tick 0.01. Un achat post-only de 2 BTC at 100.00 rencontrerait immediatement l’ask. Une plateforme de type reject rejette la demande ; une plateforme cancel n’enregistre aucune execution et annule l’ordre. Une plateforme reprice pourrait le deplacer a 99.99, mais uniquement si ce comportement documente a ete demande. Un achat a 99.99 peut rester au carnet si l’etat du moteur ne change pas ; son execution n’est pas garantie.
  • Execution maker au carnet et frais. Une vente de 3 ETH at 99.90 reste au carnet avec bid et ask a 99.80 / 100.00, puis un achat agressif l’execute. Le notionnel est 3 x 99.90 = 299.70. Avec un taux maker de -1 bp, les frais sont 299.70 x -0.0001 = -0.02997, soit un rebate. La classer a tort au taux taker de 5 bp produit une charge de 0.14985, soit un ecart de 0.17982. Utilisez l’indicateur de liquidite et l’ecriture de frais reels.
  • Execution partielle et course a l’annulation. Une vente post-only au carnet porte sur 10 units at 100. Elle execute 4, puis le client envoie une annulation. Avant l’annulation terminale, une autre 1 est executee, laissant 5 annulees. La quantite totale executee est 5, pas 4 ; le notionnel execute vaut 500 et un rebate de 2 bp vaut 0.10. Un accuse d’annulation n’est pas le releve terminal du stock.
  • Des frais inferieurs peuvent tout de meme couter plus cher. Acheter immediatement 10 a 100.00 avec 8 bp de frais taker coute 1,000.80. Manquer ce prix puis rester au carnet a 100.20 avec 2 bp de frais maker coute 1,002.2004. La voie maker economise 0.5996 de frais, mais coute 1.4004 de plus au total. Post-only gere le comportement d’execution ; il n’optimise pas automatiquement l’operation complete.

Risques

  • La regle post-only du mauvais produit ou de la mauvaise plateforme est supposee.
  • Un ordre executable est rejete, annule ou revalorise de facon inattendue.
  • La latence fait qu’un prix non croisant cote client croise a l’arrivee au moteur.
  • L’arrondi au tick change le prix transmis ou le test de croisement.
  • Un carnet bloque, une enchere ou un mode special change le comportement.
  • Un ordre au carnet n’est jamais execute.
  • La selection adverse depasse tout rebate maker.
  • La tranche, le signe du rebate ou la devise des frais change.
  • Le statut maker est deduit de la demande plutot que de chaque execution.
  • La profondeur de file ou la liquidite cachee est sous-estimee.
  • Une modification reinitialise la priorite dans la file.
  • Une execution partielle est omise du stock ou de la tresorerie.
  • Une course d’annulation ou de remplacement cree une execution supplementaire ou un ordre chevauchant.
  • Un timeout ou une nouvelle tentative non idempotente cree un etat incertain ou duplique.
  • Lacunes, doublons ou evenements WebSocket desordonnes corrompent la vue locale.
  • La prevention de l’auto-negociation annule ou reduit un cote inattendu.
  • Post-only entre en conflit avec IOC, FOK ou une autre regle de validite.
  • Reduce-only, close-only ou le mode de position rejette, reduit ou inverse l’intention.
  • Un ordre enfant declenche devient executable et est annule ou rejete.
  • Une defaillance de plateforme, conservation, API ou regle, ou l’ordonnancement onchain, le gas, une reorganisation ou la finalite, empeche le rapprochement.

Idees fausses courantes

  • Post-only garantit une execution. L’ordre peut etre rejete, annule, rester sans execution ou expirer.
  • Une reponse API reussie prouve que l’ordre est au carnet. L’accuse de transport et l’etat du moteur sont des releves differents.
  • Chaque execution post-only obtient un rebate. Classification maker, tranche, devise et taux dependent de l’execution et de la plateforme.
  • Modifier ou annuler empeche toute execution ulterieure. La priorite peut etre reinitialisee et une execution peut gagner la course avant la confirmation terminale.
  • Un hash de transaction ou une inclusion dans un bloc prouve qu’un ordre onchain est devenu liquidite maker et a ete negocie avec finalite. Inclusion, execution du protocole, etat au carnet, execution et finalite de chaine sont des evenements distincts.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...