Presentamos Bell, Protocolo 30 en Stellar

La próxima actualización de la red de Stellar, Bell, Protocolo 30, se aproxima. Está diseñada para preparar las cuentas inteligentes para empresas a escala y empezar el trabajo en dos objetivos a más largo plazo: firmas poscuánticas y libros mayores más rápidos.

Bell incluye tres cambios propuestos: direcciones de contrato muxed que permiten a los contratos inteligentes atender a múltiples clientes, soporte para verificación de firmas poscuánticas en contratos inteligentes y temporización del libro mayor en milisegundos que elimina una barrera técnica para tiempos de cierre más rápidos.

La votación en testnet es el 3 de noviembre de 2026 y la de mainnet el 23 de noviembre de 2026.

Aquí está lo que incluye Bell, por qué importa y qué sigue.

Un contrato, muchos clientes (CAP-84)

Si operas un exchange, una rampa o un producto de custodia en Stellar, probablemente ya usas cuentas muxed. Una cuenta muxed es una cuenta de Stellar con un ID adjunto, de modo que cada cliente obtiene su propia dirección para depositar mientras los fondos llegan a la misma cuenta y tú llevas registro de quién posee qué fuera de la cadena. Así es como un negocio mantiene fondos de clientes sin abrir una cuenta por cliente.

Las cuentas inteligentes no tienen equivalente. Una cuenta inteligente es una cuenta que es un contrato inteligente en lugar de un par de claves, lo que le permite fijar sus propias reglas sobre quién puede gastar, ya sea mediante una passkey, multifirma o una política de gasto.

Más negocios están eligiendo una cuenta inteligente sobre una cuenta clásica precisamente por esa flexibilidad, pero una cuenta inteligente que mantiene saldos de clientes no tiene forma de distinguir pagos entrantes, lo que ha significado un contrato por cliente. Eso funciona para diez clientes. No funciona para un millón.

CAP-84 cierra la brecha. Una dirección de contrato ahora puede llevar un ID de 64 bits, expresado como un nuevo formato de dirección que comienza con W.

💡 ¿Por qué W? “Es una M al revés. Consideramos reutilizar la M, pero decidimos que era mejor tener un tipo distinto para que los desarrolladores siempre sepan con qué están trabajando.”—Jake Urban, Gerente Senior de Ingeniería (Wallet), Stellar Development Foundation

Envía un token a una dirección de contrato muxed y llega al contrato como antes, con el ID registrado en el evento de transferencia para que tu aplicación sepa para qué cliente era.

El diseño reutiliza la maquinaria de cuentas muxed, así que si tu código ya maneja direcciones M, la dirección W sigue el mismo patrón. Sigue siendo un tipo de dirección nuevo y los desarrolladores deben contemplarlo en aplicaciones y contratos inteligentes: (1) actualiza tus SDKs y (2) agrega la variante de dirección W a tus verificaciones de tipo.

Qué significa para ti: si tu producto mantiene fondos de clientes en una cuenta inteligente, ahora puedes ejecutar el mismo modelo ómnibus que ejecutas en cuentas clásicas. Si brindas infraestructura de cuentas inteligentes a otros negocios, esto permite que tus clientes hagan lo mismo sin implementar un contrato por usuario final. Si creas billeteras o exploradores, espera direcciones W después de la actualización. Consulta la guía de actualización.

Firmas poscuánticas para contratos inteligentes (CAP-87)

Stellar, como casi toda gran blockchain, protege cuentas con firmas de curva elíptica: Ed25519, secp256k1 y secp256r1. Estas se basan en un problema matemático que las computadoras de hoy no pueden resolver, pero una computadora cuántica lo suficientemente grande sí podría.

Ninguna computadora cuántica conocida públicamente puede hacer esto hoy, pero las claves públicas están en el libro mayor a la vista, y migrar una red a criptografía nueva toma años, así que la industria ha empezado temprano.

En 2024, el Instituto Nacional de Estándares y Tecnología de EE. UU. (NIST) finalizó sus estándares de firmas poscuánticas. ML-DSA es uno de ellos, y ya viene en software de uso general como OpenSSL, Java y el servicio de gestión de claves de AWS.

CAP-87 permite que los contratos inteligentes de Stellar verifiquen firmas ML-DSA. Verificar una requiere mucha más computación que verificar una firma Ed25519, así que Bell lo hace dentro de Stellar Core en lugar de en el código del contrato. Eso mantiene barata su invocación y significa que la implementación se escribe y prueba una sola vez, contra los vectores de prueba oficiales, en lugar de por cada autor de contratos.

Qué significa para ti: Esta es la primera pieza onchain del Plan de Preparación Cuántica de Stellar. Un contrato de cuenta personalizado ahora puede exigir una firma poscuántica para gastar, que es el bloque de construcción que las billeteras y los custodios necesitan antes de poder ofrecer cuentas de contrato poscuánticas.

