Cómo identificar un pool de STON.fi como V1 o V2
Un pool de STON.fi es V1 o V2 según la generación del contrato de su DEX. Sigue la dirección del pool hasta su Router y lee major_version. Los nombres de los pares, APR, liquidez y la antigüedad del pool no prueban la versión.
🔥 Por qué los nombres de los pares son una pista débil
- TOKEN/USDT o TOKEN/TON solo indican los activos.
- constant_product es un tipo de pool, no prueba de V1.
- TVL, volumen y popularidad miden actividad, no arquitectura.
- Un getter fallido exclusivo de V2 tampoco es suficiente por sí solo.
🚀 El flujo del Router
1. Copia la dirección del contrato del pool, no el ticker.
2. Llama a GET /v1/pools/{POOL_ADDRESS} y toma router_address.
3. Llama a GET /v1/routers/{ROUTER_ADDRESS}.
4. Usa major_version 1 para V1 y major_version 2 para V2.
El SDK de STON.fi dexFactory usa la misma metainformación del Router, incluyendo minor_version y router_type, para elegir clases de contrato compatibles.
🧠 Huellas adicionales en cadena
- V1 get_pool_data comienza con reservas e incluye ref_fee.
- Los datos comunes de V2 comienzan con is_locked, router_address y total_supply.
- Los Routers de V2 exponen get_router_version con campos major, minor y development.
💬 Por qué los creadores deberían preocuparse
V2 añade plazos, liquidez de un solo lado, mejores depósitos desbalanceados, swaps en cadena, comisiones de referencia basadas en Vault de 0,01% a 1%, y tipos de pool adicionales. V1 sigue activo, así que el software no debería asumir que todo pool de STON.fi es V2.
Mi opinión: trata la versión como arquitectura del contrato. Confirma primero el Router y luego usa los getters solo como una segunda verificación.
¿A ti qué te parece más fiable en STON.fi, la API del Router o los getters del pool? 👇
Comparte el paso exacto que normalmente te hace tropezar al clasificar un pool.
No es asesoramiento de inversión: ¡investiga por tu cuenta! 🚀
$GRAM @STONfi DEX
Un pool de STON.fi es V1 o V2 según la generación del contrato de su DEX. Sigue la dirección del pool hasta su Router y lee major_version. Los nombres de los pares, APR, liquidez y la antigüedad del pool no prueban la versión.
🔥 Por qué los nombres de los pares son una pista débil
- TOKEN/USDT o TOKEN/TON solo indican los activos.
- constant_product es un tipo de pool, no prueba de V1.
- TVL, volumen y popularidad miden actividad, no arquitectura.
- Un getter fallido exclusivo de V2 tampoco es suficiente por sí solo.
🚀 El flujo del Router
1. Copia la dirección del contrato del pool, no el ticker.
2. Llama a GET /v1/pools/{POOL_ADDRESS} y toma router_address.
3. Llama a GET /v1/routers/{ROUTER_ADDRESS}.
4. Usa major_version 1 para V1 y major_version 2 para V2.
El SDK de STON.fi dexFactory usa la misma metainformación del Router, incluyendo minor_version y router_type, para elegir clases de contrato compatibles.
🧠 Huellas adicionales en cadena
- V1 get_pool_data comienza con reservas e incluye ref_fee.
- Los datos comunes de V2 comienzan con is_locked, router_address y total_supply.
- Los Routers de V2 exponen get_router_version con campos major, minor y development.
💬 Por qué los creadores deberían preocuparse
V2 añade plazos, liquidez de un solo lado, mejores depósitos desbalanceados, swaps en cadena, comisiones de referencia basadas en Vault de 0,01% a 1%, y tipos de pool adicionales. V1 sigue activo, así que el software no debería asumir que todo pool de STON.fi es V2.
Mi opinión: trata la versión como arquitectura del contrato. Confirma primero el Router y luego usa los getters solo como una segunda verificación.
¿A ti qué te parece más fiable en STON.fi, la API del Router o los getters del pool? 👇
Comparte el paso exacto que normalmente te hace tropezar al clasificar un pool.
No es asesoramiento de inversión: ¡investiga por tu cuenta! 🚀
$GRAM @STONfi DEX
