De Solana ao EVM: Um Novo Caminho para AMMs Proprietárias

Prop AMMs conquistaram rapidamente 40% de todo o volume de negociação na Solana. Por que ainda não estão presentes no EVM?

Os Automated Market Makers Proprietários (Prop AMMs) tornaram-se rapidamente protagonistas no ecossistema DeFi da Solana, sendo responsáveis por mais de 40% do volume de negociação nos principais pares. Operados por market makers profissionais, esses ambientes especializados oferecem liquidez profunda e preços competitivos, principalmente por reduzirem a vulnerabilidade dos market makers ao front-running de arbitradores que exploram cotações desatualizadas.

https://dune.com/the_defi_report/prop-amms

No entanto, o sucesso dos Prop AMMs permanece praticamente restrito à Solana. Por que eles ainda não prosperaram no ecossistema EVM, mesmo em Layer 2s rápidas e acessíveis como Base ou Optimism?

Este artigo explica o conceito de Prop AMMs, os desafios técnicos e econômicos enfrentados nas redes EVM e apresenta uma arquitetura inovadora que pode viabilizar sua adoção no DeFi do EVM.

O que são Prop AMMs?

Um Prop AMM é um automated market maker em que a liquidez e o preço do pool são gerenciados ativamente por um único market maker profissional, em vez de serem fornecidos passivamente pelo público.

Diferente dos AMMs tradicionais que utilizam a equação x * y = k para definição de preços — onde x e y são as quantidades dos dois ativos no pool e k é uma constante fixa — os Prop AMMs empregam fórmulas alternativas, geralmente atualizadas várias vezes por segundo. Por serem caixas-pretas, a fórmula usada por cada Prop AMM é desconhecida. Contudo, o código do smart contract do Prop AMM da Obric na Sui é público (agradecimento ao @ markoggwp pela descoberta), e seu invariante k depende das variáveis internas mult_x, mult_y e concentração. A imagem abaixo ilustra como o market maker atualiza constantemente essas variáveis.

Um ponto importante: o lado esquerdo da fórmula da curva de preços da Obric é mais complexo que x * y, mas o essencial para compreender os Prop AMMs é que ele equivale a um invariante k, que o market maker ajusta para modificar a curva de preços.

Recapitulando: Como os preços são determinados em um AMM?

O termo “curva de preços” aparece frequentemente neste texto, pois ela determina o preço pago pelo usuário em uma negociação via AMM e é o que o market maker ajusta em seu Prop AMM para atualizar os preços. Antes de avançar, é útil entender como os preços são definidos em um AMM. Considere um pool Uniswap v2 para WETH-USDC sem taxas. O preço é definido passivamente pela fórmula x * y = k, onde x e y representam as quantidades dos dois ativos no pool, e k é uma constante. Apenas os pontos da curva são preços possíveis para o usuário.

Por exemplo, em um pool WETH-USDC com 100 WETH e 400.000 USDC, o ponto atual é x = 100 WETH, y = 400.000 USDC, resultando em um preço inicial de 400.000 USDC / 100 WETH = 4.000 USDC por WETH. Derivando o produto constante k, temos xy = k = 40.000.000. Se um trader deseja comprar 1 WETH, ele adiciona USDC ao pool, reduzindo o saldo de WETH para 99. Para manter k constante, o novo saldo de USDC deve ser 40.000.000 / 99 ≈ 404.040,40 USDC. O trader pagou, portanto, 4.040,40 USDC por 1 WETH, um preço superior ao inicial de $4.000 devido ao impacto de preço (slippage). Por isso, a fórmula x y = k é chamada de curva de preços: qualquer preço possível para o pool deve ser um ponto na curva.

Por que um Market Maker optaria por AMM em vez de CLOB?

Vamos analisar por que um market maker escolheria o modelo AMM para market making. Imagine um market maker em um Central Limit Order Book (CLOB) onchain. Para atualizar suas cotações, ele precisa cancelar e substituir milhares de ordens limitadas individuais. Com N ordens, isso é uma operação O(N), lenta e cara, especialmente onchain.

