Introducing Bell, Protocol 30 on Stellar

The next upgrade to the Stellar network, Bell, Protocol 30, is coming up. It's designed to make smart accounts ready for businesses at scale and start the work on two longer-term goals: quantum-safe signatures and faster ledgers.

Bell includes three proposed changes: muxed contract addresses that allow smart contracts to serve multiple customers, support for post-quantum signature verification in smart contracts, and millisecond ledger timing that removes a technical barrier to faster ledger close times.

The testnet vote is on November 3, 2026 and the mainnet vote on November 23, 2026.

Here's what's included in Bell, why it matters, and what happens next.

One contract, many customers (CAP-84)

If you run an exchange, a ramp, or a custodial product on Stellar, you likely already use muxed accounts. A muxed account is one Stellar account with an ID attached, so every customer gets their own address to deposit to while the funds all land in the same account and you track who owns what offchain. It's how a business holds customer funds without opening an account per customer.

Smart accounts have no equivalent. A smart account is an account that is a smart contract rather than a keypair, which lets it set its own rules for who can spend, whether through a passkey, multisig, or a spending policy.

More businesses are choosing a smart account over a classic account for exactly that flexibility, but a smart account that holds customer balances has no way to tell incoming payments apart, which has meant one contract per customer. That works for ten customers. It doesn't work for a million.

CAP-84 closes the gap. A contract address can now carry a 64-bit ID, written as a new address format that starts with W.

💡 Why W? “It's an upside-down M. We considered reusing M, but decided it was better to have a distinct type so developers always know what they're working with.”—Jake Urban, Senior Engineering Manager (Wallet), Stellar Development Foundation

Send a token to a muxed contract address and it lands in the contract as before, with the ID recorded in the transfer event so your application knows which customer it was for.

The design reuses the muxed-account machinery, so if your code already handles M addresses, the W address follows the same pattern. It is still a new address type and developers need to account for it in applications and smart contracts: (1) update your SDKs and (2) add the W address variant to your type checks.

What it means for you: if your product holds customer funds in a smart account, you can now run the same omnibus model you run on classic accounts. If you provide smart-account infrastructure to other businesses, this lets your customers do the same without deploying a contract per end user. If you build wallets or explorers, expect W addresses after the upgrade. See the upgrade guide.

Quantum-safe signatures for smart contracts (CAP-87)

Stellar, like almost every major blockchain, secures accounts with elliptic-curve signatures: Ed25519, secp256k1 and secp256r1. These rest on a math problem that today's computers can't solve, but a large enough quantum computer could.

No publicly known quantum computer can do this today but public keys sit on the ledger in plain view, and migrating a network to new cryptography takes years, so the industry has started early.

In 2024, the US National Institute of Standards and Technology (NIST) finalized its post-quantum signature standards. ML-DSA is one of them, and it already ships in mainstream software such as OpenSSL, Java and AWS's key management service.

CAP-87 lets Stellar smart contracts verify ML-DSA signatures. Verifying one takes far more computation than verifying an Ed25519 signature, so Bell does it inside Stellar Core rather than in contract code. That keeps it cheap to call, and it means the implementation is written and tested once, against the official test vectors, instead of by every contract author.

What it means for you: This is the first onchain piece of Stellar's Quantum Preparedness Plan. A custom account contract can now require a quantum-safe signature to spend, which is the building block wallets and custodians need before they can offer quantum-safe contract accounts.

CAP-87 protects authorization inside smart contracts. Network transaction signatures stay Ed25519 for now; a native post-quantum signer for classic accounts will come in a future protocol change.

The pieces around it already exist, since the hardware security modules and key-management services custodians rely on ML-DSA today. What comes next is adoption, and that is still in its research phase across the industry.

A millisecond clock for the ledger (CAP-88)

In September, Adapter (Protocol 28) brought mainnet ledger close times down from about 5.7 seconds to 5 seconds. CAP-88 sets up the next step.

Today, Stellar records each ledger's close time in whole seconds, so the network can only target whole-second intervals, and never less than one second apart. At five or six seconds that never mattered. As close times keep falling, it becomes the thing that sets the pace. Moving the ledger to a millisecond clock opens up finer-grained close times for future protocol changes to target.

What it means for you: CAP-88 is the protocol-level prerequisite for faster ledgers. The Stellar Core team is already using it to test faster ledger close times on experimental branches.

Bell changes the format of the ledger header so anything that reads the ledger data needs to understand the format. If you use a Stellar SDK, upgrade before the votes and you should be covered.

If you read ledger data without an SDK (an indexer, an explorer, an analytics pipeline or custom tooling) update your XDR definitions before the upgrade or your decoder will stop working. While the library requires an update, note that the previous closeTime field will not change, and still reports whole seconds. Details are in the upgrade guide under “Breaking changes.”

The proposed Bell, Protocol 30 roll out timeline is below. Dates are subject to change:

• October 16, 2026—Stellar Core v30.0.0 stable release available.
• October 16 to 23, 2026—Additional stable releases (infrastructure and SDKs) available.
• November 3, 2026, 1700 UTC—Testnet upgrade vote.
• November 23, 2026, 1700 UTC—Mainnet upgrade vote.

If you run infrastructure, a validator, or build on Stellar, there are steps to take before the votes. The full timeline, release links, and preparation instructions for validators, infrastructure operators, SDK users, wallets, exchanges, issuers, ramps, and protocols are in the Bell, Protocol 30 Upgrade Guide.

To stay up to date on all Bell, Protocol 30 announcements, join the Stellar Developer Discord, where the ecosystem coordinates the upgrade in the #protocol-next channel.

What is Bell, Protocol 30? The next Stellar network upgrade, carrying CAP-84 (muxed contract addresses), CAP-87 (ML-DSA post-quantum signature verification for smart contracts) and CAP-88 (millisecond ledger close times).

When does Bell go live? Validators vote on November 3, 2026 for testnet and on November 23, 2026 for mainnet, both at 1700 UTC. The upgrade takes effect if they approve.

What is a smart account? An account that is a smart contract rather than a keypair, so it can set its own rules for who can spend, such as a passkey, a multisig or a spending policy. Two of Protocol 30's three changes extend what a smart account can do.

Do I need to do anything? Upgrade to the latest SDK before the votes. If your product handles addresses, make sure it accepts the new W address type for muxed contracts. If you decode raw ledger data without an SDK, update your XDR definitions before the upgrade.

Does Bell make Stellar post-quantum? No. It lets smart contracts verify ML-DSA signatures, so contract accounts can opt into quantum-safe authorization. Network transaction signatures remain Ed25519.

Does Bell, Protocol 30 make Stellar produce blocks faster than 5s? Not by itself. It removes the one-ledger-per-second floor in the protocol so block times can come down in future steps.