Stellar’s public test network is reporting protocol 30 while its production network remains on protocol 29, according to Horizon records retrieved by NetNapz on 7 November. The observation moves Bell’s testnet coverage beyond an expired voting countdown, while keeping the mainnet decision separate.

What the network records show

The testnet ledger record for sequence 5,604,908, closed at 10:43:01 UTC on 7 November, reports protocol_version: 30. The mainnet record for sequence 65,352,429, closed six seconds later, reports version 29. The corresponding Horizon root responses also distinguish the networks by passphrase and current protocol version.

These are timestamped observations from public API services, not a NetNapz-operated validator or a reconstruction of the upgrade vote. They establish the protocol versions those records report, but not the exact activation ledger, every operator’s readiness or the health of every application.

The foundation’s upgrade guide, last updated 23 October, scheduled the testnet vote for 3 November and the mainnet vote for 23 November at 17:00 UTC. The latter remains a scheduled governance event, not evidence of completed production activation.

Compatibility work is the immediate issue

The guide says SDK upgrades are required because Bell changes ledger-header encoding. Custom raw-data decoders need updated XDR definitions. It also adds muxed contract addresses with a W prefix; installing a parser alone does not update an application’s validation, display, storage and routing logic.

For teams serving multiple customers through smart accounts, testing the complete payment path matters more than simply accepting a new string. A valid destination can still be mishandled downstream if accounting and event-processing systems do not preserve the customer identifier.

What Bell changes—and what it does not

The foundation’s Bell explanation describes three components: contract addresses carrying a 64-bit identifier, ML-DSA signature verification inside smart contracts, and millisecond ledger timing. Contract-level support for a post-quantum signature scheme does not change network transaction signatures from Ed25519.

The finer clock is groundwork for later reductions in ledger intervals. Bell alone does not establish faster production ledgers. A protocol version also cannot establish measured throughput, payment adoption or incremental XLM demand.

NetNapz assessment

The practical milestone is a test environment on the new protocol while production remains on the previous version. That gives integrators a place to test the changes against their own systems before the scheduled mainnet decision. It does not remove the need to verify the outcome of that decision.

The useful follow-up is evidence of successful end-to-end integration: decoding ledger data, accepting the new address type, crediting the right customer and handling failures correctly. Mainnet activation and sustained operational reliability would be later, distinct milestones. This report makes no token-price causation claim.

Sources and verification limits

NetNapz retrieved both Horizon roots and latest-ledger responses directly at approximately 10:43 UTC on 7 November, checked the foundation’s announcement and guide, and verified featured attachment 4386 and its image attribution. The API observations are dated above; the scheduled vote dates come from the foundation. NetNapz did not replay consensus, audit the implementation or test a wallet integration. Existing Stellar coverage was checked for duplication. This is reporting and labelled assessment, not investment advice.