Stellar Warns Wallets to Update Before November Bell Votes

Bell’s W addresses change wallet handling

Bell builds on Stellar’s earlier smart-account delegation upgrade. That work expanded how accounts authorize activity. Protocol 30 addresses a different operational problem: distinguishing customers whose funds reach the same smart contract.

The CAP-84 specification combines a contract identifier with a 64-bit customer identifier. Its text representation begins with W. A service can receive payments into one contract and use the attached identifier to allocate balances in its own records.

The design extends an approach already available for conventional Stellar accounts. It avoids requiring a separate contract for every customer balance, but does not create individual onchain balances automatically. The business still needs its own accounting.

Transfer and mint events carry the multiplexing identifier using the existing event convention. Contracts expecting a plain address reject the new muxed type, so teams need to decide explicitly which inputs they accept. The specification also prohibits using muxed contract addresses directly as contract storage keys.

There is a consequential split between JavaScript releases. The v16.4.0 maintenance notes say it can decode the new data types, but its higher-level address helpers throw on muxed contract addresses.

The v17.3.0 release adds the corresponding address support. For an exchange, successfully reading a ledger and successfully accepting a withdrawal destination are therefore separate checks. A system can pass one and still fail the other.

That distinction makes deposit attribution, withdrawal validation and transfer-event processing practical tests before the votes. Treating W as an unfamiliar spelling of an existing address would miss the additional identifier that the receiving application needs.

Protocol 30 quantum signatures have limits

The Stellar Core v30.0.0 release, published October 16, bundles three changes: muxed contract addresses, ML-DSA signature verification and millisecond ledger timestamps. Available software is a preparation milestone, not proof that mainnet has adopted its protocol rules.

Under CAP-87, Soroban smart contracts gain functions for verifying three ML-DSA parameter sets. Verification checks whether a signature matches a message and public key. It gives custom accounts a cryptographic building block rather than automatically migrating existing users.

ML-DSA is covered by NIST’s FIPS 204 standard, finalized in August 2024. NIST describes it as designed to remain secure against a large-scale quantum computer. That is the security objective of the algorithm, not a claim that every surrounding wallet or custody process inherits the same protection.

Stellar’s Bell announcement explicitly keeps network transaction signatures on Ed25519. Quantum-resistant authorization inside a contract and changing the network’s native signing system are different projects.

The distinction is relevant alongside NEAR’s quantum-safe signing rollout. Networks can introduce new cryptographic options at different layers. Comparing their headlines without checking which accounts and transactions are covered obscures the actual scope.

Existing Stellar contracts are expected to continue working. Adopting the new verification functions requires development work; the release does not establish that every wallet supports them or that customers have switched signing methods.

November Bell votes put ledger readers on notice

The CAP-88 timing specification adds millisecond-resolution close times. The existing whole-second field remains, rounded down from the finer timestamp. Transaction time limits and other existing time-dependent rules retain their whole-second interpretation.

The change removes a technical constraint on future ledger intervals. It does not establish that Bell immediately delivers subsecond production ledgers or a particular increase in transaction throughput.

Raw-data consumers face a more immediate compatibility requirement. From the ledger following the protocol upgrade, the new header value types are required. Indexers, explorers and custom analytics tools using older data definitions may fail to decode them.

Consecutive ledgers can also share the same whole-second timestamp. Software that assumes advancing one ledger always means advancing at least one second needs review, even though the legacy time field remains available.

The guide schedules both votes for 17:00 UTC and still lists the Protocol 30 CLI release as pending. The Soroban Rust SDK is listed as a release candidate. Teams rebuilding contracts should follow the release status rather than assume every tool has reached a stable version together.

Source: Alternative.me, checked October 25: 54, Neutral, versus 51 the previous day. The broad sentiment index does not measure Bell readiness.

The next tests are the November 3 testnet vote, integration results and the remaining tool releases before November 23. The published dates remain a proposed schedule. Neither release availability nor a calendar entry confirms mainnet activation or complete support across wallets and exchanges.