Presentamos Bell, Protocolo 30 en Stellar

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

Bell incluye tres cambios propuestos: direcciones de contrato muxed que permiten a los contratos inteligentes atender a múltiples clientes, admitir la verificación de firmas poscuánticas en contratos inteligentes y temporización del ledger en milisegundos que elimina una barrera técnica para tiempos de cierre de ledger 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.

Esto es 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 terminan en la misma cuenta y tú rastreas quién posee qué fuera de cadena. Es cómo 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, multisig o una política de gasto.

Más empresas eligen una cuenta inteligente sobre una cuenta clásica justamente 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 portar un ID de 64 bits, escrito como un nuevo formato de dirección que empieza 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 (Billetera), 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 tenerlo en cuenta 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 usas en cuentas clásicas. Si brindas infraestructura de cuentas inteligentes a otras empresas, esto permite que tus clientes hagan lo mismo sin desplegar 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, asegura las cuentas con firmas de curva elíptica: Ed25519, secp256k1 y secp256r1. Estas se basan en un problema matemático que las computadoras actuales no pueden resolver, pero una computadora cuántica lo suficientemente grande sí podría.

No existe hoy una computadora cuántica públicamente conocida que pueda hacer esto, pero las claves públicas están en el ledger a la vista, y migrar una red a nueva criptografía lleva años, por lo 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 se entrega en software ampliamente usado 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 lo mantiene barato de invocar, 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: Este es el primer componente onchain del Plan de Preparación Cuántica. Un contrato de cuenta personalizado ahora puede requerir una firma poscuántica para gastar, que es la base 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 se mantienen en Ed25519 por ahora; un firmante nativo poscuántico para cuentas clásicas llegará en un cambio de protocolo futuro.

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

Un reloj en milisegundos para el ledger (CAP-88)

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

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

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

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

Si lees datos del ledger 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. Mientras la biblioteca requiere una actualización, ten en cuenta que el campo anterior closeTime no cambiará y aún reporta segundos enteros. Los detalles están en la guía de actualización en la sección “Cambios incompatibles”.

A continuación está la línea de tiempo propuesta del despliegue de Bell, Protocolo 30. Las fechas están sujetas a cambios:

• 16 de octubre de 2026—Stellar Core v30.0.0 lanzamiento estable disponible.
• Del 16 al 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 operas infraestructura, un validador o construyes sobre Stellar, hay pasos que tomar antes de las votaciones. La línea de tiempo completa, los enlaces de 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 de todos los anuncios de Bell, Protocolo 30, únete al Discord de Desarrolladores de Stellar, 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 de Stellar, que incluye CAP-84 (direcciones de contrato muxed), CAP-87 (verificación de firmas ML‑DSA post‑cuántica 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 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, un 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 sin procesar del libro mayor sin un SDK, actualiza tus definiciones XDR antes de la actualización.

¿Bell hace que Stellar sea post‑cuántica? No. Permite que los contratos inteligentes verifiquen firmas ML‑DSA, así las cuentas de contrato pueden optar por autorización post‑cuántica. Las firmas de las transacciones de la red siguen siendo Ed25519.

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