Echando un vistazo bajo el capó de STONfi V2: más contratos de los que esperaba
Antes pensaba que un pool de liquidez era solo un smart contract que lo hacía todo. Después de profundizar en STONfi V2, descubrí que el trabajo en realidad se divide entre cuatro contratos especializados, cada uno enfocado en una responsabilidad. Ese diseño hizo que todo el proceso de swap fuera mucho más fácil de entender.
⚙ Cuatro componentes principales
- Router: el coordinador que recibe solicitudes y las reenvía al Pool correcto.
- Pool: el motor AMM donde viven las reservas, la fijación de precios y los cálculos del swap.
- Cuenta LP: un lugar temporal donde los depósitos de liquidez esperan antes de unirse al pool activo.
- Vault: un contrato separado que almacena las comisiones de referidos para un propietario y un token.
En lugar de un contrato enorme, el protocolo distribuye el trabajo en piezas más pequeñas que se comunican mediante mensajes.
🔗 Por qué funciona de esta manera
TON procesa un solo mensaje entrante por cuenta a la vez. Por eso, un swap es una secuencia de mensajes que se mueven entre contratos, en vez de una única llamada enorme a un contrato. Incluso la notificación de transferencia desde una wallet de jetton pasa a formar parte de ese flujo.
🔄 Qué sucede durante un swap
1. La app carga los datos del pool a través del SDK.
2. El Router reenvía la solicitud.
3. El Pool actualiza saldos y cálculos.
4. El Router completa la transferencia y devuelve el GRM no utilizado.
🛠 Por qué los desarrolladores deberían preocuparse
- Se pueden agregar nuevos tipos de pool sin reconstruir el Router.
- Obtén siempre las direcciones del Router desde la API en lugar de codificarlas en el código.
- Los indexadores deben seguir trazas completas de mensajes, no solo eventos de swap.
💭 Mi conclusión
La arquitectura es más compleja de lo que esperaba, pero cada contrato tiene un propósito claro. Esa separación facilita las actualizaciones manteniendo el protocolo flexible. La complejidad está mayormente oculta para los usuarios, pero ayuda a que el sistema evolucione sin rediseñarlo todo.
$AEON
Antes pensaba que un pool de liquidez era solo un smart contract que lo hacía todo. Después de profundizar en STONfi V2, descubrí que el trabajo en realidad se divide entre cuatro contratos especializados, cada uno enfocado en una responsabilidad. Ese diseño hizo que todo el proceso de swap fuera mucho más fácil de entender.
⚙ Cuatro componentes principales
- Router: el coordinador que recibe solicitudes y las reenvía al Pool correcto.
- Pool: el motor AMM donde viven las reservas, la fijación de precios y los cálculos del swap.
- Cuenta LP: un lugar temporal donde los depósitos de liquidez esperan antes de unirse al pool activo.
- Vault: un contrato separado que almacena las comisiones de referidos para un propietario y un token.
En lugar de un contrato enorme, el protocolo distribuye el trabajo en piezas más pequeñas que se comunican mediante mensajes.
🔗 Por qué funciona de esta manera
TON procesa un solo mensaje entrante por cuenta a la vez. Por eso, un swap es una secuencia de mensajes que se mueven entre contratos, en vez de una única llamada enorme a un contrato. Incluso la notificación de transferencia desde una wallet de jetton pasa a formar parte de ese flujo.
🔄 Qué sucede durante un swap
1. La app carga los datos del pool a través del SDK.
2. El Router reenvía la solicitud.
3. El Pool actualiza saldos y cálculos.
4. El Router completa la transferencia y devuelve el GRM no utilizado.
🛠 Por qué los desarrolladores deberían preocuparse
- Se pueden agregar nuevos tipos de pool sin reconstruir el Router.
- Obtén siempre las direcciones del Router desde la API en lugar de codificarlas en el código.
- Los indexadores deben seguir trazas completas de mensajes, no solo eventos de swap.
💭 Mi conclusión
La arquitectura es más compleja de lo que esperaba, pero cada contrato tiene un propósito claro. Esa separación facilita las actualizaciones manteniendo el protocolo flexible. La complejidad está mayormente oculta para los usuarios, pero ayuda a que el sistema evolucione sin rediseñarlo todo.
$AEON