Guía de actualización de Bell, Protocolo 30

Última actualización: 23 de octubre de 2026

Esta guía está diseñada para ayudar a empresas y desarrolladores a prepararse para Bell, Protocolo 30, con fechas clave, información de lanzamientos, pasos de preparación y un resumen de cambios incompatibles. Esta guía es informativa. Los operadores son responsables de probar sus propias integraciones antes de cada votación.

Puedes leer todo lo que incluye Bell en el blog del anuncio, y mantente al día con todos los anuncios relacionados con Bell en el Discord de Desarrolladores de Stellar, donde el ecosistema coordina y comparte información sobre la actualización en el canal #protocol-next.

Fechas clave

• 16 de octubre de 2026—Stellar Core v30.0.0 versión estable disponible.
• 16-23 de octubre de 2026—Lanzamientos estables adicionales (infraestructura y SDKs) disponibles.
• 3 de noviembre de 2026, 1700 UTC—Votación de actualización de Testnet.
• 23 de noviembre de 2026, 1700 UTC—Votación de actualización de Mainnet.

Si usas un SDK de Stellar

Actualiza a la última versión del SDK de Stellar correspondiente.

• Para tu Testnet integración, actualiza antes del 3 de noviembre de 2026.
• Para tu Mainnet integración, actualiza antes del 23 de noviembre de 2026.

La actualización del SDK no es opcional en este ciclo. El Protocolo 30 cambia el formato del encabezado del libro mayor (CAP-88), y un SDK antiguo puede no lograr decodificar los libros mayores del Protocolo 30. Los SDKs del Protocolo 30 incluyen las definiciones XDR actualizadas, además de compatibilidad con el nuevo tipo de dirección de contrato multiplexada y su strkey W (CAP-84).

Si tu aplicación maneja direcciones, la actualización del SDK es el paso uno de dos. El SDK te da un analizador para direcciones W; tu propio código debe aceptarlas. Agrega la variante de dirección W a tus validaciones de tipo dondequiera que valides, muestres o almacenes direcciones, y donde leas el destino de un evento de transferencia. Consulta Cambios incompatibles más abajo.

Si creas contratos inteligentes de Stellar (Soroban), no necesitas cambiar nada: los contratos existentes seguirán funcionando después de la actualización. Cuando recompiles contra el SDK de Soroban del Protocolo 30, por ejemplo para usar las funciones de verificación ML-DSA (CAP-87), también necesitarás una CLI de Stellar en una versión coincidente o posterior.

Un recordatorio no relacionado con el Protocolo 30: desde el Protocolo 27 (CAP-71-02), SOROBAN_CREDENTIALS_ADDRESS_V2 es el tipo de credencial recomendado para la autorización de direcciones de Soroban. El tipo original SOROBAN_CREDENTIALS_ADDRESS aún funciona y no tiene fecha de desuso, pero un protocolo futuro podría retirarlo. Si tu billetera o biblioteca de firmado aún usa el tipo original, migra cuando te resulte conveniente.

Si ejecutas infraestructura de Stellar (Stellar Core, Horizon, RPC, Galexie)

Instala los lanzamientos del Protocolo 30, disponibles ahora. Las versiones se enumeran en la sección Lanzamientos del Protocolo 30 más abajo.

• Si usas imágenes de Docker, extrae las compilaciones del Protocolo 30 desde el registro de Docker.
• Si compilas desde el código fuente o usas nuestros paquetes de Debian, actualiza tus stellar-core, stellar-horizon, stellar-rpc, y stellar-galexie binarios a las compilaciones del Protocolo 30.

Ubuntu: Hemos publicado imágenes para Ubuntu 24.04 y Ubuntu 22.04. Para compilar desde el código fuente, consulta las instrucciones de instalación; la instalación basada en paquetes se describe en la documentación de Stellar.

Docker: Hemos publicado las imágenes de Docker de Stellar Core para el Protocolo 30; la instalación basada en Docker se describe en la documentación de Stellar.

