Smart Order Routing em Cripto: Uma Ordem, Doze Corretoras, Nenhum NBBO
Você precisa comprar 400 BTC. A Binance tem a maior profundidade. OKX e Bybit mostram, cada uma, um tamanho razoável um tick mais largo. A Coinbase cota um preço de fachada melhor, mas em USD, não em USDT. O topo do livro da Kraken parece fantástico e está desatualizado em 400 milissegundos. A Upbit é ainda melhor, mas sua aprovação de compliance para a Coreia não existe, e o seu KRW também não. Um trader de ações olhando para essa bagunça recorreria a um smart order router e pararia de pensar, porque em ações as partes difíceis do roteamento foram reguladas para dentro do encanamento há duas décadas. Em cripto, você é o encanamento. Não há fita consolidada, nenhuma regra de proteção contra trade-through, nenhum teto de taxa, nenhuma liquidação líquida — e, mais fundamentalmente, nenhuma capacidade de negociar em qualquer lugar onde seu capital ainda não esteja alocado.
Este artigo trata de construir o router mesmo assim: o livro consolidado e por que o roteamento ingênuo pelo melhor preço contra ele perde dinheiro, o problema de alocação como um programa convexo que você consegue realmente resolver dentro do prazo de uma ordem filha, a restrição de capital que torna o SOR em cripto indissociável da gestão de tesouraria, o roteamento ciente de maker entre corretoras, e o loop de feedback de TCA que diz se tudo isso funciona. É o irmão de engenharia de Execução de Arbitragem Complexa em Rust — aquele artigo cobre os nanossegundos; este cobre as decisões.
O que o SOR de ações ganha de graça
Vale a pena ser preciso sobre o que o roteamento de ações dos EUA herda da regulação, porque cada item da lista é algo que você precisa reconstruir ou conscientemente viver sem ele.
A Regulation NMS (SEC, 2005) fez três coisas que importam aqui. A Rule 611, a Order Protection Rule, proíbe executar a um preço pior do que uma cotação protegida exibida em outra bolsa — um "trade-through" — o que força toda corretora a rotear para o melhor preço exibido ou varrê-lo com ordens de intermarket sweep. A Rule 610 limita a taxa de acesso que qualquer venue pode cobrar por tomar uma cotação protegida a $0.003 por ação, de modo que os preços exibidos são comparáveis entre venues com margem de 30 mils. E a fita consolidada (os SIPs) publica um National Best Bid and Offer, uma única resposta oficial para "qual é o mercado".
O veredito acadêmico sobre essa arquitetura é que ela funciona surpreendentemente bem. O'Hara and Ye (2011), "Is market fragmentation harming market quality?" (Journal of Financial Economics 100(3), 459–474), examinaram ações dos EUA em diferentes níveis de fragmentação e descobriram que ações mais fragmentadas tinham custos de transação menores e execuções mais rápidas, com preços mais próximos de um passeio aleatório. O resumo deles é a frase-chave: as ações dos EUA se comportam como "um único mercado virtual com múltiplos pontos de entrada". A fragmentação é inofensiva quando smart routers somada à proteção contra trade-through costuram os fragmentos de volta. Foucault and Menkveld (2008), "Competition for Order Flow and Smart Order Routing Systems" (Journal of Finance 63(1), 119–158), mostraram o mecanismo no mercado holandês: quando um segundo livro de ordens limitadas (o EuroSETS da LSE) entrou em concorrência com a Euronext, a profundidade consolidada aumentou, e a oferta de liquidez em um venue foi diretamente amortecida pela sua taxa de trade-through — routers que ignoram um venue matam o incentivo dele para cotar.
Mesmo nesse mundo regulado, a visão consolidada é uma mentira em horizontes curtos. Ding, Hanna, and Hendershott (2014), "How Slow Is the NBBO? A Comparison with Direct Exchange Feeds" (Financial Review 49(2), 313–332), mediram o NBBO do SIP contra um NBBO construído a partir de feeds diretos das bolsas no mesmo data center e encontraram deslocamentos várias vezes por segundo em ativos ativos, tipicamente durando de um a dois milissegundos — pura latência de agregação e transporte. Guarde esse número: é a versão em ações de um problema que é de uma a duas ordens de magnitude pior em cripto.
Agora apague tudo isso. Cripto não tem NBBO porque não há SIP. Nenhuma regra de trade-through: um venue vai alegremente lhe dar um preço cinco ticks através da cotação de outro venue, e ninguém registra nada. Nenhum teto de taxa: as taxas de taker variam de níveis negociados abaixo de um ponto-base até tabelas de varejo de 10 pontos-base, então a ordenação por preço exibido e a ordenação por preço líquido rotineiramente discordam. E nenhuma compensação consolidada: cada bolsa é seu próprio silo com saldos pré-financiados. Você é o SIP, o router e a corretora de compensação, simultaneamente.
Construindo o livro consolidado, e por que o roteamento ingênuo pelo melhor preço falha
A base de engenharia é pouco glamourosa: N feeds L2 via WebSocket, tratamento de gaps de número de sequência por venue, normalização de símbolo e tamanho de tick, e normalização de moeda de cotação (um livro BTC-USD e um livro BTC-USDT diferem pela taxa USDT/USD, que não é identicamente 1.0 e ocasionalmente está bem longe disso). Combine os livros normalizados em uma única escada ordenada por preço, marcando cada nível com seu venue e — crucialmente — a idade do snapshot de onde veio. Se o seu livro combinado não carrega a idade da cotação por venue como um campo de primeira classe, você construiu um protetor de tela, não um router.

