Stellar’s Bell, Protocol 30, has proposed upgrade votes on November 3, 2026 for testnet and November 23 for mainnet, both at 17:00 UTC. As of this October 27 preparation article, those votes are still ahead. The work for an integration is concrete: prepare for new muxed contract addresses and updated ledger decoding, while keeping a planned vote separate from an activated network rule.
Prepare for the receiving address your application may encounter
The Bell introduction describes three changes: muxed contract addresses, ML-DSA signature verification in smart contracts and millisecond-resolution ledger timing. The upgrade guide says the SDK supplies parsing support for the new W address type, while applications must accept that variant in their own validation, display and storage logic. Installing the parser alone is therefore not the whole address-handling task.
For a receiving service, the useful question is whether its complete workflow understands the destination. An address may pass a library’s parser and still be rejected by an application’s older type check. Or a display layer may shorten away information that the operator needs to reconcile the recipient. Treat the address exactly as supplied by the receiving service; do not manufacture a new format by changing the first letter of an existing address.
| Integration boundary | Preparation question | Evidence that matters |
|---|---|---|
| Receiving address | Do validation, display, storage and routing accept the new variant? | A test covering the application path, not only the SDK parser |
| Transfer reconciliation | Does the system retain the destination’s multiplexing identifier? | A test record linking the intended recipient to the transfer event |
| Ledger decoder | Can the consumer read Protocol30 XDR values? | A decoder test against the updated definitions |
| Time-based processing | Does code incorrectly assume each new ledger advances a whole second? | A test using distinct ledger records within one displayed second |
| Account authorization | Is a new smart-contract verification feature actually adopted? | The account’s own implemented authorization policy |
Millisecond precision changes what a timestamp can prove
The primary CAP-88 specification keeps the existing whole-second closeTime meaning while adding millisecond resolution and new XDR variants. Time-based protocol features continue using whole seconds. Applications that decode the underlying data still need the updated definitions. Do not simply reinterpret an existing seconds field as milliseconds.
In a fictional data-processing test, one ledger closes at 12:00:00.100 and another at 12:00:00.900. Both round down to the same whole-second display. That does not make them the same ledger or prove a duplicate payment. If software uses only the displayed second to identify new records, this example exposes an assumption worth removing. The two invented times are not a claim about observed mainnet performance.
Likewise, greater clock precision does not itself set the interval at which ledgers close or the time an exchange credits an account. A prerequisite for future performance work is not a guarantee of an immediate millisecond transfer. Preserve the distinction between network timing, a transaction’s result and a receiving service’s internal processing.
Smart-contract verification is an opt-in building block
The Bell introduction confines the proposed ML-DSA verification support to smart contracts and says network transaction signatures remain Ed25519. It should not be reported as every Stellar account becoming quantum-safe at once. A contract account needs its own adopted authorization policy; an ordinary holder should not infer a demand to replace keys or send funds to a quantum-upgrade address.
For operators, this creates separate acceptance questions rather than one upgrade checkbox. Can the data pipeline decode the ledger? Can the application handle a permitted destination? Has a particular account actually changed its signing policy? A successful answer to one does not establish the others, and none should be substituted for confirmation of the vote’s actual outcome.
- Read the current guide and confirm the proposed testnet or mainnet vote relevant to your environment.
- Update the relevant SDK and raw-data definitions, then test the application’s complete address-handling path.
- Review reconciliation and time-based assumptions using explicit test cases such as the same-second example.
- After the vote, confirm the actual network stage before describing features as active; verify the recipient’s current support before a real transfer.
For a holder preparing an exchange
Use the receiving service’s current address and any required routing information. A protocol announcement is not permission to omit information that service still requires. Keep the quote and transaction record so support can distinguish delivery from an application-processing problem.
Check supported assets and networks, read the order workflow and select an offered simple swap route. These KOT.CASH pages do not assert W address support, a custom signing policy or a promised Bell settlement time. Confirm the actual exchange instructions for the operation you intend to make.
FAQ
Is the Stellar Protocol30 vote the same as completed activation?
The published dates are proposed votes, with activation conditional on approval. Check the actual network stage before reporting a feature as live.
Does the new Stellar address format require editing an old address?
Use the complete receiving details supplied by the recipient. Changing a prefix does not create a valid destination or prove that a service supports it.
Does a Stellar address check prove the recipient’s application supports W addresses?
A parser check is only one part of the workflow. The service must handle the variant in its own validation, display, storage and routing.