The Stellar Development Foundation introduced Bell, the proposed Protocol 30 upgrade, on October 20, 2026, outlining changes to business smart accounts, digital signatures and ledger timing. The next decisions belong to network validators: votes are scheduled for November 3 on the test network and November 23 on the main network.
Bell would let one smart contract distinguish payments intended for different customers and verify a new class of signatures designed to resist quantum attacks. It would also prepare the network for more precise ledger timing. Those capabilities remain conditional on approval, and they should not be confused with an immediate speed increase or complete quantum protection for Stellar.
One contract could receive payments for many customers
The most practical change concerns a problem familiar to exchanges and payment businesses: collecting funds centrally while knowing which customer each payment belongs to. Stellar's existing account system already supports an account address combined with a customer identifier. CAP-84, one of Bell's formal protocol proposals, extends that model to contract addresses.
A smart account uses a contract to decide how funds can be spent. Unlike an account governed only by a conventional key, it can enforce rules such as multiple approvals or spending policies. Bell would add a 64-bit identifier to a contract address, represented by an address beginning with W. Transfer events would carry the identifier so the business can match an incoming payment to its customer records.
The distinction is important: the identifier supplies routing information. CAP-84 does not create an independently controlled wallet for each customer or change the underlying contract's authorization rules. Readers comparing custody arrangements can start with how crypto wallets control access to funds. A more convenient deposit address does not, by itself, change who controls the money.
Post-quantum verification has a defined boundary
Another proposal, CAP-87, would add support for verifying ML-DSA signatures inside Stellar's smart contract environment. ML-DSA is a digital signature algorithm standardized by the US National Institute of Standards and Technology in August 2024. Digital signatures allow a recipient to check who authorized data and whether that data has changed.
NIST describes ML-DSA as designed to remain secure against an adversary with a large quantum computer. It also warns that implementing a standard does not automatically make an entire system secure: private keys still need protection, and the surrounding software still matters.
Stellar's proposal would provide three verification functions for the algorithm's standardized parameter sets. Running verification through the underlying platform gives contract developers a shared implementation instead of requiring each application to reproduce the cryptography itself.
That could support custom accounts using post-quantum authorization or contracts checking signed information from external systems. However, CAP-87 explicitly leaves Stellar's network transaction signatures on the existing Ed25519 scheme. Broader migration is a separate task. Bell therefore offers an additional building block, with benefits depending on application adoption and design.
A finer clock does not promise faster settlement immediately
CAP-88 addresses a less visible constraint. Stellar currently expresses ledger closing times in whole seconds. That limits the timing intervals the protocol can represent, even if future software can process work more quickly. A ledger is the network's agreed record of its state at a particular point.
The proposal adds millisecond precision, allowing consecutive ledgers to carry distinct times within the same second. Existing time-based rules would still use whole seconds, with the more precise value rounded down. This preserves the meaning of familiar transaction deadlines while allowing finer timing underneath.
The foundation says Bell does not itself reduce the network's five-second ledger interval. Faster targets would require further work. For readers following Stellar's payment and smart contract network, the useful distinction is between removing a technical limit and demonstrating a performance improvement under real operating conditions.
Infrastructure teams have work before the votes
Software preparation is already underway. Stellar Core version 30.0.0 was released on October 16, and its release notes identify all three proposals. Publishing the software does not activate the new rules across the network.
In its upgrade guide, updated October 23, the foundation tells operators to update the software development kits used by their applications before the relevant vote. Programs reading raw ledger data also need updated format definitions. Older decoders may fail when they encounter the new ledger structure.
Address handling needs attention as well. Updating a library supplies support for the W format, but an application's own validation, storage and display logic must accept it. The guide says existing smart contracts continue working; adopting the new contract features requires appropriate updated tooling.
The two scheduled votes are at 17:00 UTC, and the foundation cautions that dates can change. Until approval and implementation, the concrete development is the publication of Bell's proposed changes and preparation requirements. Application compatibility, adoption and later performance gains remain matters to watch.