O router ingênuo percorre essa escada combinada gulosamente: melhor preço líquido primeiro. Ele falha por três razões distintas, e vale a pena mantê-las distintas porque as correções são diferentes.
Cotações desatualizadas e distorção de latência. Seus venues não entregam dados na mesma latência. Um feed colocado (colocated) pode ter 3 ms de idade quando você age sobre ele; um WebSocket público de um venue em outro continente pode ter 300 ms de idade. O topo do livro combinado é, portanto, um composto de passados diferentes. Quando o BTC se move 10 pontos-base em 200 ms — rotina —, as cotações do venue desatualizado parecem sistematicamente atraentes exatamente no lado errado. Rotear para elas compra uma corrida que você já perdeu: a cotação se foi, sua ordem IOC volta vazia ou parcialmente preenchida, e quando você reroteia, os venues frescos já reprecificaram. Este é o problema de deslocamento de 1–2 ms do SIP de Ding–Hanna–Hendershott, exceto que seus deslocamentos duram centenas de milissegundos e ninguém é obrigado a honrar nada.
Liquidez fantasma. Somar o tamanho exibido entre venues superestima, porque o mesmo inventário de um market maker é cotado em vários lugares ao mesmo tempo. Van Kervel (2015), "Competition for Order Flow with Fast and Slow Traders" (Review of Financial Studies 28(7), 2094–2127), documentou isso em ações fragmentadas: um trade em um venue é seguido, dentro de milissegundos, por cancelamentos significativos de ordens limitadas em venues concorrentes, exatamente como previsto por um modelo em que provedores de liquidez rápidos cotam tamanho duplicado em todo lugar e retiram as cópias assim que uma é atingida. Market makers de cripto seguem o mesmo roteiro entre Binance/OKX/Bybit, então a profundidade consolidada acessível é materialmente menor do que a profundidade consolidada exibida, e a diferença cresce conforme quão sequencialmente (em vez de simultaneamente) você atinge os venues. Se o seu router envia ordens filhas um venue por vez, esperando a confirmação de preenchimento de cada uma, você está cultivando a si mesmo: cada preenchimento sinaliza ao resto da rua para cancelar.
As taxas reordenam a escada. Um venue mostrando o melhor preço bruto com uma taxa de taker de 7.5 pontos-base é frequentemente o pior preço líquido do livro. Isso soa óbvio demais para dizer, mas "roteamento pelo melhor preço exibido" é exatamente o que a maioria dos routers de cripto de primeira geração (e vários produtos de fornecedores) implementa. A comparação líquida de taxa é o mínimo aceitável; o artigo irmão sobre taxas e rebates de maker-taker cobre a matemática de taxas por venue, a dinâmica de níveis VIP e por que o seu nível de taxa marginal — não o preço de tabela — pertence ao router.
A otimização de roteamento
Formalize o problema da ordem filha. Você precisa comprar quantidade agora, negociável, entre venues . Seja o preço de venda marginal do venue após consumir unidades de seu livro (uma função escada não decrescente a partir do snapshot L2), sua taxa de taker, e uma penalidade por unidade para desatualização e seleção adversa no venue (calibrada abaixo, a partir dos seus próprios markouts). A alocação resolve
Cada é convexa (integral de uma função não decrescente, mais um termo linear), então o problema é convexo, e as condições KKT contam toda a história: existe um limiar tal que
e para venues que não recebem nada. Em palavras: derrame a ordem entre os venues como água, igualando o custo marginal all-in em todos os lugares onde você negocia. Um venue é excluído exatamente quando sua primeira unidade — melhor preço, mais taxa, mais penalidade de desatualização — é pior do que a unidade marginal em outro lugar.

