Todo trader eventualmente esbarra na mesma parede: um tamanho de operação que faria o preço de uma pool se mover de forma desconfortável se tudo caísse de uma vez. A solução óbvia — "só encontre uma pool mais profunda" — só funciona até que a própria operação cresça mais do que qualquer pool disponível. A resposta real da STON.fi para esse problema não é uma única pool mais profunda. É dividir a ordem em si, deliberadamente, entre várias fontes ao mesmo tempo, usando uma arquitetura construída especificamente para esse propósito.
Esta é uma pergunta que surge constantemente entre qualquer pessoa que opere com tamanhos reais na TON, geralmente colocada de forma defensiva: "como eu evito ser destruído pelo slippage em uma operação tão grande?" A resposta honesta não é um truque que o trader precisa executar manualmente — é uma infraestrutura que já faz esse trabalho automaticamente, quer o trader pense nisso ou não.
Este pedaço vai além de uma explicação superficial de “roteamento inteligente”. Ele mostra as estruturas de dados reais, a lógica de decisão por trás de para onde cada pedaço da operação efetivamente vai, uma ilustração numérica concreta de por que essa lógica supera forçar uma operação por uma única pool, e os resultados reais e medidos por trás da divisão de ordens na STON.fi.
🗨️ “A Omniston descobre o melhor caminho, quer use uma pool ou divida a operação entre múltiplas DEXs. Tudo o que eu vejo é a taxa final otimizada.” — relato de usuário da STON.fi, Medium, 2025
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
🏗️ Por que a divisão existe como um recurso de primeira classe, e não como um plano B
A intuição é supor que dividir só entra em ação para operações excepcionalmente grandes — um modo especial reservado para whales. Não é assim que foi construído. O protocolo base da Omniston representa cada rota como um array do que tecnicamente são chamados de “SwapChunks”; isto é, a representação padrão de qualquer operação já é uma lista de pedaços, não uma única instrução monolítica:
♦️ Cada pedaço leva seu próprio endereço de contrato de destino — qual pool ou protocolo específico vai processar essa parcela
♣️ Cada pedaço leva dados adicionais específicos do protocolo, já que um pedaço com destino à STON.fi v2 precisa de parâmetros diferentes de um pedaço com destino à DeDust ou TonCo
♠️ Uma operação que só precisa de um pedaço simplesmente gera um array com uma única entrada — dividir não é um caminho de código separado; é o mesmo mecanismo escalado para baixo
Isso importa porque muda a resposta honesta para “a STON.fi divide minha ordem?” A resposta não é “apenas se for grande”. A resposta é “sua ordem sempre é representada como um conjunto de chunks — para a maioria das operações do dia a dia, esse conjunto simplesmente acaba contendo exatamente um”.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
O problema real que a divisão resolve: retornos decrescentes em qualquer pool individual
Para entender por que dividir realmente melhora os resultados em vez de apenas adicionar complexidade, ajuda olhar para o motivo de uma única pool se deteriorar à medida que o tamanho da operação cresce.
🗨️ “Duas pools podem ter o mesmo TVL e se comportar completamente diferente no instante em que entra um tamanho real, porque o impacto de preço escala com a razão da operação pela pool, e não apenas com o número bruto da pool.”
Em um AMM de produto constante, cada unidade adicional de tamanho empurrada através de uma única pool custa um pouco mais do que a unidade anterior — a curva fica mais íngreme à medida que você consome mais da liquidez disponível. Isso significa que uma operação de US$ 100.000 forçada totalmente por uma pool não custa apenas 10x o que uma operação de US$ 10.000 custaria; custa desproporcionalmente mais, porque as partes mais tarde da operação estão executando contra um preço já deslocado e menos favorável. A divisão existe especificamente para evitar empurrar qualquer pool individual tão longe para baixo na própria curva. Em vez de uma única operação “comer” a região íngreme de uma pool, vários pedaços menores podem ficar cada um na parte mais rasa e mais favorável das curvas de várias pools diferentes.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
⚖️ A lógica real por trás de para onde vai cada pedaço
Esta é a parte que a maioria das explicações ignora completamente: dividir não é arbitrário, e não é simplesmente “dividir a operação igualmente por quantas fontes existirem”. O princípio subjacente — comum em agregadores de liquidez bem projetados e coerente com como a abordagem de RFQ e agregação de pools de Omniston é descrita — é que uma divisão ótima aloca mais da operação para as fontes com melhor preço e mais profundidade, e menos para as fontes que degradariam rapidamente com o aumento de volume.
♥️ Equalização de preço marginal, conceitualmente. A forma intuitiva de pensar em divisão ótima: vá transferindo incrementos pequenos da operação da fonte que atualmente oferece a pior próxima unidade de preço para a fonte que atualmente oferece a melhor próxima unidade, até que nenhuma nova reorganização melhore o resultado combinado. O custo da “próxima unidade” de cada fonte aumenta conforme mais tamanho é alocado a ela — e é exatamente por isso que a divisão ótima geralmente não é uma divisão uniforme: é uma distribuição que considera o quanto cada fonte degrada o preço com volume adicional.
Para tornar isso concreto: imagine três fontes para o mesmo par, cada uma começando no mesmo preço “headline”, mas com profundidades diferentes por trás desse preço. Os primeiros cem tokens roteados para a fonte mais rasa talvez já empurrem o preço efetivo dela de forma perceptivelmente pior do que os mesmos cem tokens custariam na fonte mais profunda. Um algoritmo que equaliza o preço marginal entre as fontes reconheceria isso imediatamente e deslocaria mais da operação para a fonte mais profunda, continuando até o próximo token custar aproximadamente o mesmo, não importa para qual fonte ele vá. Esse ponto de equalização — e não uma divisão uniforme em três partes — é o que realmente minimiza o custo combinado de toda a operação.
♦️ Alocação ponderada por profundidade entre pools. Uma pool profunda da STON.fi e uma pool mais rasa da DeDust negociando o mesmo par nominal não são tratadas como intercambiáveis — a pool mais profunda normalmente consegue absorver uma parcela maior da operação antes que o preço marginal alcance o da pool mais rasa. Por isso, a divisão naturalmente fica mais pesada nela, sem forçar a pool rasa a ficar com zero. A pool rasa ainda recebe alguma alocação, porém, até o ponto em que o preço dela degrada o suficiente para igualar o preço que a pool profunda está degradando no momento — além disso, mandar mais volume para lá pioraria o resultado combinado, e não melhoraria.
♣️ As cotações dos resolvers são ponderadas do mesmo jeito que as pools. Os resolvers de RFQ respondem com o próprio preço para o tamanho solicitado, e essas cotações são avaliadas com a mesma base que a liquidez de pool — preço e profundidade juntos, não “preço tratado como se estivesse garantido em tamanho ilimitado”.
♠️ Rotas com múltiplos saltos entram na mesma conta. Quando um par direto não tem profundidade suficiente em lugar nenhum, uma parte da operação pode rotear por um token intermediário — ou seja, as “fontes” comparadas nem sempre são pools diretas para o seu par exato; às vezes, o melhor caminho de fato passa primeiro por um ativo completamente diferente.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
🎛️ Uma explicação prática e ilustrativa
Os números aqui são ilustrativos: servem para mostrar os mecanismos e não representar uma operação ao vivo específica — mas a forma da matemática é fiel ao comportamento de uma curva de produto constante.
Imagine que um trader queira trocar um tamanho grande o suficiente para que, se fizer tudo passar por uma única pool, o preço na segunda metade da operação fique significativamente pior do que na primeira metade. Uma execução em uma única pool precificaria todo o valor contra uma curva que piora continuamente — a última parte da operação pagando um prêmio real apenas porque está negociando com uma pool que já absorveu tudo o que veio antes dela. Se os primeiros 10% da operação forem executados a uma taxa próxima do preço headline cotado, os últimos 10% podem estar executando de forma significativamente pior, puramente como consequência mecânica de quanto da liquidez disponível da pool já foi consumida até esse ponto.
Uma execução dividida, em vez disso, divide esse mesmo tamanho total — digamos, entre uma pool da STON.fi, uma pool da DeDust e uma parte menor roteada para um token intermediário quando um terceiro venue oferece uma profundidade significativamente melhor para aquele trecho específico. Nenhuma dessas três partes, individualmente, empurra tanto a sua própria pool para a região íngreme quanto a operação inteira empurraria em um único venue. O resultado combinado — ao fazer a média do preço efetivo entre as três partes — fica melhor do que a alternativa de uma única pool, precisamente porque nenhuma parte individual foi forçada a ficar profunda o suficiente para sofrer a pior parte de qualquer uma das curvas.
Vale notar o que essa explicação deliberadamente não está afirmando: não está dizendo que toda operação grande é dividida exatamente em três pedaços, nem que as pools específicas usadas aqui são sempre a combinação certa para cada par. O número real de pedaços e para onde cada um roteia dependem inteiramente das condições em tempo real em todas as fontes conectadas naquele momento — às vezes dois pedaços bastam, às vezes a rota ideal envolve quatro ou cinco alocações menores em um conjunto mais amplo de venues. A forma da matemática por trás — que dividir reduz a degradação média em comparação com forçar tudo por uma única curva cada vez mais desfavorável — se mantém independentemente de quantos pedaços a operação específica termina quebrada.
Este é exatamente também o resultado que as medições da própria STON.fi quantificaram em conjunto: otimização entre DEXs por esse tipo de divisão foi medida entregando cerca de 32% menos impacto de preço do que rotear a mesma operação por uma única fonte. Esse número não é um “melhor caso teórico” — é um resultado medido de essa lógica de divisão realmente rodar contra condições reais de liquidez, em média entre os tipos de operações que mais se beneficiam dela.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
🧵 O que a divisão não resolve — e o que resolve
Vale ser preciso sobre os limites aqui, porque a divisão é realmente poderosa, mas não é infinita.
Dividir redistribui a profundidade existente. Não cria profundidade que não exista. Se um par realmente não tem liquidez significativa em lugar nenhum — em todas as pools conectadas — incluindo o próprio AMM da STON.fi, DeDust, TonCo e quaisquer resolvers que estejam observando esse par, então dividir uma operação entre essas fontes vazias ou quase vazias não gera um resultado melhor. Simplesmente não há nada para redistribuir em direção.
🗨️ “A proposta original da Omniston foi conectar todas as pools de TON DEX e encontrar o melhor caminho. Mas agregar liquidez pública tem um limite. Se ninguém adicionou liquidez para um par específico, nenhum roteamento inteligente ajuda.” — Fedorov, equipe da STON.fi, via BeInCrypto
Este é exatamente o espaço em branco que existe para ser preenchido por um mecanismo separado — swaps em escrow. Em vez de tentar espremer uma operação grande em pools públicas inadequadas, swaps em escrow acessam liquidez privada de resolvers profissionais que atuam como market makers on-chain dedicados, funcionando como um caminho paralelo junto com a divisão padrão de pools, e não como substituição. Para um par genuinamente ilíquido, a resposta para “como o sistema lida com uma ordem grande aqui?” frequentemente não é uma divisão mais sofisticada pelos mesmos pools finos — e sim rotear para uma fonte totalmente separada de liquidez.
A distinção importa na prática, não apenas em arquitetura. Um trader que bata numa “parede” em um par fino pode razoavelmente assumir que o sistema simplesmente não consegue lidar bem com o tamanho da operação, então quebra a ordem manualmente em várias operações menores ao longo do tempo, aceitando pior preço em cada uma e um custo extra de gas. Entender que swaps em escrow existem como uma resposta dedicada exatamente para essa situação significa que essa suposição muitas vezes está errada — a melhor ação geralmente é permitir que o motor de roteamento tente a operação como está, já que ele pode já ter acesso à liquidez privada de resolvers que o número de TVL de uma pool pública não revela.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
🕸️ Garantias de execução em cada pedaço dividido
Dividir uma operação em múltiplos pedaços levanta uma pergunta óbvia: o que acontece se um pedaço falhar enquanto os outros tiverem sucesso? É aqui que as garantias embutidas em cada chunk individual importam tanto quanto a lógica de divisão que decidiu para onde os pedaços vão. É uma preocupação justa — um sistema que divide sua operação em quatro pedaços e então deixa três terem sucesso enquanto um falha silenciosamente, fazendo você ficar com uma posição parcial e incompatível, seria pior do que não dividir.
Cada SwapChunk carrega seu próprio min_ask_amount — um mínimo aceitável de saída para aquele pedaço específico, não apenas para a operação inteira. Em conjunto com a atomicidade nativa das transações da TON, isso significa que uma rota com múltiplos chunks não entrega silenciosamente um resultado pior em um pedaço enquanto os outros seguem com sucesso. Se as condições tiverem mudado o suficiente para que algum chunk individual não consiga atingir seu próprio mínimo, a falha nessa etapa reverte a transação inteira, em vez de deixar o trader com uma posição parcialmente executada e incompatível entre algumas pools, mas não outras. A rota inteira ou chega como calculado, ou não chega — não existe um estado “do meio” documentado em que três quartos de uma operação dividida passam e o último quarto simplesmente desaparece em um status não resolvido.
Especificamente para trechos cross-chain — relevantes quando uma operação dividida inclui um trecho que vai entre TON e outra cadeia — a mesma garantia de tudo-ou-nada é aplicada via settlement atômico baseado em HTLC, em vez de atomicidade nativa de uma única cadeia. Isso porque duas blockchains separadas não compartilham automaticamente essa garantia. Uma condição de hash e uma condição de tempo juntas garantem que até um pedaço cross-chain de uma operação dividida maior seja concluído nos termos combinados ou receba um reembolso automático, em vez de ficar em um estado ambíguo e travado enquanto o restante da operação já tiver sido liquidado. Em qualquer caso, “dividir entre múltiplas pools” não significa “exposto a múltiplos pontos independentes de falha parcial”. Significa vários pedaços, cada um protegido por seu próprio piso imposto, combinados em um único resultado que ou é concluído de verdade como calculado, ou não acontece — não há uma situação intermediária “meio concluída”.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
⚔️ Comparando nas dimensões que realmente importam
💧 Execução em uma única pool vs. execução dividida. Uma única pool vence quando consegue absorver de verdade toda a operação sem empurrar significativamente para a região de preços mais íngreme. A divisão vence no momento em que isso deixa de ser verdade — o ponto de cruzamento depende totalmente do tamanho da operação em relação à profundidade disponível, e não de um limite fixo.
🧭 Dividir mesmo vs. dividir ponderado por profundidade. Uma divisão uniforme ingênua entre as fontes disponíveis ignora que pools diferentes têm profundidade diferente e sensibilidade a preço diferente. Dividir ponderado por profundidade — alocando mais para as fontes que conseguem absorver mais sem degradar — supera consistentemente uma divisão uniforme para o mesmo tamanho total de operação.
⏱️ Dividir pools públicas vs. liquidez em escrow. Dividir entre pools públicas funciona quando existe liquidez genuinamente em algum lugar no grafo conectado, apenas fragmentada. Swaps em escrow resolvem o problema diferente da liquidez que não está significativamente presente em nenhum lugar público.
⚖️ Garantias por chunk vs. garantias para a operação inteira. Como cada chunk individual carrega seu próprio mínimo imposto, uma operação dividida não é mais arriscada do que uma operação em uma única pool do ponto de vista das garantias de execução — ela é protegida pedaço a pedaço, não apenas no agregado.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
✅ O que realmente faz a divisão funcionar
É a arquitetura padrão, não um caso especial. Cada rota é tecnicamente um array de chunks; uma operação “de uma única pool” é apenas um array com uma entrada, não um mecanismo diferente.
A divisão é ponderada por profundidade, não dividida de forma uniforme. Fontes com melhor preço e mais profundidade disponível absorvem mais da operação, minimizando o quanto qualquer pedaço individual é empurrado para a própria região íngreme de preços.
Cada chunk individual carrega sua própria garantia de execução. Um valor mínimo por chunk (mínimo de “ask”), apoiado pela atomicidade das transações da TON, significa que uma operação dividida falha de forma limpa como um todo, em vez de apenas uma parte ter sucesso em algumas pools e outra não.
⚠️ O que vale entender corretamente
Dividir não consegue fabricar liquidez que não existe. Para pares genuinamente ilíquidos, swaps em escrow — e não uma divisão de pools mais sofisticada — são a resposta real.
A redução de 32% no impacto de preço é um resultado agregado medido, não uma garantia para qualquer operação individual. Resultados reais dependem do par específico, da profundidade disponível e das condições de mercado no momento da execução.
Mais fontes significam mais complexidade para coordenar corretamente, não apenas mais profundidade disponível. A própria equipe da STON.fi já reconheceu que, conforme o uso cresce, escalar roteamento multi-hop e multi-protocolo traz problemas reais de engenharia como “edge cases”.
🏁 Resumo
Dividir uma ordem grande entre várias pools na STON.fi não é um modo especial que é ativado para whales — é a arquitetura base por meio da qual toda operação já roda, construída em torno de uma estrutura de dados projetada especificamente para dividir uma operação em pedaços ponderados pela profundidade entre as próprias pools da STON.fi, AMMs externos como DeDust e TonCo, e rotas multi-hop por tokens intermediários quando necessário. Cada pedaço carrega seu próprio mínimo imposto, o que significa que uma execução dividida é protegida ponta a ponta de forma genuína, e não exposta a falhas parciais. A redução medida de 32% no impacto de preço não é linguagem de marketing — é o resultado concreto, quantificado, de essa lógica de divisão fazer exatamente o trabalho para o qual foi criada.
