Stellar votes on protocol 30 on November 23: the next step for holders and wallets

This much is documented: Stellar is getting new network rules. On October 20, 2026 the Stellar Development Foundation introduced Bell, the network's protocol 30. It holds three change proposals: multiplexed contract addresses with a prefix not used so far, the verification of quantum-safe signatures inside smart contracts, and a ledger that will carry time in milliseconds. None of it goes live by itself. The validators vote on the testnet on November 3 and on the mainnet on November 23, both at 17:00 UTC. Our own reading follows further down in its own section.

Nothing changes about a holder's balance. There is no migration, old addresses stay valid, and nobody has to move XLM. Bell becomes noticeable where a service sleeps through the switch: in wallets that do not know the new address format, and in block explorers or data pipelines whose decoders are pinned to the old ledger definitions.

Stellar (XLM) traded at $0.1841 on the morning of October 21, around five percent above the previous day (CoinGecko). The daily high was $0.1842, the daily low $0.1753. A market value of $6.48 billion is enough for rank 21.

Bell bundles three change proposals: CAP-84, CAP-87 and CAP-88

A CAP at Stellar is a Core Advancement Proposal, a formal request to change the network rules. Protocol 30 carries three of them. CAP-84 extends contract addresses with an identifier, CAP-87 brings quantum-safe signature verification into smart contracts, CAP-88 changes how the ledger keeps time.

Bundling like that is usual at Stellar. The predecessor, protocol 28 under the name Adapter, cut the time between two ledgers on the mainnet from around 5.7 to 5 seconds. Since that switch the price has come back from a good $0.19 to today's $0.1841. A second development was added in October: we assessed the launch of the Chainlink data feeds on Stellar of October 14 at the time.

CAP-84 and the new Strkey prefix W: one contract address for many customers

Until now Stellar knew multiplexed addresses only for classic accounts. They start with an M and let an exchange run thousands of customers behind a single deposit address, because every payment carries its own identifier. Smart contracts could not do that.

CAP-84 closes that gap. A contract address will be able to carry a 64-bit multiplexing identifier, technically as the new variant SC_ADDRESS_TYPE_MUXED_CONTRACT. The matching Strkey prefix is W, described by the Foundation as an upside-down M. The identifier lands in the payment's transfer event, so the recipient reads the allocation along with it instead of having to roll out a separate contract for every customer.

In practice that means a payment service provider settling on Stellar will no longer need one address per customer. Anyone building software that accepts addresses, though, has to add W to validation, display and storage. Contracts that expect a plain Address in their interface will reject W addresses.

CAP-87 brings ML-DSA into the smart contract, not into the transaction signature

ML-DSA is one of the signature schemes the US standards body NIST adopted as a quantum-safe standard in 2024. CAP-87 builds verification of such signatures directly into Stellar Core instead of reproducing it in contract code. A smart contract can therefore verify an ML-DSA signature without the computing load making the contract unaffordable.

The limit of that change matters, and the Foundation draws it itself. The signatures of transactions on the network stay with Ed25519, the existing scheme. A native quantum-safe signer for classic accounts is named in the announcement as a plan for a later protocol version, not as part of Bell.

CAP-88 moves the ledger to milliseconds, the block time stays at five seconds

Until now the ledger kept its timestamps in whole seconds. CAP-88 switches to a millisecond clock. The gaps between two ledgers do not get shorter for the moment; the five-second target stays. What falls away is the floor of one ledger per second, which had blocked any later shortening.

For analysts the switch has an awkward side effect. Protocol 30 changes the format of the ledger header. Anyone decoding raw ledger data, for instance with their own indexer, an explorer or an analysis pipeline, has to lift the XDR definitions to protocol 30. Otherwise decoding fails on unknown fields. The closeTime field itself stays unchanged and continues to report whole seconds.

The roadmap to protocol 30: Stellar Core v30.0.0 has been out since October 16

The Foundation set out the timetable in the upgrade guide to Bell. Stellar Core v30.0.0 appeared as a stable release on October 16, 2026, and between October 16 and October 23 further stable versions follow for infrastructure and developer libraries. The validators vote on the testnet on November 3 and on the mainnet on November 23, both dates at 17:00 UTC. The Foundation adds that the dates may change.

The guide names no concrete version numbers for the individual SDKs; it points to each project's own release pages. It is unambiguous on how binding this is: the SDK update is not optional in this cycle. For applications that process addresses it is also only the first of two steps, because their own code then still has to accept W addresses.

For end users and holders the guide contains no instructions. That is no oversight but a consequence of the design: the work sits with the operators, not with the owners of the balances.

The validators decide on Bell, not the Stellar Development Foundation

A protocol version at Stellar is not switched on by the Foundation. Node operators enter a protocol version and a point in time in their configuration, and only once enough voting weight comes together does the network raise the version. That is why November 3 and November 23 each mark a vote in the calendar and not an activation.