Para livros em função escada, a solução water-filling é calculada por uma caminhada gulosa sobre a escada combinada ajustada por taxa e penalidade — então a caminhada gulosa em profundidade não está errada em si; ela é a solução exata desde que você caminhe gulosamente sobre custos marginais líquidos com tamanhos ajustados (haircut), não preços brutos exibidos. Essa distinção é toda a diferença entre um router e um protetor de tela.
O tratamento canônico do problema geral é Cont and Kukanov, "Optimal order placement in limit order markets" (Quantitative Finance 17(1), 21–39, 2017; arXiv:1210.1625). Eles formulam o posicionamento de ordens entre venues — incluindo a divisão entre ordens limitadas e a mercado, taxas e rebates, e uma penalidade para o risco de execução — como uma otimização convexa, derivam uma forma fechada explícita para a divisão limite/mercado de venue único, e dão um algoritmo de aproximação estocástica para o caso multi-venue que calcula uma alocação entre doze bolsas em menos de 200 ms. O framework é anterior ao cripto, mas se transfere quase intocado, porque nunca assumiu um NBBO em primeiro lugar — assumiu apenas livros por venue, taxas por venue e incerteza sobre preenchimentos, que é precisamente a situação do cripto.
Um esboço mínimo e honesto do lado negociável (o water-fill convexo com haircuts de desatualização):
import math
from dataclasses import dataclass
@dataclass
class Venue:
name: str
asks: list[tuple[float, float]] # (price, displayed size), sorted
taker_fee: float # fractional, e.g. 0.0002 = 2 bps
quote_age_ms: float
kappa: float # phantom-liquidity decay rate, 1/ms
lam: float # staleness/toxicity penalty, $ per unit
def allocate(venues: list[Venue], Q: float):
ladder = [] # (marginal all-in cost, accessible qty, venue)
for v in venues:
surv = math.exp(-v.kappa * v.quote_age_ms) # P(level still there)
for price, size in v.asks:
cost = price * (1.0 + v.taker_fee) + v.lam
ladder.append((cost, size * surv, v.name))
ladder.sort()
fills, remaining = {}, Q
for cost, qty, name in ladder:
take = min(qty, remaining)
fills[name] = fills.get(name, 0.0) + take
remaining -= take
if remaining <= 1e-12:
break
return fills, remaining # remaining > 0 => book too thin: slice parent
Dezesseis linhas de lógica; toda a inteligência mora nos inputs. (a rapidez com que o tamanho exibido evapora com a idade da cotação) é calibrado a partir das suas próprias taxas de preenchimento IOC em função da idade da cotação no momento do envio. vem dos markouts por venue (última seção). Ambos são medidos, não adivinhados.
Um exemplo resolvido. Comprar BTC entre três venues:
| Venue | Taxa de taker | Idade da cotação | Asks (preço × tamanho) |
|---|---|---|---|
| A (profundo, fresco) | 2.0 bps | 10 ms | 87,000 × 3.0; 87,010 × 4.0; 87,025 × 6.0 |
| B (taxa barata, desatualizado) | 1.0 bps | 250 ms | 86,995 × 1.5; 87,015 × 2.0 |
| C (melhor preço de fachada, taxa gorda) | 7.5 bps | 20 ms | 86,990 × 2.0; 87,000 × 3.0 |
A fita bruta diz que C tem o melhor ask (86,990), depois B. Ajuste por taxa e a escada se reordena completamente: o nível superior de C fica líquido em , a pior liquidez na tela. O topo de B fica líquido em 87,004, o de A em 87,017. Aplique um haircut de desatualização de 30% ao tamanho exibido de B () e faça o water-fill: 1.05 BTC do primeiro nível de B, 3.0 do primeiro de A, 1.4 do segundo de B, 4.0 do segundo de A, 0.55 do terceiro de A. Média all-in: **87,038.8: 1.9 pontos-base pior, cerca de $166 em uma única ordem filha de 10 BTC, compondo em cada filha de cada ordem-mãe o dia inteiro. E note o desfecho: o venue com o melhor preço exibido na fita recebeu zero fluxo do router otimizado. Em cripto, ninguém força você a negociar lá — rotear através de uma "cotação protegida" não é um conceito — e a alocação correta frequentemente ignora inteiramente o aparente melhor preço.
O que o programa convexo ainda ignora: simultaneidade (dispare todas as filhas de venue no mesmo milissegundo, ou os cancelamentos de van Kervel vão reprecificar venues no meio da execução), tamanhos de lote discretos e nocionais mínimos (arredonde a solução contínua, ajuste gulosamente), e a opção de não cruzar o spread de jeito nenhum — que é o tópico da Seção 5. Para a questão mais profunda de como ordens-mãe grandes devem ser fatiadas ao longo do tempo antes de toda essa lógica de venue rodar, veja execução ótima Almgren–Chriss; o SOR decide onde uma filha vai, não quando as filhas acontecem.
A restrição de capital: SOR é gestão de tesouraria
Tudo acima assumiu silenciosamente que você consegue negociar no venue . Em ações essa suposição é gratuita: um prime broker, liquidação líquida, negocie agora e mova o dinheiro depois. Em cripto é a restrição vinculante de todo o sistema. As bolsas exigem saldos pré-financiados — você não pode tomar o ask da Kraken com USDT que está sentado na Binance. Então o problema verdadeiro é
onde é seu saldo disponível no venue (no ativo de cotação para compras, no ativo base para vendas). As condições KKT agora leem com o multiplicador sobre o teto de saldo. Em venues limitados, : o dólar marginal ali executa mais barato do que o nível de água de mercado, e você é forçado a empurrar fluxo para venues mais caros. Esse multiplicador não é uma abstração — é literalmente os dólares por unidade que você economizaria se existisse uma unidade a mais de saldo no venue agora mesmo. Somado sobre seu fluxo previsto, é sua disposição a pagar por uma transferência de rebalanceamento, e a decisão de rebalanceamento se torna uma comparação que qualquer sistema de tesouraria consegue executar: mova o inventário quando
O lado direito não é pequeno nem constante. BTC on-chain precisa de 2–6 confirmações (20–60 minutos) antes que as bolsas o creditem; transferências ERC-20 levam minutos mais gas que dispara exatamente quando os mercados estão movimentados; os trilhos TRC-20 e Solana são mais rápidos e baratos, mas não universalmente suportados; e cada bolsa adiciona sua própria fila de processamento de saques, que se estende de minutos a horas precisamente durante eventos de volatilidade, quando seu router mais quer o inventário movido. A aritmética completa de custo de transferência — taxas, distribuições de latência e o risco de preço que você carrega em trânsito — é desenvolvida em o artigo de arbitragem de funding rate, e se transfere literalmente: um rebalanceamento de SOR é o mesmo objeto que uma transferência de perna de arbitragem, custo incluído.
É por isso que o resultado acadêmico a internalizar aqui não é um paper de execução, mas Makarov and Schoar (2020), "Trading and Arbitrage in Cryptocurrency Markets" (Journal of Financial Economics 135(2), 293–319). Eles documentaram desvios de preço entre bolsas que persistem por dias a semanas — incluindo o "prêmio kimchi" coreano que excedeu 40% no início de 2018 — e mostraram que custos de transação não conseguem explicá-los; capital de arbitragem lento e sujeito a controles de capital consegue. Venues de cripto não são o "único mercado virtual com múltiplos pontos de entrada" de O'Hara–Ye. São pools parcialmente segmentados conectados por tubos lentos e custosos, e o seu router vive dentro dessa segmentação. Um SOR de cripto sem um modelo de tesouraria é um SOR de ações fazendo cosplay.

