Stellar schedules Bell’s testnet vote for today, before a separate mainnet vote

A test vote before any mainnet decision

Stellar testnet validators are due to vote on Bell, the Protocol 30 upgrade, on November 3, 2026, at 17:00 UTC. The official guide schedules a separate mainnet vote for November 23 at the same time. These dates remain subject to the validation process and may change. At the time of preparation, the testnet vote is still ahead: neither its approval nor mainnet activation is presented as a foregone conclusion.

The immediate purpose is to let developers and operators test changes before their possible arrival in the environment used for real transactions. A test network is used to exercise software and integrations; its evolution is not equivalent to a commercial deployment. Bell combines several technical changes, but the foundation’s longer-term objectives must not be confused with features already available everywhere on Stellar.

One contract for many customers and signatures with a limited scope

One proposal extends the principle of multiplexed accounts to contract addresses. It allows an identifier to be attached to a contract address to distinguish payments from multiple customers received by a single smart account. Applications must recognize the new format beginning with W and adapt their type checks. The aim is to reduce the need to deploy a separate contract for each user while retaining identification of transfers.

Another change brings ML-DSA signature verification to smart contracts. The foundation presents it as a step toward post-quantum cryptography, with implementation in the network software. The scope matters: network transaction signatures remain based on Ed25519 at this stage. Bell therefore does not automatically make all existing accounts resistant to quantum attacks, and adoption of new account models remains a separate task.

A more precise clock and software updates

Bell also provides for millisecond measurement of ledger time. This change removes a technical limit tied to whole-second timestamps and prepares finer closing intervals in future changes. By itself, it is not a promise of immediately faster transactions. The document distinguishes this technical foundation from faster-ledger tests on experimental branches, without announcing generally deployed performance improvements.

The header-format change requires preparation by tools that read network data. Development-library users must follow compatible releases; indexers, explorers and tools that decode data directly must update their definitions. The guide specifies that the historical close-time field continues to express whole seconds. The next evidence to follow will be the actual testnet vote result, integration testing and, separately, the mainnet validators’ decision.