Up to that point Bell is a proposal with code and a date, no more. Keeping that in mind makes headlines about Stellar's supposedly settled quantum protection read differently.

bitFlyer has not been crediting incoming XLM since October 19

How much payment traffic depends on the infrastructure around the network showed two days before the Bell announcement. The Japanese exchange bitFlyer said on X on October 20 that Stellar Lumens arriving from outside have not been credited to customer accounts as usual since around 23:49 Japanese time on October 19. The exchange names access restrictions at the Stellar Development Foundation's official Stellar interface, which bitFlyer uses, as the cause.

Sending XLM is not affected, nor are deposits and withdrawals of all other crypto assets. bitFlyer says it is working on resuming the crediting over a different route and will announce the resumption; the exchange gave no timetable. The notice concerns an exchange with no German customer base. The pattern is instructive all the same: a deposit can have been confirmed on the blockchain long ago and still be missing from the account, because the provider's bookkeeping sits between the two.

XLM at $0.1841: the price sits 41.6 percent below the year-ago level

The price picture stays weak, even with the gain of around five percent on Tuesday. Over a week there is a loss of 2.9 percent, over a month one of 10.7 percent, over a year one of 41.6 percent (CoinGecko, October 21, 2026). The all-time high of $0.8756 from January 2018 is 79 percent away from the price.

Since October 7, when XLM tested the 20-cent mark on a 6.3 percent daily loss, the price has not won that mark back. Tuesday's high of $0.1842 sits a good eight percent below it. There are 35.2 billion XLM in circulation out of 50.0 billion in total, and trading turnover over the past 24 hours came to $127.6 million. Measured against market value that is a turnover of just under two percent, a thin market for a top-25 asset.

Buying route in Germany: MiCA authorisation, custody and the new address format

Anyone buying XLM in Germany has done so, since the EU's MiCA regulation applies in full, through providers holding an authorisation as a crypto asset service provider. BaFin keeps a public register of authorised institutions, and every serious provider names its authorisation in its terms. Which platforms hold such an authorisation and what they charge in fees and spread is set side by side in our comparison of crypto exchanges.

On custody Bell touches daily life most directly. Once W addresses are in circulation from the end of November, the software you use for sending has to recognise them as valid. Hardware wallets get that through a firmware update, exchanges through their SDK. For the coming weeks that means: install firmware updates when the manufacturer offers them, and send a small amount first when an address looks unfamiliar. How reliably a given device is supplied with firmware is the real selection criterion here.

A warning belongs with it: network upgrades are a popular hook for fraud. For Bell there is no token swap, no registration and no wallet that would have to migrate a balance. Any demand that you enter your recovery words somewhere because of protocol 30 is an attack.

Tax on XLM: the one-year holding period and swaps into other coins

For tax purposes XLM count in Germany as another asset within the meaning of section 23 of the Income Tax Act. More than twelve months have to lie between purchase and sale for the gain to stay tax free. Within that period a threshold of 1,000 euros a year applies to all private disposals taken together; once it is exceeded, the entire gain is taxable.

A protocol upgrade triggers no taxable event by itself, because it constitutes neither a swap nor a receipt. A move from XLM into another coin does, even without a detour through euros. If you buy across several platforms, you need records that carry acquisition dates forward on a first in, first out basis.

Our assessment: Bell does not make Stellar quantum-safe

From this desk's point of view the quantum angle is being stretched too far in the coverage. The evidence sits in the announcement itself: CAP-87 brings ML-DSA verification into the smart contract, the network's transaction signatures stay with Ed25519, and the Foundation defers a native quantum-safe signer for classic accounts to a later protocol version. A balance on an ordinary Stellar account hangs on the same curve after Bell as before.

Against that stands the fact that the groundwork has value. A network whose contracts can verify ML-DSA can make the move later without opening a second front, and the step comes earlier than at most large blockchains. The closer effect of Bell is a different one, though: CAP-84 cuts costs for payment service providers, and that is exactly where Stellar earns its money. Together with the $4 billion in tokenised assets the Foundation reports for its ecosystem, that is the part of the announcement more likely to carry the price over the medium term than the cryptography.

Protocol 30: the validator majority decides by November 23

1. Check over the coming weeks whether your wallet manufacturer publishes a firmware or app update for protocol 30, and install it before the mainnet vote runs on November 23. Which devices are maintained how reliably is shown by the hardware wallet comparison.
2. If your XLM sit on an exchange, a look at its status notices is enough: the bitFlyer case shows that deposits and withdrawals hang on the provider's connection and not on the network. An authorised alternative is in the comparison of crypto exchanges.
3. Note the acquisition date and purchase price of every position before you reshuffle ahead of the upgrade. The one-year mark decides the tax, not the protocol; the right programmes are in the comparison of tax tools.

(As of October 21, 2026. This article is not investment advice. Prices and fee structures change; check the terms with the provider before you buy.)