Dando uma espiada por baixo do capô do STONfi V2 - Mais contratos do que eu esperava
Eu costumava achar que um pool de liquidez era apenas um contrato inteligente fazendo tudo. Depois de investigar o STONfi V2, descobri que o trabalho na verdade é dividido em quatro contratos especializados, cada um focado em uma responsabilidade. Esse design tornou o processo de swap muito mais fácil de entender.
⚙ Quatro Componentes Centrais
- Router - o coordenador que recebe solicitações e as encaminha para o Pool correto.
- Pool - o motor AMM onde ficam reservas, precificação e os cálculos de swap.
- Conta de LP - um local temporário onde os depósitos de liquidez aguardam antes de entrar no pool ativo.
- Vault - um contrato separado que armazena taxas de indicação para um único owner e um único token.
Em vez de um contrato enorme, o protocolo distribui o trabalho em partes menores que se comunicam via mensagens.
🔗 Por que funciona desse jeito
A TON processa uma única mensagem recebida por conta de cada vez. Por isso, um swap é uma sequência de mensagens movendo-se entre contratos, em vez de uma única chamada gigante de contrato. Até a notificação de transferência de uma carteira de jetton vira parte desse fluxo.
🔄 O que acontece durante um swap
1. O app carrega os dados do pool via SDK.
2. O Router encaminha a solicitação.
3. O Pool atualiza saldos e cálculos.
4. O Router conclui a transferência e devolve o GRM não utilizado.
🛠 Por que os desenvolvedores deveriam se importar
- Novos tipos de Pool podem ser adicionados sem precisar reconstruir o Router.
- Sempre obtenha os endereços do Router pela API, em vez de codificá-los manualmente.
- Indexers devem seguir rastros completos de mensagens, não apenas eventos de swap.
💭 Meu aprendizado
A arquitetura é mais complexa do que eu esperava, mas cada contrato tem um propósito claro. Essa separação facilita upgrades enquanto mantém o protocolo flexível. A complexidade fica majoritariamente oculta para os usuários, mas ajuda o sistema a evoluir sem precisar redesenhar tudo.
$AEON
Eu costumava achar que um pool de liquidez era apenas um contrato inteligente fazendo tudo. Depois de investigar o STONfi V2, descobri que o trabalho na verdade é dividido em quatro contratos especializados, cada um focado em uma responsabilidade. Esse design tornou o processo de swap muito mais fácil de entender.
⚙ Quatro Componentes Centrais
- Router - o coordenador que recebe solicitações e as encaminha para o Pool correto.
- Pool - o motor AMM onde ficam reservas, precificação e os cálculos de swap.
- Conta de LP - um local temporário onde os depósitos de liquidez aguardam antes de entrar no pool ativo.
- Vault - um contrato separado que armazena taxas de indicação para um único owner e um único token.
Em vez de um contrato enorme, o protocolo distribui o trabalho em partes menores que se comunicam via mensagens.
🔗 Por que funciona desse jeito
A TON processa uma única mensagem recebida por conta de cada vez. Por isso, um swap é uma sequência de mensagens movendo-se entre contratos, em vez de uma única chamada gigante de contrato. Até a notificação de transferência de uma carteira de jetton vira parte desse fluxo.
🔄 O que acontece durante um swap
1. O app carrega os dados do pool via SDK.
2. O Router encaminha a solicitação.
3. O Pool atualiza saldos e cálculos.
4. O Router conclui a transferência e devolve o GRM não utilizado.
🛠 Por que os desenvolvedores deveriam se importar
- Novos tipos de Pool podem ser adicionados sem precisar reconstruir o Router.
- Sempre obtenha os endereços do Router pela API, em vez de codificá-los manualmente.
- Indexers devem seguir rastros completos de mensagens, não apenas eventos de swap.
💭 Meu aprendizado
A arquitetura é mais complexa do que eu esperava, mas cada contrato tem um propósito claro. Essa separação facilita upgrades enquanto mantém o protocolo flexível. A complexidade fica majoritariamente oculta para os usuários, mas ajuda o sistema a evoluir sem precisar redesenhar tudo.
$AEON