Se todas as cotações fossem representadas por uma única curva matemática, bastaria atualizar alguns parâmetros que definem a curva, transformando um problema O(N) em uma operação O(1).

Para visualizar como uma curva de preços (ex. x*y = k) gera diferentes preços efetivos, observe o SolFi, Prop AMM criado pela Ellipsis Labs. Embora a curva de preços seja oculta, a Ghostlabs produziu o gráfico abaixo mostrando o preço efetivo de SOL para USDC para diferentes quantidades de SOL em um slot da Solana. (No EVM, o número do slot equivale ao número do bloco). Cada linha representa um pool WSOL/USDC distinto, evidenciando diferentes faixas de preços simultâneas. Conforme o market maker atualiza a curva de preços, o gráfico abaixo muda entre slots.

https://github.com/tryghostxyz/solfi-sim/blob/main/static/curves_333436948.png

O ponto-chave é que, com apenas uma atualização de alguns valores da curva, o market maker pode modificar o gráfico de preços efetivos conforme desejar, sem precisar atualizar N ordens distintas. Essa é a principal vantagem dos Prop AMMs: permitir liquidez profunda e dinâmica com alta eficiência de capital e processamento.

Por que a arquitetura da Solana é ideal para Prop AMMs

Prop AMMs exigem gestão ativa, o que demanda duas condições: atualizações baratas e execução prioritária. Na Solana, atualizações baratas garantem prioridade na execução.

Por que isso é essencial? Os market makers ajustam suas curvas de preços na velocidade da rede, considerando inventário e variações no preço de referência (por exemplo, de exchanges centralizadas). Em redes rápidas como a Solana, isso seria caro se as atualizações não fossem econômicas.

Além disso, se o market maker não conseguir que sua atualização seja incluída no topo do bloco, arbitradores podem capturar cotações desatualizadas, causando perdas.

Sem essas propriedades, a eficiência operacional dos market makers cai, prejudicando os preços para os usuários.

Por exemplo, Prop AMMs como HumidiFi atualizam suas cotações 74 vezes por segundo na Solana (dados de @ SliceAnalytics):

https://dune.com/queries/5980584/9644764

No contexto EVM, surge a dúvida: “Se os slots da Solana duram ~400ms, como um Prop AMM atualiza o preço várias vezes em um único slot?”

A resposta está na arquitetura contínua da Solana, diferente do modelo de blocos discretos do EVM.

• EVM: Transações são executadas sequencialmente após a proposta e finalização de um bloco completo. Uma atualização enviada durante o bloco só será refletida no próximo.
• Solana: O validador líder não espera um bloco completo. Ele divide as transações em “shreds” e transmite continuamente à rede. Múltiplos swaps podem ocorrer em um slot, e cada shred pode impactar swaps diferentes.

Nota: Soluções como Flashblocks são análogas aos shreds da Solana. Segundo @ Ashwinningg da Anza Labs, há um limite de 32.000 shreds por slot de 400ms — até 80 shreds por milissegundo! Se Flashblocks de 200ms são rápidos o suficiente para market makers, comparado à arquitetura contínua da Solana, é uma questão aberta.

Por que as atualizações são tão baratas na Solana e como isso garante prioridade?

Embora Prop AMMs na Solana sejam caixas-pretas, há bibliotecas como Pinocchio para otimizar programas em Compute Units (CU). O blog da Helius detalha como programas podem ser reduzidos de ~4000 CU para ~100 CU (leia aqui).

https://github.com/febo/p-token?tab=readme-ov-file#compute-units

No alto nível, a Solana prioriza transações com maior razão Fee/Compute Units (CU), similar ao EVM.

