Transactions agrégées (aggTrades)

Les transactions agrégées, ou aggTrades, sont les enregistrements compacts de Binance dans lesquels les exécutions produites par un même ordre taker à un même prix sont fusionnées en un seul événement à quantité cumulée. Un aggTrade compte donc un ordre agressif, pas une exécution, et il porte le drapeau maker nécessaire pour classer l'agresseur.

Senzoukria · Glossaire · Mis à jour en septembre 2026


Définition et champs

Quand un ordre taker balaie plusieurs ordres au repos au même prix, l'exchange produit une exécution par ordre touché. Le flux et les archives de transactions agrégées de Binance fusionnent ces exécutions en un seul enregistrement : un identifiant d'agrégat, le prix, la quantité cumulée, les identifiants de la première et de la dernière transaction sous-jacente, un horodatage et un drapeau indiquant si l'acheteur était maker. Si l'acheteur était maker, c'est le vendeur qui a pris la liquidité et la transaction est agressive à la vente ; sinon elle est agressive à l'achat.

Cette représentation ne perd rien de ce dont un footprint a besoin. Le volume par prix et par côté est inchangé par la fusion, et le delta, calculé comme volume à l'ask moins volume au bid à chaque prix, ressort identique. Ce qui change, c'est le comptage : un graphique qui affiche le nombre d'événements affiche des ordres agressifs, pas des exécutions brutes.

  • Un enregistrement par ordre taker et par prix, quantité cumulée.
  • Le drapeau maker sur l'acheteur donne le côté agresseur sans règle du tick.
  • Les identifiants ordonnés permettent de détecter un trou quand le flux perd des messages.

Pourquoi un footprint préfère ce format

  • Moins de messages pour le même volume, ce qui compte sur les paires actives en séance rapide.
  • Le côté agresseur est explicite : le delta devient une mesure et non une estimation.
  • Les archives historiques sont publiées dans le même format, donc l'historique reconstruit respecte la convention du direct.
  • La distribution des tailles est par ordre, ce qui correspond à l'intention d'un filtre de gros trades.

Dans Senzoukria

Les sources Binance Spot et Binance USD-M Perp lisent le flux aggTrade en direct, et le chemin d'historique crypto reconstruit les cellules bid × ask à partir des archives aggTrades de l'exchange, qui fournissent la quantité et le côté pour les séances passées. Au premier chargement, le chart importe les transactions récentes puis poursuit sur le flux ; quand le flux reste vide un certain temps, la connexion le signale au lieu de dessiner des barres plates.

Chaque aggTrade est stocké avec son notionnel en plus de sa quantité en actif de base, de sorte que le footprint, les bulles Big Trades et les indicateurs de taille peuvent changer d'unité de façon cohérente. Comme l'enregistrement correspond à un ordre agressif, les indicateurs de nombre et de taille de transactions comptent des ordres en crypto. Le guide crypto renvoie vers un journal de construction qui documente ce que coûte en pratique la reconstruction d'une journée de bid × ask depuis ces archives, mesuré sur BTCUSDT Spot.

Erreurs fréquentes

  • Comparer un nombre d'aggTrades au nombre de transactions brutes d'un autre flux et lire l'écart comme des données manquantes.
  • Inverser le drapeau maker : acheteur maker signifie que le vendeur était agressif.
  • Supposer que Bybit utilise la même agrégation et le même drapeau ; son champ de côté se vérifie séparément.
  • Lire un gros aggTrade comme l'intention d'un participant : c'est un ordre, et rien n'indique qui l'a envoyé.

Cette page dans d’autres langues

Questions fréquentes

Les aggTrades changent-ils le delta par rapport aux transactions brutes ?
Non. Fusionner les exécutions d'un même ordre taker à un même prix additionne des quantités du même côté au même prix : le volume à l'ask, le volume au bid et leur différence par niveau sont identiques. Seuls les comptages diffèrent : les aggTrades comptent des ordres agressifs, les transactions brutes comptent des exécutions.
Les aggTrades permettent-ils de reconstruire un carnet ?
Non. Ils enregistrent ce qui s'est exécuté, pas ce qui attendait et a été annulé. Une heatmap historique demande une profondeur enregistrée sur la période, qui vient côté crypto d'une source d'historique de carnet distincte. Les archives de transactions ne peuvent pas révéler un ordre au repos qui n'a jamais tradé.