Lo que realmente significan los contratos de pools inmutables para los usuarios de STONfi
"Inmutable" es una de esas palabras que DeFi tomó prestada y luego despojó silenciosamente de precisión. La gente la usa como atajo para "aquí nunca puede cambiar nada", lo cual suena tranquilizador y casi nunca es lo que realmente significa en la práctica. El significado real es más acotado, más específico y, sinceramente, más útil una vez que lo entiendes; pero solo si estás dispuesto a mantener esa distinción en mente en lugar de tratar la palabra como una insignia de seguridad. 🔒
STONfi describe sus contratos de pools de liquidez como inmutables. Ese planteamiento es cierto y elimina una clase de riesgo realmente importante. Pero eso no significa que un pool exista fuera de la gobernanza, los cambios de configuración o la evolución a nivel de protocolo: la arquitectura de STONfi permite deliberadamente que ciertos parámetros y estados de funcionamiento cambien mediante mecanismos predefinidos, y porque el Router que está delante de esos pools es actualizable incluso cuando los pools en sí no lo son.
Entender exactamente dónde cae esa línea es la diferencia entre un modelo mental preciso de tu riesgo y uno cómodo pero incorrecto.
Dónde se ubica realmente la inmutabilidad en la arquitectura
STONfi divide responsabilidades en varios contratos inteligentes distintos en lugar de concentrarlo todo en una sola pieza monolítica de código, y esa separación es lo que hace que la pregunta de inmutabilidad sea interesante en vez de ser binaria.
El Router es el punto de entrada principal: recibe operaciones y las enruta hacia el pool de liquidez adecuado. El Pool almacena los datos de AMM para un par específico de tokens, procesa swaps y operaciones de liquidez, realiza los cálculos de precios y actúa como minter de los tokens LP que representan tu participación en ese pool.
La distinción arquitectónica que más importa: según la documentación de STONfi, el Router es el único contrato DEX que se puede actualizar. Los contratos de pool, una vez desplegados, mantienen su código de forma permanente.
Eso te da dos superficies de seguridad genuinamente distintas para pensar, y confundirlas es donde empieza la mayor parte de la confusión. El pool ofrece una persistencia fuerte del código: su implementación central no puede ser reemplazada de manera repentina por nadie por ninguna razón con una lógica distinta. El Router ofrece flexibilidad del protocolo: puede coordinar pools, ajustar parámetros soportados y recibir futuras actualizaciones a medida que el protocolo evoluciona.
Este es un compromiso de diseño deliberado, no un accidente ni una inconsistencia. Obtienes previsibilidad justo donde la previsibilidad importa más — el código que mantiene y calcula con respecto a tus fondos — mientras conservas suficiente flexibilidad en la capa de coordinación para que el protocolo realmente mejore con el tiempo, en lugar de quedarse congelado con lo que acertó su primera versión.
El código inmutable no significa estado inmutable
Probablemente esto sea lo más importante para internalizar, y es donde la definición casual de “inmutable” causa más daño a la comprensión de la gente.
Un contrato de pool puede tener código permanentemente fijado mientras los datos almacenados dentro de ese contrato cambian continuamente, transacción tras transacción, para siempre. Son conceptos completamente separados que ocurren a la vez dentro del mismo contrato.
Cada swap cambia las reservas del pool. Agregar o retirar liquidez cambia tanto las reservas como el suministro total de tokens LP. La acumulación de comisiones cambia balances con el tiempo. El estado del pool puede cambiar. Ciertos parámetros del pool pueden actualizarse mediante operaciones que el código del contrato existente permite explícitamente.
El estado del pool de STONfi v2 incluye variables como reservas, suministro total de LP, comisiones de LP, comisiones del protocolo y el estado del pool; todo ello está diseñado para cambiar, porque un pool que no pudiera actualizar sus propias reservas sería un pool que no podría procesar ni un solo swap. La documentación del Router define por separado operaciones administrativas para cambiar comisiones y el estado del pool, y las implementaciones especializadas del pool pueden admitir actualizaciones adicionales de parámetros además de eso.
Así es como se descomponen realmente las piezas:
Código del contrato de pool existente — no puede cambiar. La implementación central no es reemplazable.
Reservas de tokens — cambian constantemente, a través de cada swap y de cada operación de liquidez.
Suministro de tokens LP — cambia cada vez que se agrega o se retira liquidez.
Comisiones de trading — se pueden ajustar mediante controles de protocolo documentados.
Estado del pool — se pueden restringir las operaciones de trading o de liquidez.
Código del Router — se puede actualizar.
Las reglas que permiten todo lo anterior — fijas para cualquier pool existente, definidas por el código desplegado de ese pool.
Esa última línea es la que lo conecta todo. Las reglas que gobiernan qué puede cambiar se establecieron por sí mismas de forma permanente en el despliegue. No se puede añadir nada a esa lista después.
La forma más clara que he encontrado para pensarlo: el reglamento está fijo, mientras el juego continúa desarrollándose de acuerdo con esas reglas. La inmutabilidad limita qué tipos de cambios son posibles, no si algo cambia o no.
🛡️ ¿De qué te protegen realmente los pools inmutables?
El beneficio más directo es la protección contra reemplazo arbitrario de código del pool, y vale la pena ser específico sobre por qué eso importa en lugar de aceptarlo como algo evidentemente bueno.
En un smart contract actualizable, quien controla el mecanismo de actualización potencialmente puede reemplazar la lógica existente por código completamente nuevo. Los mecanismos de actualización legítimos realmente son útiles: permiten a los desarrolladores corregir bugs y añadir funciones sin abandonar una dirección y migrar a todos. Pero también crean una dependencia de seguridad adicional que nunca desaparece: los usuarios tienen que confiar en que la autoridad de actualización y sus llaves nunca sean abusadas, nunca sean comprometidas, nunca se manejen mal por quien las tenga, indefinidamente, mientras sus fondos estén ahí.
La documentación del propio smart contract de TON es explícita al respecto: señala que las actualizaciones pueden afectar el comportamiento del contrato, los fondos y el estado, y que actualizaciones no autorizadas pueden resultar en pérdida de control o pérdida de fondos directamente.
Un pool inmutable de STONfi elimina por completo esa ruta de ataque en el propio pool. Si hoy inspeccionas o auditas el código detrás de un pool existente, un administrador no puede luego reemplazar silenciosamente el mismo pool por otro código diferente. Lo que revisaste es lo que se queda ahí.
Para proveedores de liquidez específicamente, esto significa que la implementación fundamental del contrato que sostiene el estado de tu pool no está diseñada alrededor de un mecanismo irrestricto de “actualiza este pool más tarde” que quede en segundo plano como un requisito de confianza permanente y abierto. Eso reduce de forma significativa lo que tienes que seguir confiando con el tiempo.
Pero la inmutabilidad no es una garantía de seguridad, y no debería interpretarse como tal
El código inmutable aún puede contener bugs. Esa frase merece leerse dos veces, porque es la parte que la gente se salta cuando “inmutable” se trata como una credencial de seguridad.
De hecho, la inmutabilidad crea un compromiso real en lugar de ser una victoria total. Si existe un error dentro de un código inmutable, los desarrolladores no pueden simplemente corregir el pool desplegado en su lugar. El bug permanece ahí, en ese contrato, de forma permanente. Los contratos actualizables hacen que corregir defectos sea sencillo, pero introducen riesgo de autoridad de actualización. Los contratos inmutables eliminan el riesgo de autoridad de actualización a nivel de pool, pero hacen que los bugs desplegados sean mucho más difíciles de corregir.
Ninguno de los enfoques es superior de forma universal. Son perfiles de riesgo distintos, y los protocolos razonables toman decisiones diferentes dependiendo de qué estén optimizando.
El marco honesto es que la inmutabilidad te dice algo muy específico sobre cómo puede cambiar el código de un contrato. No te dice nada en absoluto sobre si cada resultado que produce ese código será favorable para ti; esa es una pregunta completamente distinta.
La inmutabilidad tampoco hace nada frente al riesgo de mercado, la pérdida impermanente, el riesgo de tokens, el riesgo de liquidez, ni problemas económicos derivados de condiciones de mercado inesperadas. Un pool perfectamente inmutable que sostiene un token que colapsa sigue siendo un pool que sostiene un token que colapsó. El contrato se comportó exactamente como se desplegó durante todo el tiempo.
🧭 El Router es la excepción importante, y el timelock es la razón por la que funciona
No puedes entender correctamente los pools inmutables de STONfi sin también entender el Router, porque mirar la inmutabilidad del pool de forma aislada da una imagen genuinamente incompleta del modelo real de confianza del protocolo.
STONfi describe el Router como el punto de entrada principal para operaciones de DEX y el contrato que contiene capacidades administrativas a nivel de protocolo. Puede bloquear o desbloquear operaciones, cambiar comisiones para un pool en particular y actualizar su propio contrato. Así que, aunque la lógica matemática y operativa ya desplegada dentro de un pool no se puede reescribir, el entorno a través del cual realmente interactúas con ese pool sí tiene elementos configurables y, además, es actualizable.
STONfi aborda el riesgo de actualización del Router mediante un timelock de siete días. La documentación del protocolo establece que las actualizaciones de contratos del Router se retrasan siete días, dando a los usuarios aviso anticipado y una oportunidad real para retirar liquidez si no están de acuerdo con el cambio propuesto.
Esa es, fundamentalmente, un modelo de seguridad diferente al de actualizaciones administrativas instantáneas. En lugar del patrón en el que un admin propone nuevo código y ese nuevo código controla inmediatamente el protocolo, pasa a ser: se inicia la actualización, comienza un periodo de espera, los usuarios pueden evaluar el cambio y solo entonces se puede finalizar la actualización.
Para aclarar qué logra (y qué no) el retraso: no hace imposible una actualización mala. Nada sobre un timelock impide que, eventualmente, alguien finalice un cambio que los usuarios no desean. Lo que sí hace es garantizar que tienes tiempo para observar y reaccionar antes de que el nuevo código del Router se active, lo cual convierte una clase de riesgo de “te enteras después” a “tienes una semana para decidir qué hacer al respecto”. Eso no es poco, y es sustancialmente mejor que la alternativa, pero no es lo mismo que que el cambio sea imposible.
Las comisiones son el ejemplo más claro de toda esa distinción
Las comisiones de trading demuestran exactamente por qué “contrato inmutable” y “pool inalterable” no son sinónimos, y es el ejemplo al que apuntaría primero si alguien tuviera dificultades con el concepto.
La documentación actual de STONfi indica que las comisiones son configurables por pool. La comisión total predeterminada es 0,3% — 0,2% para los proveedores de liquidez, 0,1% para el protocolo — y la configuración de comisiones puede ajustarse dentro de un rango documentado de 0%–1%.
Mecánicamente, el Router expone una operación set_fees que envía la nueva configuración de comisiones al pool objetivo, y el contrato v2 de Pool ya contiene la lógica para recibir esa actualización autorizada de comisiones.
Nada de esto contradice, ni siquiera ligeramente, la inmutabilidad del pool. El código no cambió. El código inmutable original se escribió desde el principio para aceptar ciertas actualizaciones autorizadas de parámetros; esa capacidad estaba incorporada en el despliegue, no se añadió después. Al usar ese mecanismo, alguien está usando el contrato exactamente como fue construido de forma permanente.
Esto se generaliza en una lección realmente útil para leer cualquier smart contract: la inmutabilidad se refiere a reemplazo de código, no necesariamente a cada valor almacenado por ese código. Un contrato puede quedar “arreglado” de forma permanente y aun así haber sido diseñado desde el día uno con parámetros configurables.
Qué significa esto realmente si estás proporcionando liquidez
Para un LP, los contratos de pool inmutables hacen sustancialmente más fácil razonar sobre una parte específica del modelo de riesgo. No tienes que asumir que el contrato exacto del pool en el que depositaste podría más tarde recibir bytecode completamente diferente mediante algún mecanismo de actualización a nivel de pool. La implementación que gobierna swaps, contabilidad de liquidez y el comportamiento de los tokens LP se mantiene como la implementación que puedes inspeccionar hoy.
Pero esa garantía es limitada, y los LPs deberían seguir monitoreando activamente lo que está fuera de ella:
Las comisiones actuales afectan directamente tu rendimiento por comisiones, y son ajustables dentro del rango documentado
El estado del pool afecta si el pool es utilizable o no para operaciones de trading o de liquidez
Las actualizaciones del Router pueden afectar cómo se mueven las transacciones a través del protocolo, sujeto a esa ventana de aviso de siete días
Las nuevas versiones del protocolo pueden introducir arquitecturas nuevas de pool por completo, en lugar de reescribir pools antiguos
Ese último punto merece énfasis porque es fácil pasarlo por alto. La evolución del protocolo en STONfi ocurre alrededor de pools inmutables, no cambiándolos. Una nueva versión significa contratos nuevos, no contratos antiguos modificados.
La conclusión práctica: el análisis de riesgo para LP debe separar el riesgo del código del pool del riesgo de control del protocolo, en lugar de mezclar ambos en un solo “riesgo de contrato inteligente” vago. Esas son exposiciones realmente distintas, con mitigaciones diferentes, y la inmutabilidad solo aborda una de ellas.
Qué significa esto si solo estás haciendo trading
Para traders, la inmutabilidad del pool compra principalmente previsibilidad. Un pool conocido no puede ejecutar de repente una lógica central totalmente distinta porque alguien haya cambiado su código de contrato. Los cálculos de precios implementados dentro de ese pool permanecen vinculados a su implementación desplegada, de forma permanente.
Lo que no compra es ninguna seguridad de que las condiciones de trading sean permanentes. Las comisiones pueden cambiar dentro del rango permitido. Un pool o el Router puede bloquearse bajo controles de protocolo soportados. La liquidez cambia continuamente, lo cual afecta directamente tu impacto en el precio en cualquier trade dado. Diferentes versiones de STONfi y diferentes tipos de pool pueden comportarse de forma distinta entre sí.
Así que saber que un pool es inmutable es un contexto realmente útil, pero no reemplaza revisar la configuración actual del pool, la liquidez, las comisiones y la versión del Router antes de asumir cómo se ejecutará tu operación específica. La inmutabilidad es una afirmación sobre la permanencia del código, no un “snapshot” de las condiciones actuales.
Cómo cambia la forma de evolucionar del protocolo
TON admite contratos actualizables específicamente porque las actualizaciones son realmente útiles: permiten a los desarrolladores corregir defectos y añadir funcionalidades sin abandonar una dirección existente ni obligar a todos a migrar. STONfi eligió deliberadamente un camino distinto para sus pools, y esa elección tiene consecuencias reales sobre cómo crece el protocolo.
En lugar de depender de la capacidad de reescribir continuamente cada pool desplegado, la evolución ocurre alrededor de pools inmutables: mediante actualizaciones del Router, mediante nuevas implementaciones de contratos y mediante nuevas versiones del protocolo. La documentación de STONfi ya separa sus contratos originales de la v1 de la arquitectura más nueva de la v2, que añade funciones que incluyen una gestión de liquidez mejorada y un sistema basado en un vault.
Esto hace que la versionado de contratos sea considerablemente más importante de lo que sería bajo un modelo de “actualiza todo”. Un contrato inmutable te dice que su implementación seguirá siendo la misma que en el despliegue. No te dice que STONfi como protocolo nunca introducirá arquitecturas más nuevas; de hecho, la inmutabilidad esencialmente garantiza que las nuevas arquitecturas son la forma en que debe ocurrir la mejora.
🎯 Una mejor pregunta que “¿es inmutable?”
Al evaluar cualquier protocolo DeFi, preguntar simplemente “¿los contratos son inmutables?” no es suficiente, porque la respuesta casi siempre es más matizada que un simple sí o no, y es en esa matización donde vive el riesgo real.
Una mejor pregunta, y una que realmente puedes responder con documentación:
Qué contratos son inmutables, cuáles se pueden actualizar, qué parámetros pueden cambiar, quién está autorizado para cambiarlos y cuánto tiempo tienen los usuarios para reaccionar.
Para STONfi, esa pregunta tiene una respuesta razonablemente estructurada. Los contratos de pool son inmutables. Su estado cambia según una lógica predeterminada ya presente en el código desplegado. Ciertos parámetros del pool permanecen configurables dentro de rangos documentados. El Router mantiene responsabilidades administrativas más amplias y es actualizable, con actualizaciones sujetas a un retraso de siete días.
Esa es una imagen mucho más precisa que cualquier extremo conveniente — “todo lo controlan los administradores” de un lado, “nunca puede cambiar nada” del otro. Ambas cosas están mal, y ambas llevan a decisiones mal calibradas.
Pensamientos finales
Los contratos de pool inmutables le dan a los usuarios de STONfi una forma específica y realmente valiosa de previsibilidad: el código central de un pool de liquidez ya desplegado no puede simplemente sustituirse por otra implementación. Eso elimina el riesgo asociado con actualizaciones directas del código del pool y hace que el comportamiento de un contrato existente sea mucho más fácil de razonar a lo largo de horizontes temporales largos.
Pero esa garantía tiene límites claros, y conocer dónde caen es justamente el objetivo. Las reservas del pool siguen moviéndose. La oferta de LP cambia con cada depósito y retiro. Las comisiones pueden ajustarse dentro de límites documentados. Los pools tienen parámetros configurables y controles de estado. Y el Router sigue siendo un componente actualizable de la arquitectura más amplia, protegido por un retraso de siete días en lugar de por una inmutabilidad absoluta.
La conclusión práctica no es que los pools de STONfi nunca puedan cambiar. Es que su código no puede cambiar, mientras que su estado y el protocolo alrededor de ellos solo pueden evolucionar mediante mecanismos que la propia arquitectura ya define.
Esa distinción es lo que hace que los contratos inmutables sean realmente útiles — y es exactamente lo que los usuarios necesitan entender antes de tratar la inmutabilidad como una garantía de seguridad completa, en lugar de la protección específica y acotada que realmente es.
❓ Preguntas frecuentes
Si un contrato de pool es inmutable, ¿por qué pueden cambiar sus comisiones? Porque el código original desplegado se escribió para aceptar ciertas actualizaciones autorizadas de parámetros. El código en sí no se ha reemplazado; esa capacidad — que siempre había existido — se está usando.
¿STONfi puede reemplazar un pool al que yo ya le aporté liquidez? No el código del pool. Las nuevas versiones del protocolo introducen nuevos contratos de pool en lugar de reescribir los existentes, así que la implementación en la que depositaste se mantiene como fue desplegada.
¿Qué pasa si se encuentra un bug en un contrato de pool inmutable? No se puede parchear en su lugar; ese es el verdadero compromiso de la inmutabilidad. Las correcciones tienen que llegar mediante nuevos despliegues de contratos en lugar de actualizar el pool existente.
¿De qué me protege realmente el timelock del Router de siete días? No impide que eventualmente ocurra una actualización. Garantiza aviso anticipado, dándote tiempo para evaluar el cambio y retirar liquidez antes de que el nuevo código del Router entre en actividad.