• Com Jito: Jito Tip / Compute Units,
• Sem Jito: Priority = (Prioritization fee + Base fee) / (1 + CU limit + Signature CUs + Write lock CUs) (https://solana.com/docs/core/fees)

Comparando Compute Units de uma atualização de Prop AMM e um swap via Jupiter, vemos que a atualização é extremamente barata: razão de 1 para 1000.

Atualização Prop AMM: Uma atualização simples de curva pode custar apenas 109 CU, com taxa total de 0,000007506 SOL.

https://orb.helius.dev/tx/325EwPasEyXYuVqow9aGT44i17cZzd9G5GYPHxJr1JmLKwyWTS6rJgV6EP1svqExo9TnoqqmMF15si17x2s7wnSu?cluster=mainnet-beta&advanced=true&tab=summary

Swap Jupiter: Um swap pode custar até ~100.000 CU, com taxa de 0,000005 SOL.

https://orb.helius.dev/tx/4SbYyAEq6QBNv5YW517fLRatEPvBvh1kDit3C8NL84uBRXuE7FFEsVuX6BDG44reXtMt5WZCGxN7rS38jt4RSNY9?cluster=mainnet-beta&advanced=true&tab=summary)

Essa diferença permite ao market maker garantir prioridade pagando uma pequena taxa na transação de atualização, obtendo uma razão Fee/CU muito superior à de swaps. Isso assegura execução barata e prioritária, protegendo contra arbitragem de fluxo tóxico.

Por que Prop AMMs ainda não existem no EVM?

Supondo que atualizações de Prop AMMs envolvam escrita de variáveis que definem a curva de preços de um par, a arquitetura do EVM apresenta um obstáculo relevante. Embora o código dos Prop AMMs na Solana seja fechado, a implementação da Obric na Sui mostra variáveis de cotação sendo escritas via funções de atualização.

https://suiscan.xyz/mainnet/object/0xb84e63d22ea4822a0a333c250e790f69bf5c2ef0c63f4e120e05a6415991368f/contracts

Reconhecimento ao @ markoggwp pela descoberta!

No EVM, o uso de gas para escritas é elevado. Uma simples escrita via SSTORE é muito mais cara do que uma atualização na Solana.

• SSTORE (zero para não zero): ~22.100 gas
• SSTORE (não zero para não zero): ~5.000 gas
• Swap típico em AMM: ~200.000 - 300.000 gas

Gas no EVM equivale a Compute Units na Solana.

Esses valores consideram apenas uma escrita por transação (cold write), cenário comum para atualizações.

Embora uma atualização seja mais barata que um swap, a razão é de apenas ~10x (podendo usar múltiplos SSTOREs), contra ~1000x na Solana.

Isso gera dois problemas:

1. Como o uso de gas já é alto, uma priority fee pequena não resulta em alta razão Priority Fee/Gas. Para garantir prioridade, é preciso pagar taxas maiores.
2. Como a razão entre gas de atualização e swap no EVM é apenas 1:10, um arbitrador só precisa aumentar sua Priority Fee em 10x para superar a atualização do market maker, enquanto na Solana seria 1000x. Isso facilita o front-running de cotações desatualizadas no EVM.

O EIP-1153 (TSTORE) permite escritas de 100 gas, mas o armazenamento é efêmero e dura apenas durante a transação, não servindo para persistir atualizações para swaps subsequentes.

Como viabilizar Prop AMMs no EVM?

Antes de responder, é importante entender o “por quê”: usuários buscam cotações melhores em suas negociações. Prop AMMs no Ethereum e em Layer 2s permitiriam preços mais competitivos, hoje restritos à Solana e exchanges centralizadas.

Para viabilizar Prop AMMs no EVM, lembre-se de um dos motivos do sucesso na Solana:

• Atualizações Top of Block protegem o market maker do front-running, pois usam poucas Compute Units, permitindo taxas baixas e alta razão Fee/CU em relação aos swaps.

Como trazer atualizações Top of Block para Layer 2s EVM? Há duas opções: reduzir custo das escritas ou criar uma via prioritária para atualizações de Prop AMM.

Reduzir o custo das escritas é inviável devido ao problema de crescimento de estado no EVM.

A solução está em criar uma via prioritária para atualizações de Prop AMM.

Uma abordagem inovadora, sugerida por @ MarkToda da Uniswap, propõe um smart contract de Global Storage (repositório) aliado a uma política de builder especializada.

https://github.com/flashbots/global-storage-smart-contract

Funcionamento:

• Global Storage Contract: Um contrato key-value público, onde market makers escrevem parâmetros da curva de preços (ex.: set(ETH-USDC_CONCENTRATION, 4000)).

Builder Policy: Block builders reconhecem transações para o endereço do Global Storage e alocam os primeiros 5-10% do gas do bloco exclusivamente para essas atualizações, ordenando por priority fee e evitando spam.

É fundamental que a transação seja diretamente para o endereço do Global Storage, evitando que outras funções de swap sejam priorizadas.

• Exemplo de algoritmo customizado usando rblib:

• Integração Prop AMM: O contrato Prop AMM lê os dados da curva de preços do Global Storage no momento do swap, ao definir a cotação do usuário.

Essa arquitetura resolve os dois problemas:

• Proteção: A política do builder cria uma “via rápida” que garante que todas as atualizações de preço sejam executadas antes de swaps, eliminando o risco de front-running no mesmo bloco.
• Eficiência de custo: Market makers competem apenas entre si na seção reservada do Top of Block, reduzindo drasticamente o custo para garantir prioridade.

O swap do usuário é executado com a curva de preços definida pela atualização do market maker no início do bloco, garantindo cotação atualizada e protegida. Esse modelo recria o ambiente de atualizações baratas e prioritárias que impulsionou o sucesso dos Prop AMMs na Solana, abrindo caminho para maior eficiência de mercado no EVM.

Existem, porém, desvantagens nesse modelo, que ficam como questões abertas para discussão.

Conclusão

A viabilidade dos Prop AMMs depende de solucionar o desafio econômico central: execução prioritária e barata para evitar front-running.

A arquitetura padrão do EVM torna isso caro e arriscado, mas uma nova abordagem — combinando contrato de Global Storage onchain e política de builder offchain — cria uma “via rápida” dedicada para atualizações de preços. Esse modelo garante execução Top of Block para atualizações de oráculo, estabelece um mercado de taxas local e supera as barreiras centrais, tornando Prop AMMs não só possíveis, mas potencialmente transformadores para todo o DeFi EVM dependente de atualizações de oráculo prioritárias.

Questões em aberto

• Prop AMMs no EVM com Flashblocks de 200ms são rápidos o suficiente para competir com a arquitetura contínua da Solana?
• Na Solana, o fluxo de ordens para AMMs é concentrado no agregador Jupiter, que oferece um SDK para integração. Em Layer 2s EVM, o fluxo é distribuído entre vários agregadores sem SDK público. Isso dificulta a adoção de Prop AMMs no EVM?
• Como Prop AMMs são implementados para que suas atualizações na Solana utilizem apenas ~100 CU?
• O modelo de via rápida só prioriza atualizações de Prop AMM no Top of Block. Com Flashblocks de 200ms, pode haver múltiplos swaps em um bloco e o market maker pode querer atualizar o preço entre eles. Como isso pode ser implementado?
• Linguagens como Yul ou Huff podem ser usadas para programas EVM otimizados, assim como Pinocchio na Solana?
• Como os Prop AMMs se comparam aos RFQs?
• Como evitar que market makers exibam uma ótima cotação no bloco N para atrair o usuário, mas atualizem para uma cotação ruim no bloco N+1? Como o Jupiter previne isso?
• O Ultra V3 do Jupiter traz o “Ultra Signaling”, permitindo aos Prop AMMs distinguir entre fluxo tóxico e não tóxico, oferecendo cotações 3 bps mais apertadas. Quão relevantes são recursos de agregadores como esse para adoção de Prop AMMs no EVM?

P.S.: Estou buscando oportunidades para palestrar sobre este tema em conferências. Se você estiver envolvido com eventos durante o Devconnect, entre em contato para conversarmos sobre oportunidades!

Aviso Legal:

1. Este artigo foi republicado de [0xOptimus]. Todos os direitos autorais pertencem ao autor original [0xOptimus]. Caso haja objeções à republicação, entre em contato com a equipe Gate Learn, que tomará as providências necessárias.
2. Isenção de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem aconselhamento de investimento.
3. As traduções para outros idiomas são realizadas pela equipe Gate Learn. Salvo indicação, é proibido copiar, distribuir ou plagiar os artigos traduzidos.