CAP-87 protege la autorización dentro de los contratos inteligentes. Las firmas de transacciones de la red siguen siendo Ed25519 por ahora; un firmante poscuántico nativo para las cuentas clásicas llegará en un futuro cambio de protocolo.

Las piezas alrededor ya existen, ya que los módulos de seguridad de hardware y los servicios de gestión de claves en los que confían los custodios usan ML-DSA hoy. Lo que sigue es la adopción, y eso aún está en fase de investigación en toda la industria.

Un reloj en milisegundos para el libro mayor (CAP-88)

En septiembre, Adapter (Protocolo 28) redujo los tiempos de cierre del libro mayor en mainnet de aproximadamente 5,7 segundos a 5 segundos. CAP-88 prepara el siguiente paso.

Hoy, Stellar registra el tiempo de cierre de cada libro mayor en segundos enteros, así que la red solo puede apuntar a intervalos de segundos completos, y nunca a menos de un segundo de diferencia. A cinco o seis segundos eso nunca importó. A medida que los tiempos de cierre siguen bajando, se convierte en lo que marca el ritmo. Mover el libro mayor a un reloj en milisegundos abre tiempos de cierre más granulares a los que apunten futuros cambios de protocolo.

Qué significa para ti: CAP-88 es el prerrequisito a nivel de protocolo para libros mayores más rápidos. El equipo de Stellar Core ya lo está usando para probar tiempos de cierre más rápidos en ramas experimentales.

Bell cambia el formato del encabezado del libro mayor, por lo que cualquier cosa que lea los datos del libro mayor necesita entender el formato. Si usas un SDK de Stellar, actualiza antes de las votaciones y deberías estar cubierto.

Si lees datos del libro mayor sin un SDK (un indexador, un explorador, una canalización de analítica o herramientas personalizadas) actualiza tus definiciones XDR antes de la actualización o tu decodificador dejará de funcionar. Aunque la biblioteca requiere una actualización, ten en cuenta que el anterior closeTime campo no cambiará y aún reporta segundos enteros. Los detalles están en la guía de actualización bajo “Cambios que rompen compatibilidad”.

La línea de tiempo propuesta para el despliegue de Bell, Protocolo 30 está abajo. Las fechas están sujetas a cambio:

• 16 de octubre de 2026—Stellar Core v30.0.0 versión estable disponible.
• 16 a 23 de octubre de 2026—Lanzamientos estables adicionales (infraestructura y SDKs) disponibles.
• 3 de noviembre de 2026, 17:00 UTC—Voto de actualización de testnet.
• 23 de noviembre de 2026, 17:00 UTC—Voto de actualización de mainnet.

Si operas infraestructura, un validador o construyes en Stellar, hay pasos que tomar antes de las votaciones. La línea de tiempo completa, los enlaces a lanzamientos y las instrucciones de preparación para validadores, operadores de infraestructura, usuarios de SDK, billeteras, exchanges, emisores, rampas y protocolos están en la Guía de Actualización de Bell, Protocolo 30.

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

¿Qué es Bell, Protocolo 30? La próxima actualización de la red Stellar, que incluye CAP-84 (direcciones de contrato muxed), CAP-87 (verificación de firmas ML-DSA poscuánticas para contratos inteligentes) y CAP-88 (tiempos de cierre del libro mayor en milisegundos).

¿Cuándo entra en vigor Bell? Los validadores votan el 3 de noviembre de 2026 para testnet y el 23 de noviembre de 2026 para mainnet, ambos a las 1700 UTC. La actualización entra en vigor si la aprueban.

¿Qué es una cuenta inteligente? Una cuenta que es un contrato inteligente en lugar de un par de claves, por lo que puede fijar sus propias reglas sobre quién puede gastar, como una passkey, una multisig o una política de gasto. Dos de los tres cambios del Protocolo 30 amplían lo que puede hacer una cuenta inteligente.

¿Necesito hacer algo? Actualiza al SDK más reciente antes de las votaciones. Si tu producto maneja direcciones, asegúrate de que acepte el nuevo tipo de dirección W para contratos muxed. Si decodificas datos en bruto del libro mayor sin un SDK, actualiza tus definiciones XDR antes de la actualización.

¿Bell hace que Stellar sea poscuántica? No. Permite que los contratos inteligentes verifiquen firmas ML-DSA, de modo que las cuentas de contrato puedan optar por una autorización segura frente a la computación cuántica. Las firmas de transacciones de la red siguen siendo Ed25519.

¿Bell, Protocolo 30, hace que Stellar produzca bloques más rápido que 5 s? No por sí solo. Elimina el límite mínimo de un libro mayor por segundo en el protocolo para que los tiempos de bloque puedan bajar en pasos futuros.