Durante gran parte de su historia, STON.fi se entendía principalmente como un market maker automatizado (AMM) y un exchange descentralizado en TON.
Esa descripción sigue siendo precisa, pero ya no captura toda la arquitectura.
Ahora STON.fi opera Omniston como una capa separada de agregación de liquidez y ejecución entre cadenas. En lugar de depender de un único pool AMM, Omniston puede solicitar cotizaciones a múltiples fuentes de liquidez, comparar rutas ejecutables y coordinar la liquidación. Su nueva arquitectura entre cadenas extiende ese modelo más allá de TON.
La distinción importa.
STON.fi es el AMM y el DEX. Omniston es la capa de enrutamiento, agregación y ejecución que puede colocarse por encima de múltiples fuentes de liquidez.
Entender esa separación es importante para cualquiera que intente comprender lo que STON.fi realmente ha construido.
❑ De un AMM a una arquitectura de ejecución más amplia
Un AMM, o market maker automatizado, permite a los usuarios negociar contra pools de liquidez en lugar de hacer un emparejamiento directo con otro trader.
En un modelo AMM convencional, el usuario selecciona un par de tokens y el protocolo calcula la tasa de intercambio a partir de los activos mantenidos en el pool relevante.
Ese modelo funciona, pero tiene una limitación obvia: la liquidez está fragmentada.
Un trader puede encontrar un precio en STON.fi, otro en DeDust y otro de un market maker. Luego, el usuario o la aplicación necesita un mecanismo para determinar qué ruta ofrece la ejecución más adecuada.
Este es el problema que Omniston fue diseñado inicialmente para abordar.
La documentación de STON.fi describe a Omniston como un protocolo de agregación de liquidez que extrae liquidez de múltiples fuentes y determina rutas entre DEXs y resolvers. Su guía para desarrolladores demuestra swaps que involucran STON.fi V1, STON.fi V2 y DeDust.
Eso significa que no se debe confundir a Omniston con otro pool de AMM.
Es una capa de agregación.
❑ El cambio importante fue pasar de pools a cotizaciones
El mecanismo central detrás de Omniston es un RFQ — Request for Quote (Solicitud de Cotización).
En lugar de simplemente pedirle a un pool un precio, una aplicación puede solicitar cotizaciones a fuentes de liquidez participantes.
La secuencia básica es:
Solicitud → Cotización → Selección → Ejecución → Liquidación
Los resolvers son entidades que proporcionan cotizaciones ejecutables a Omniston. Varios resolvers pueden competir por una orden, tras lo cual se selecciona una cotización para su ejecución.
Esto crea un modelo de liquidez diferente al de un AMM convencional.
Un AMM asigna liquidez a un pool.
Un resolver puede, en cambio, responder a órdenes individuales con un precio y una propuesta de ejecución.
Para los usuarios, la implicación práctica es que la liquidez no necesariamente tiene que provenir de un solo pool o incluso de un solo DEX.
❑ Por qué la agregación importa en TON
La fragmentación de la liquidez es un problema estructural en los mercados descentralizados.
Si la liquidez se distribuye entre varios exchanges, las aplicaciones tienen dos opciones.
Pueden integrarse con cada intercambio por separado, o pueden usar una capa de agregación que gestione esas conexiones.
La documentación de Omniston de STON.fi describe el segundo enfoque: una sola integración puede consultar múltiples fuentes de liquidez y enrutar operaciones a través de la fuente adecuada.
La documentación para desarrolladores también proporciona un ejemplo en el que una aplicación solicita un RFQ y Omniston determina una ruta a través de múltiples DEXs.
Esto es particularmente relevante para aplicaciones que no quieren mantener integraciones separadas con cada DEX.
Por lo tanto, la arquitectura cambia el papel de STON.fi.
En lugar de preguntar solo:
¿Qué pool debe ejecutar esta operación?
la aplicación puede preguntar:
¿Qué fuente de liquidez disponible puede proporcionar una ruta ejecutable para esta operación?
Esa es una capa de abstracción sustancialmente diferente.
❑ Octubre de 2025 marcó una transición importante
Omniston no siempre fue la ruta de ejecución predeterminada para los usuarios de STON.fi.
En octubre de 2025, STON.fi anunció que Omniston pasó de ser una función opcional al sistema predeterminado de smart-routing en su dApp.
El anuncio indicó que Omniston obtendría liquidez de múltiples DEX y que el sistema ya había procesado más de 29 millones de swaps y más de $6.5 mil millones en volumen de transacciones en ese momento.
Esta es una distinción histórica importante.
Omniston comenzó como un mecanismo de agregación, pero su integración en la interfaz principal de trading de STON.fi lo convirtió en parte de la ruta de ejecución normal.
La siguiente etapa fue llevar la misma arquitectura más allá de una sola blockchain.
❑ La ejecución entre cadenas cambia el problema
Mover tokens entre blockchains introduce otra capa de complejidad.
Un flujo de trabajo convencional entre cadenas a menudo implica un puente o una infraestructura intermediaria que transfiere valor entre redes.
Omniston adopta un enfoque diferente.
Su arquitectura actual usa resolvers y HTLC vinculados — Hash Time-Locked Contracts — para coordinar los dos lados de una transacción entre cadenas.
La arquitectura actual de STON.fi describe el flujo como:
1. Un usuario solicita un swap entre cadenas.
2. Omniston envía un RFQ a los resolvers.
3. Los resolvers devuelven cotizaciones ejecutables.
4. La liquidez seleccionada se bloquea en contratos HTLC vinculados.
5. La transacción se liquida o bien de forma atómica o las partes reciben el reembolso.
El concepto importante aquí es que la liquidez del lado de destino la suministra el resolver.
STON.fi describe a los resolvers como que proporcionan liquidez del lado de destino para órdenes individuales, en lugar de exigir que una aplicación mantenga saldos prefinanciados en cada red soportada.
❑ Los HTLC son lo que conecta los dos lados
HTLC significa Hash Time-Locked Contract (Contrato con Hash y bloqueo de tiempo).
El mecanismo combina dos condiciones.
Un hashlock requiere conocer un secreto antes de que los fondos puedan reclamarse.
Un timelock establece un plazo límite después del cual la transacción puede cancelarse y los fondos devolverse.
En un swap atómico entre cadenas, estas condiciones pueden conectar las transacciones del lado de origen y del lado de destino.
El resultado previsto es directo:
O el swap se completa según las condiciones acordadas, o los fondos pueden devolverse.
La descripción actual de Omniston en STON.fi establece explícitamente que se usan contratos HTLC vinculados entre cadenas y que el swap se liquida de forma atómica o los participantes reciben el reembolso.
Eso no significa que la arquitectura esté libre de riesgos.
La seguridad de un sistema así todavía depende de la corrección de los contratos, las cadenas participantes, la implementación del resolver y las condiciones de ejecución.
El punto relevante es más estrecho: el diseño entre cadenas de Omniston intenta coordinar swaps de activos nativos mediante liquidación atómica, en lugar de depender de un modelo convencional de puente de activos envueltos.
❑ Omniston no elimina el papel de los proveedores de liquidez
Cambia de dónde puede provenir la liquidez.
Para un AMM tradicional, los proveedores de liquidez depositan activos en pools y reciben tokens LP que representan su posición.
Con el modelo de resolver de Omniston, un resolver responde a las RFQ y, para transacciones entre cadenas, proporciona la liquidez del lado de destino necesaria para completar una orden.
STON.fi dice que los resolvers compiten en precio y ejecución, y que el resolver ganador proporciona la liquidez del lado de destino requerida.
Esto crea una estructura de mercado donde los proveedores de liquidez pueden competir por el flujo de órdenes.
Por lo tanto, el resolver no es simplemente otro backend API.
Es un participante de la ejecución.
❑ El modelo de resolver introduce una nueva capa de confianza e infraestructura
Los resolvers deben interactuar con la infraestructura técnica de Omniston y responder a las solicitudes de cotización.
La documentación de STON.fi describe un resolver como una entidad que proporciona cotizaciones y ejecuta operaciones a través del protocolo de agregación.
Esto crea varias dependencias que vale la pena reconocer.
El sistema depende de:
cotizaciones precisas;
funcionamiento de la infraestructura de resolvers;
contratos de liquidación;
ejecución en blockchain;
Vencimientos de RFQ;
comportamiento correcto de HTLC;
y suficiente liquidez de resolver.
Por lo tanto, la arquitectura traslada parte de la complejidad del lado del usuario y del desarrollador de la aplicación, pero esa complejidad no desaparece.
Pasa a la capa de ejecución.
❑ El soporte entre cadenas se ha expandido más allá de TON
El sitio web actual de Omniston lista TON, TRON, Ethereum, Base, BNB Chain, Polygon, Arbitrum, Avalanche y Robinhood Chain como redes en vivo.
Hay una discrepancia importante en la documentación que vale la pena registrar.
Alguna documentación más antigua de Omniston todavía describe TRON como próximo, mientras que la página de producto actual lista TRON como en vivo.
En lugar de tratar la documentación anterior como definitiva, la interpretación más segura es que la documentación y el lanzamiento de producción se actualizaron en momentos distintos.
Para disponibilidad real, la infraestructura RFQ en vivo es la fuente operativa más relevante.
Por eso, las listas de cadenas soportadas deben tratarse como sensibles al tiempo, en lugar de como especificaciones permanentes del protocolo.
❑ La arquitectura también está diseñada para desarrolladores
Omniston no está pensado solo para usarse a través de la interfaz de STON.fi.
STON.fi proporciona herramientas para desarrolladores para aplicaciones que quieran integrar el sistema.
La documentación incluye integración basada en SDK para solicitar cotizaciones, construir transacciones y hacer seguimiento de operaciones. La guía actual demuestra integración con React y conectividad de billetera TON, mientras que la plataforma Omniston proporciona infraestructura SDK, API/RFQ y widgets.
Esa distinción es significativa.
Si Omniston fuera solo una función dentro de la aplicación STON.fi, su papel arquitectónico sería relativamente limitado.
Al exponer la infraestructura de ejecución a otras aplicaciones, STON.fi intenta convertir a Omniston en una capa reutilizable de liquidez y ejecución.
Por lo tanto, la arquitectura se entiende mejor como infraestructura, más que simplemente como una función de front-end para trading.
❑ Las tarifas forman parte del modelo de ejecución
La página de producto actual de Omniston describe dos componentes de tarifa:
una tarifa de protocolo determinada por par de activos;
una tarifa del integrador configurada por la aplicación usando Omniston.
El rango declarado de la tarifa del integrador es de 0.01 a 100 puntos básicos, con la tarifa cobrada en el activo de destino y aplicada a nivel de contrato inteligente.
Un punto básico es la centésima parte de un punto porcentual.
Por lo tanto:
1 punto básico = 0.01%
10 puntos básicos = 0.10%
100 puntos básicos = 1%
La existencia de tarifas configurables significa que Omniston no es simplemente una API de enrutamiento abierta sin una capa económica.
Tiene un modelo de ejecución en el que los integradores pueden incorporar su propia tarifa en la transacción cotizada.
❑ La pregunta sobre la escala necesita una interpretación cuidadosa
Actualmente, STON.fi presenta a Omniston como impulsando cada swap en STON.fi y describe el sistema como que procesa decenas de millones de swaps y miles de millones de dólares en volumen.
Sin embargo, hay una limitación analítica importante.
Los datos públicos no aíslan de manera limpia el volumen solo de Omniston del volumen histórico del DEX subyacente de STON.fi.
Esto importa porque Omniston se convirtió en el mecanismo de enrutamiento predeterminado solo después de su integración en la dApp de STON.fi.
Actualmente, DefiLlama informa a STON.fi como un AMM basado en TON con aproximadamente $27.15 millones de TVL y $104.21 millones en volumen de DEX a 30 días al momento de su último snapshot recuperado. También informa aproximadamente $8.50 mil millones en volumen acumulado de DEX.
Estas cifras describen el protocolo STON.fi según la metodología de DefiLlama.
No deberían presentarse como estadísticas verificadas de Omniston solo por separado.
Esa distinción es importante al evaluar la escala de la capa de ejecución.
❑ Existe evidencia de seguridad, pero tiene límites
Las afirmaciones de seguridad también deben separarse por alcance.
Los contratos AMM v2 más amplios de STON.fi fueron revisados por Trail of Bits en enero de 2025.
Por separado, STON.fi anunció que sus contratos de escrow de Omniston fueron auditados por TonTech en agosto de 2025.
Estas son señales útiles de seguridad, pero una auditoría no equivale a demostrar que un protocolo es seguro.
Una auditoría representa una revisión del código y alcance especificados en un punto particular en el tiempo.
La arquitectura entre cadenas también introduce múltiples componentes y redes, lo que significa que la pregunta de seguridad se extiende más allá de un solo contrato inteligente.
Por esa razón, la conclusión adecuada es que Omniston ha pasado una revisión documentada de seguridad de los componentes relevantes, mientras que la existencia de una auditoría no debe interpretarse como una garantía contra vulnerabilidades futuras.
❑ Qué cambia Omniston para STON.fi
La evolución puede verse en tres etapas.
1. AMM
STON.fi proporciona pools de liquidez e infraestructura de market-making automatizado en TON.
2. Agregador
Omniston conecta múltiples fuentes de liquidez y usa RFQ para determinar rutas ejecutables.
3. Capa de ejecución entre cadenas
La arquitectura más nueva amplía la ejecución basada en RFQ más allá de TON y coordina la liquidez de origen y destino usando mecanismos de liquidación atómica.
Ese avance cambia el alcance de la infraestructura.
El AMM es principalmente un lugar de liquidez.
Omniston es un coordinador de ejecución.
Los dos sistemas están relacionados, pero no son intercambiables.
❑ Las preguntas no resueltas son tan importantes como la arquitectura
Varios detalles siguen siendo difíciles de verificar a partir de material accesible públicamente.
El número exacto de resolvers activos no se divulga claramente en la documentación pública actual.
La lista completa de fuentes de liquidez de DEX agregadas en cualquier momento tampoco se presenta como una lista pública permanente.
Los parámetros exactos de timeout de HTLC pueden depender del flujo de ejecución en lugar de representarse mediante un único número universal.
Además, los datos disponibles públicamente no ofrecen un panel limpio e independiente que muestre el volumen solo de Omniston en cada aplicación y cadena integrada.
Estos no son necesariamente fallas en la arquitectura.
Son simplemente limitaciones sobre lo que actualmente se puede establecer con evidencia pública.
Una evaluación basada en investigación debería conservar esas distinciones en lugar de rellenarlas con suposiciones.
❑ Dónde encaja Omniston en la arquitectura más amplia de STON.fi
La forma más sencilla de entender el sistema es separar sus componentes.
AMM de STON.fi:
Proporciona market-making automatizado y pools de liquidez en TON.
Omniston:
Agrega liquidez y solicita cotizaciones ejecutables.
Resolvers:
Proporcionar cotizaciones y, para ejecución entre cadenas, liquidez del lado de destino.
Liquidación HTLC:
Coordina los lados de origen y destino de las transacciones entre cadenas soportadas.
SDK/API:
Permite que aplicaciones externas se integren con la infraestructura de ejecución.
En conjunto, estos componentes representan un cambio desde un único exchange descentralizado hacia una arquitectura más amplia de enrutamiento de liquidez y ejecución.
Si esa arquitectura termina siendo ampliamente utilizada en aplicaciones y cadenas es una cuestión de adopción que no puede responderse simplemente a partir de la existencia de la tecnología.
Lo que se puede establecer hoy es más específico:
Omniston ha evolucionado desde la agregación de liquidez centrada en TON hasta la infraestructura de ejecución entre cadenas que STON.fi usa para sus propios swaps y que pone a disposición para integraciones externas.
Esa es la descripción más precisa de lo que es el sistema.
❑Referencias
Fuentes oficiales
STON.fi — Omniston
https://ston.fi/omniston
Documentación de STON.fi — Descripción general de Omniston
https://docs.ston.fi/developer-section/omniston/overview
Documentación de STON.fi — Resolutores de Omniston
https://docs.ston.fi/developer-section/omniston/resolvers
Documentación de STON.fi — Guía para desarrolladores de Omniston
https://docs.ston.fi/developer-section/quickstart/omniston
GitHub de STON.fi — SDK de Omniston
https://github.com/ston-fi/omniston-sdk
Blog de STON.fi — Omniston ahora impulsa cada swap en STON.fi https://blog.ston.fi/omniston-now-powers-every-swap-on-ston-fi/
STONfi x
https://x.com/ston_fi
Investigación & Análisis
DefiLlama — Métricas de STON.fi
https://defillama.com/protocol/ston.fi
Trail of Bits — Revisión de Seguridad del DEX AMM de STON.fi TON https://github.com/trailofbits/publications/blob/master/reviews/2025-01-stonfi-ton-amm-dex-v2-securityreview.pdf
HackenProof
— STON.fi DEX Contratos Inteligentes v2 Bounty https://hackenproof.com/programs/ston-dot-fi-dex-smart-contracts-v2
CertiK — Perfil de Seguridad de STON.fi https://skynet.certik.com/projects/ston-fi
Fuentes de la comunidad & del programa
STONbassadors — Programa Oficial https://ston.fi/stonbassadors
Guías de STONbassadors https://ambassadors.ston.fi/
Escrito por Binnoreen
X: https://x.com/Bin_noreen
Telegram https://t.me/binnoreen