Desarrolladores

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

Author

Stellar Development Foundation

Publishing date

Última actualización: 20 de octubre de 2026

Esta guía está diseñada para ayudar a empresas y desarrolladores a prepararse para Bell, Protocol 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 sobre lo que incluye Bell en el blog del anuncio, y mantente al día con todos los anuncios relacionados con Bell en el Stellar Developer Discord, donde el ecosistema se 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, 17:00 UTC—Votación de actualización de Testnet.
23 de noviembre de 2026, 17:00 UTC—Votación de actualización de Mainnet.

¿Qué necesitas hacer para prepararte?

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 fallar al 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 ofrece un analizador para direcciones W; tu propio código tiene que aceptarlas. Añade la variante de dirección W a tus comprobaciones de tipo dondequiera que valides, muestres o almacenes direcciones, y donde leas el destino de un evento de transferencia. Consulta los 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 reconstruyas con el Soroban SDK 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 en Soroban. El tipo original SOROBAN_CREDENTIALS_ADDRESS sigue funcionando 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 convenga.

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

Instala los lanzamientos del Protocolo 30 en cuanto estén disponibles (despliegue a partir del 16 de octubre de 2026, con todos los componentes disponibles para el 23 de octubre de 2026).

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: Publicaremos 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: Publicaremos 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, vía 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 tras la actualización, los encabezados del libro mayor llevan un nuevo tipo de valor, y los decodificadores compilados contra XDR antiguos fallarán al procesarlo.

Si ejecutas un validador

Instala Stellar Core v30.0.0, lanzado 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, un exchange, un emisor, un on/off-ramp o un protocolo

Billeteras, on/off-ramps e emisores: Actualiza a la última versión del SDK (ver arriba) antes de la votación de Mainnet. Luego contempla 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. Añádelo 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 añade compatibilidad para retirar a direcciones de contrato multiplexadas (el tipo de dirección W). Si usas cuentas muxed 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 transferencias) son funciones optativas que adoptas cuando reconstruyes con el Soroban SDK 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 un simple "Address rechaza una dirección W, y otra declarada con MuxedAddress acepta ambas. Los contratos que leen la marca de tiempo del libro mayor deben revisar la nota de CAP-88: ahora los libros mayores consecutivos pueden informar la misma marca de tiempo con segundos enteros.

Cambios incompatibles

No se espera que Bell, Protocol 30 introduzca incompatibilidades hacia atrás a nivel de transacciones. Todos los cambios son aditivos. Dos de ellos requieren acciones posteriores: CAP-84 para cualquier cosa que maneje direcciones, y una actualización de XDR para cualquier cosa que decodifique datos del libro mayor sin procesar. Esa actualización cubre tanto CAP-84, dado que el nuevo tipo de dirección aparece en las 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 muxed): Agrega una nueva 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 strkey W, definido en SEP-23.

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

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

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 de segundo entero antiguos 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 actualizarse a las definiciones XDR del Protocolo 30, o la decodificación fallará en brazos de unión desconocidos.

Más allá de la actualización del esquema, no se requiere ningún cambio semántico: el campo de segundo entero existente closeTime no cambia y equivale al valor en milisegundos redondeado hacia abajo. Los límites de tiempo de transacción, minSeqAge, predicados de saldos reclamables, Soroban ledger_timestamp, y la programación de actualizaciones mantienen semántica de segundo entero. Una suposición se debilita: los libros mayores consecutivos ahora pueden cerrarse dentro del mismo segundo entero, así que “un libro mayor después” ya no implica “al menos un segundo después”. No se necesita acción para las integraciones normales basadas en SDK más allá del aumento 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 la 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ántica dentro de los contratos inteligentes (por ejemplo, cuentas personalizadas). Las firmas de transacciones a nivel de red siguen siendo Ed25519.

Lanzamientos del Protocolo 30

A continuación están los enlaces a los lanzamientos relevantes para el Protocolo 30. Por favor revisa las notas de cada lanzamiento para instrucciones y requisitos específicos y, salvo que se indique lo contrario, elige el “Último lanzamiento”.

Infraestructura de Stellar

SDKs

Ten en cuenta que algunos SDKs listados son mantenidos por la comunidad; revisa cada repositorio para compatibilidad con el Protocolo 30 y tiempos de lanzamiento.

Registro de cambios

20 de octubre de 2026—Guía inicial publicada.

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.