Presentamos Adapter, Protocolo 28 en Stellar

La próxima actualización de la red Stellar, Protocolo 28—Adapter—está en camino. Es un lanzamiento centrado en creadores: la mayor parte de lo que incluye les facilita la vida a las personas que escriben contratos inteligentes en Stellar, mientras un cambio bajo el capó ayuda a que la red alcance consenso más rápido a medida que sigue escalando.

Esto es lo que trae Adapter, por qué importa y qué sigue.

Consenso más rápido, incluso bajo carga (CAP-83)

Cada pocos segundos, los validadores en la red Stellar acuerdan el siguiente libro mayor. Hoy, parte de ese proceso requiere que los validadores reciban un conjunto de transacciones completo antes de poder avanzar—y compartir esos conjuntos de transacciones a través de la red toma tiempo.

CAP-83 permite que los validadores comiencen a votar antes de que el conjunto de transacciones haya llegado por completo, y les da una forma clara y explícita de descartar un conjunto de transacciones que llega tarde o es inválido en lugar de quedarse bloqueados mientras lo esperan. En la práctica, eso significa que el consenso sigue avanzando incluso cuando los datos de transacciones se propagan lentamente, lo que mejorará el rendimiento y ayudará a mantener la red funcionando sin problemas a escala y a bajo costo. Las ganancias completas de rendimiento se introducirán por fases después de mainnet a medida que se habilite gradualmente la descarga paralela de conjuntos de transacciones.

Por qué te debería importar: Esta es una mejora tras bambalinas—no necesitas cambiar nada para beneficiarte a medida que se despliega—pero es fundamental. Un proceso de consenso más rápido y más resiliente es lo que permite que Stellar siga creciendo sin volverse más lenta. (Los equipos que consumen datos de libro mayor en bruto directamente deben ver la sección “Cambios que rompen” de la guía de actualización, ya que el cambio añade un nuevo tipo de valor que querrán manejar.)

Actualizaciones atómicas para flotas de contratos (CAP-85)

Muchos protocolos implementan muchas copias del mismo contrato—una “flota” que comparte el mismo código subyacente. Cuando ese código compartido necesita una actualización (por ejemplo, para publicar una corrección de seguridad), el admin tiene que actualizar cada instancia una por una. Para flotas grandes, eso no puede hacerse en una sola transacción, lo que deja una ventana donde algunos contratos ejecutan el código nuevo y otros siguen con el código antiguo.

CAP-85 introduce un ejecutable gestionado externamente: los contratos pueden apuntar a una referencia de código compartida y actualizable, propiedad de otro contrato. Actualiza esa única referencia y cada contrato que apunte a ella se actualiza a la vez—atómicamente, sin importar cuán grande sea la flota.

Por qué te debería importar: Este es el equivalente en Stellar del patrón “beacon proxy” que los desarrolladores conocen de otras cadenas. Hace que gestionar implementaciones grandes sea mucho más seguro y menos propenso a errores, y elimina el riesgo de que una actualización parcial deje contratos en estados inconsistentes.

Datos de contrato aptos para migración (CAP-86)

A medida que los contratos evolucionan, sus estructuras de datos a menudo necesitan cambiar—añadiendo un campo, quitando uno sin uso o extendiendo una interfaz compartida. Hoy, las funciones estándar del host que leen y escriben estas estructuras rechazan cualquier cosa que no coincida con la forma exacta esperada, lo que hace sorprendentemente difícil evolucionar los datos de un contrato en vivo y, en algunos casos conocidos, ha dejado contratos atascados.

CAP-86 añade nuevas funciones del host “sparse” que manejan con gracia campos faltantes o extra en lugar de fallar. Eso les da a los desarrolladores una forma estándar y soportada de migrar los datos de contrato a un nuevo esquema con el tiempo.

Por qué te debería importar: Si mantienes contratos que esperas actualizar a lo largo de su vida útil, esto hace que los cambios de esquema sean seguros y rutinarios en lugar de una fuente de rupturas. Lo obtendrás recompilando contra un SDK actualizado—sin cambios en cómo escribes contratos. Cuando salgan las versiones de tu SDK para el Protocolo 28, asegúrate de revisar la documentación de migración para más detalles.

Adapter es, sobre todo, un lanzamiento para creadores. Dos de sus tres cambios (CAP-85, CAP-86) están dirigidos directamente a hacer que los contratos inteligentes de Soroban sean más fáciles de crear, actualizar y escalar—reduciendo la cantidad de contratos que tienes que implementar, haciendo que las actualizaciones sean atómicas y seguras, y permitiendo que los datos del contrato evolucionen sin romperse. El tercero (CAP-83) refuerza la capa de consenso sobre la que se apoya todo lo demás.

En conjunto, continúan un tema constante en las actualizaciones recientes del protocolo: hacer de Stellar una plataforma más capaz y más amigable para desarrolladores para aplicaciones financieras reales, sin comprometer la velocidad y el bajo costo por el que la red es conocida.

El Protocolo 28 se despliega con un cronograma fijo. Hitos principales:

13 de agosto de 2026 — Lanzamiento estable de Stellar Core disponible.

13-21 de agosto de 2026 — Lanzamientos estables adicionales (infraestructura y SDKs) disponibles.

27 de agosto de 2026, 1700 UTC — Votación de actualización de testnet.

16 de septiembre de 2026, 1700 UTC — Votación de actualización de mainnet.

Si operas infraestructura, un validador, o desarrollas en Stellar, hay pasos que tendrás que seguir para estar listo. Todo lo que necesitas—la línea de tiempo completa, enlaces a lanzamientos e instrucciones de preparación para validadores, operadores de infraestructura, usuarios de SDK, billeteras, exchanges, emisores, on/off-ramps y protocolos—está en la Guía de Actualización del Protocolo 28.

Para mantenerte al día con todos los anuncios relacionados con Adapter, únete al Stellar Developer Discord, donde el ecosistema coordina la actualización en el canal #protocol-next.