Si consumes datos sin procesar del libro mayor (por ejemplo, a través de Galexie, un indexador, un explorador de bloques, una canalización de analítica o un decodificador XDR personalizado), debes actualizar tus definiciones XDR antes de la actualización. Lee la nota de CAP-88 en Cambios incompatibles: desde el primer libro mayor después de la actualización, los encabezados del libro mayor llevan un nuevo tipo de valor, y los decodificadores construidos contra XDR antiguos fallarán al procesarlo.

Si ejecutas un validador

Instala Stellar Core v30.0.0, publicado el 16 de octubre de 2026. El comando de armado para la votación de actualización de Mainnet del 23 de noviembre se compartirá con los validadores a través de los canales habituales de validadores antes de la votación.

Si operas una billetera, exchange, emisor, on/off-ramp o protocolo

• Billeteras, ramps y emisores: Actualiza a la última versión del SDK (ver arriba) antes de la votación de Mainnet. Luego ten en cuenta el nuevo tipo de dirección W: después de la actualización, una dirección de contrato multiplexada puede usarse como destino de un evento de acuñación o transferencia. Agrégala a tu validación, visualización y almacenamiento de direcciones, y a cualquier lógica que lea adónde fue una transferencia.
• Exchanges y custodios: Actualiza cualquier SDK e infraestructura que ejecutes antes de la votación correspondiente, y agrega compatibilidad para retiros hacia direcciones de contrato multiplexadas (el tipo de dirección W). Si usas cuentas multiplexadas de Stellar (el tipo de dirección M) para depósitos, considera si las direcciones de contrato multiplexadas pueden ajustarse mejor a tus necesidades.
• Protocolos y equipos de contratos inteligentes: CAP-87 (verificación de firmas ML-DSA) y CAP-84 (direcciones de contrato multiplexadas como destino de transferencia) son funciones opcionales que adoptas cuando recompilas contra el SDK de Soroban actualizado. Los contratos existentes siguen funcionando sin cambios. Si tu contrato acepta direcciones de usuarios, por ejemplo un token o un contrato de pagos, decide si debe aceptar la variante multiplexada: una función declarada con una simple Address rechaza una dirección W, y una declarada con MuxedAddress acepta ambas. Los contratos que leen la marca de tiempo del libro mayor deben revisar la nota de CAP-88: los libros mayores consecutivos ahora pueden reportar la misma marca de tiempo al segundo exacto.

Bell, el Protocolo 30 no se espera que introduzca incompatibilidades hacia atrás a nivel de transacción. Todos los cambios son aditivos. Dos de ellos requieren acciones aguas abajo: CAP-84 para todo lo que maneje direcciones, y una actualización de XDR para todo lo que decodifique datos de libro mayor en bruto. Esa actualización cubre tanto CAP-84, ya que el nuevo tipo de dirección aparece en transacciones y por lo tanto en el meta del libro mayor, como CAP-88, que cambia el encabezado del libro mayor. Actualizar tu SDK es obligatorio en todos los casos.

CAP-84 (direcciones de contrato multiplexadas): Agrega un nuevo SCAddress variante, SC_ADDRESS_TYPE_MUXED_CONTRACT (un ID de contrato más un ID de multiplexación de 64 bits), con un nuevo prefijo de strkey W, definido en SEP-23.

Toda aplicación que valide, muestre, almacene o enrute direcciones debe manejar la nueva variante y prefijo. El SDK del Protocolo 30 te proporciona el analizador; añadir la variante W a tus propias comprobaciones de tipo es el trabajo de ingeniería.

• Dónde aparece: el to argumento del Stellar Asset Contract transfer function; cualquier campo de dirección proporcionado por el usuario en una billetera, exchange, rampa o explorador; y el meta del libro mayor, que la actualización de XDR de CAP-84 cubre.
• Eventos: los eventos transfer y mint llevan el ID en el existente to_muxed_id campo, exactamente como para las cuentas muxed (CAP-67). Quienes ya manejan cuentas muxed no necesitan nueva lógica.
• Reglas heredadas de las cuentas muxed: una dirección de contrato muxed no puede usarse en una clave de almacenamiento del contrato, y una función que declare un simple Address como argumento la rechaza.