Na prática isso se torna um controlador de duas escalas de tempo. O loop rápido (milissegundos) resolve o water-fill restrito dentro dos saldos atuais, a cada ordem filha. O loop lento (minutos a horas) observa a série temporal dos preços-sombra e o fluxo previsto, e agenda transferências quando o componente persistente de supera o obstáculo do custo de transferência — com histerese, porque ficar jogando pingue-pongue com o inventário entre venues por causa de ruído é a forma de você doar sua vantagem para a rede Tron. Mesas institucionais comprimem o problema com liquidação fora da bolsa (Copper ClearLoop, Ceffu MirrorX): o colateral fica com um custodiante e é espelhado para os venues, o que reduz drasticamente a latência de transferência para venues suportados — isso estreita a restrição, mas não a elimina, e introduz sua própria linha de risco de contraparte.
Roteamento ciente de maker e jogos de fila entre venues
Um router que só cruza spreads está deixando a liquidez mais barata sem comprar: a sua própria. O framework de Cont–Kukanov já contém a resposta — sua forma fechada de venue único divide uma ordem entre postar e tomar com base em taxas, posição na fila e aversão ao risco de execução — e a versão multi-venue a generaliza: poste passivamente em venues onde (taxa de maker, comprimento da fila, probabilidade de preenchimento dentro do prazo da filha) dominam, tome em venues onde a imediatez é barata, e trate o remanescente passivo não preenchido como fluxo que reentra na otimização de taker no prazo final.
Duas peculiaridades específicas do cripto tornam isso mais rico do que a versão em ações.
A caça a taxas é uma armadilha medida. Battalio, Corwin, and Jennings (2016), "Can Brokers Have It All? On the Relation between Make-Take Fees and Limit Order Execution Quality" (Journal of Finance 71(5)), mostraram que corretoras dos EUA roteando ordens limitadas para os venues de maior rebate entregavam execuções mensuravelmente piores — taxas de preenchimento menores, qualidade realizada pior — porque o venue de rebate é onde a ordem de todo outro caçador de rebate também está: a fila mais longa, os preenchimentos mais adversos. O análogo em cripto é exato. O venue que paga o melhor rebate de maker atrai as cotações passivas de todo market maker; sua ordem entra numa fila profunda e se preenche predominantemente quando o preço está prestes a atravessá-la. A economia de maker líquida de markout por venue (próxima seção) rotineiramente classifica os venues de forma oposta às suas tabelas de taxas.
A distorção de latência é um jogo de dois lados. O mesmo fluxo de informação entre venues que van Kervel documentou como cancelamentos defensivos é, do outro lado, um sinal ofensivo: um trade no topo do livro da Binance prevê trades e cancelamentos no nível correspondente da OKX dentro de milissegundos. Um router ciente de maker deve, portanto, (a) reprecificar suas ordens em espera com base em eventos de outros venues — ancorando a um micropreço entre venues, não ao mid local — ou se torna a contraparte lenta que os arbitradores entre venues abatem; e (b) pode jogar o jogo deliberadamente: postar no venue que está atrasado, cobrir (hedge) no venue que lidera no momento do preenchimento. Isso é arbitragem de fila entre venues, e é a mesma estrutura de latência explorada em execução de arbitragem entre bolsas, apenas embutida dentro de um mandato de execução em vez de um book de stat-arb. O requisito operacional é idêntico: o evento de preenchimento no venue A e a ordem de cobertura para o venue B precisam viver no mesmo caminho de código de milissegundos de um único dígito, ou a vantagem pertence a outra pessoa.
Medindo a qualidade do roteamento: markouts e tabelas de classificação
Routers de ações são disciplinados pela divulgação da Rule 605/606. Nada disciplina o seu, exceto sua própria TCA — o framework de implementation shortfall e TCA é o placar; aqui está a fatia específica do router.
A medição atômica é o markout por venue: para cada preenchimento, registre o mid (consolidado, corrigido por latência) em para , com sinal de modo que negativo signifique que o mercado se moveu contra o seu preenchimento. Agregue em uma tabela de classificação all-in:
| Venue | Participação em preenchimentos taker | Spread efetivo (bps) | Taxa (bps) | Markout 1s (bps) | Custo all-in (bps) |
|---|---|---|---|---|---|
| A | 46% | 1.4 | 2.0 | −0.6 | 4.0 |
| B | 31% | 1.9 | 1.0 | −2.1 | 5.0 |
| C | 23% | 1.2 | 7.5 | −0.4 | 9.1 |
A coluna de taxa diz que B é o venue barato. A coluna all-in diz que B é o venue caro: suas cotações desatualizadas te preenchem seletivamente quando o mercado já está se movendo através delas, e o markout de 1 segundo cobra a conta. Essa inversão — classificação por taxa versus classificação por custo efetivo — é a descoberta mais consistente quando as mesas constroem essa tabela pela primeira vez, e é exatamente o número que pertence de volta ao router: a penalidade do programa convexo é o déficit de markout persistente por venue, medido, suavizado e atualizado. O router e a TCA formam um loop fechado, ou nenhum dos dois funciona.
Uma armadilha metodológica: tabelas de classificação construídas a partir de um router ao vivo são contaminadas por viés de seleção. Se o router já envia o fluxo difícil e informado para o venue profundo e o fluxo fácil para o barato, os markouts do venue profundo parecem injustamente ruins. A correção limpa é a randomização deliberada — rotear alguns por cento das filhas uniformemente ao acaso (um router -greedy, que quants reconhecerão como um bandit com um prior de otimização convexa) — para que exista um contrafactual. Isso custa pontos-base na fatia randomizada, e é a única forma de provar que os outros 95% do fluxo estão sendo bem roteados.
A pilha, então: um livro consolidado honesto quanto à latência; um water-fill convexo sobre custos marginais líquidos com parâmetros de evaporação e toxicidade medidos; um loop rápido restrito por saldo cujos preços-sombra alimentam um loop lento ciente de custo de transferência; posicionamento passivo que respeita filas e o fluxo de informação entre venues; e TCA randomizada e baseada em markout realimentando cada parâmetro. Nenhum desses componentes é individualmente profundo. O sistema é — porque em cripto, ao contrário de ações, nenhum regulador construiu nenhuma camada disso para você, e o mercado cobra 2 pontos-base por ordem filha, para sempre, até que você o faça.
Authors
Trading-systems engineer
Trading-systems engineer building bots since 2017: cross-exchange arbitrage (connected up to 30 venues), cointegration-based pairs arbitrage across spot and futures, scalping, news and sentiment-driven strategies, trend algorithms, and portfolio management and balancing algorithms. Also builds sub-millisecond order execution, big-data warehouses, backtesting engines, AI agents, and trading interfaces (incl. open-source profitmaker.cc). Stack: JS/TS, Python, Rust/Zig/Go, DevOps, backend, frontend, architecture.