CAP-88 (tiempos de cierre con resolución de milisegundos): Introduce dos nuevos StellarValue tipos, STELLAR_VALUE_SIGNED_MS y STELLAR_VALUE_EMPTY_TX_SET_MS, y un nuevo TimePointMs typedef. Desde el libro mayor inmediatamente después de la actualización, cada libro mayor lleva uno de los nuevos tipos; los tipos antiguos de segundos completos ya no se producen.

Todo consumidor que decodifique StellarValue, LedgerHeader, LedgerCloseMeta o el historial de SCP (indexadores, exploradores, canalizaciones de analítica, herramientas personalizadas) debe actualizar a las definiciones XDR del Protocolo 30, o la decodificación fallará en ramas de unión desconocidas.

Más allá de la actualización del esquema, no se requiere ningún cambio semántico: el closeTime no cambia y equivale al valor en milisegundos redondeado hacia abajo. Los límites de tiempo de las transacciones, minSeqAge, predicados de saldos reclamables, Soroban ledger_timestamp, y la programación de actualizaciones mantienen semántica de segundos completos. Una suposición se debilita: los libros mayores consecutivos ahora pueden cerrarse dentro del mismo segundo completo, por lo que “un libro mayor después” ya no implica “al menos un segundo después”. No se necesita ninguna acción para integraciones normales basadas en SDK más allá del incremento de versión del SDK.

CAP-87 (funciones host ML-DSA): Agrega tres funciones host de Soroban, verify_sig_ml_dsa_44, verify_sig_ml_dsa_65, y verify_sig_ml_dsa_87, que implementan verificación de firmas FIPS 204, además de nuevas ContractCostType entradas para medición. Sin incompatibilidades hacia atrás. Los contratos compilados contra un protocolo anterior no pueden importar estas funciones hasta la actualización. Ten en cuenta el alcance: esto habilita la verificación de firmas poscuánticas dentro de los contratos inteligentes (por ejemplo, cuentas personalizadas). Las firmas de transacciones a nivel de red siguen siendo Ed25519.

A continuación encontrarás enlaces a las versiones relevantes para el Protocolo 30. Por favor revisa las notas de cada versión para instrucciones y requisitos específicos y, salvo que se indique lo contrario, elige la “Última versión.”

Infraestructura de Stellar

• Stellar Core v30.0.0
• Horizon v30.0.0
• RPC v30.0.0
• Galexie v30.0.0
• Stellar CLI (versión del Protocolo 30 pendiente)

SDKs mantenidos por SDF

• Rust SDK (Soroban) 30.0.0-rc.1 (la versión estable llegará antes de la votación de Mainnet)
• JavaScript SDK v17.3.0. Si estás en la línea de mantenimiento 16.x, v16.4.0 decodifica libros mayores del Protocolo 30 pero no maneja direcciones W; pasa a v17.3.0 para soporte de CAP-84.
• Go SDK v0.8.0

SDKs de la comunidad

• Java
• Python
• iOS
• PHP
• C# .NET
• Flutter
• Elixir
• KMP

Cada enlace de SDK de la comunidad anterior lleva al issue de seguimiento del Protocolo 30 presentado al mantenedor, donde puedes seguir el calendario de lanzamientos.

• 20 de octubre de 2026—Guía inicial publicada.
• 23 de octubre de 2026—Se agregaron versiones de lanzamiento del Protocolo 30 a la lista de lanzamientos (JavaScript SDK v17.3.0 y v16.4.0, Go SDK v0.8.0, Soroban Rust SDK 30.0.0-rc.1, Horizon, RPC y Galexie v30.0.0); las entradas de SDKs de la comunidad ahora enlazan a sus issues de seguimiento del Protocolo 30.

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