News
Follow what has changed.
Reviewed news adds a checked explanation of a development and the stage the evidence supports. Automatic headlines are for discovery and are labelled as not yet reviewed. Publication dates and review dates are shown separately, and older items stay as history.
Reviewed news
745 reviewed developments across 151 chains. Each chain's developments were reviewed on the date shown with it; after 10 days its label reads Review overdue until the next review.
A weekly reviewed news run is planned and not yet running, so many chains will show Review overdue until it starts. The items stay available as history.
Sorted by publication date · newest first; equal dates follow the alphabetical chain order. Page 1 of 15.
One chain's developments, A to Z
-
Ethereum confirmed Sepolia's Glamsterdam fork and scheduled Hoodi
The Ethereum Foundation Protocol Cluster announced on October 16 that, following its October 6 activation on Sepolia, Glamsterdam was scheduled to activate on Hoodi at epoch 132352 on October 26, 2026 at 17:42:48 UTC, matching the Hoodi network configuration merged on October 9. The announcement listed client releases for Hoodi and stated that the mainnet activation date had not been decided. Hoodi had not reached the scheduled epoch when checked.
- Type:Upgrade
- Proposal:Hoodi scheduled mainnet undecided
- Release:Hoodi network configuration merged
- Activation:Sepolia confirmed hoodi scheduled mainnet undecided
Sources: Ethereum Foundation — Glamsterdam Hoodi Testnet Announcement (external site) · ethereum/pm — schedule glamsterdam on hoodi (external site) · eth-clients/hoodi — feat: schedule Hoodi Glamsterdam activation (external site) · Ethereum Improvement Proposals — EIP-7773: Hardfork Meta - Glamsterdam (external site) · Ethereum Foundation — Glamsterdam Testnet Announcement (external site) · Go Ethereum contributors — Go Ethereum v1.17.6 (external site)
-
Hedera upgraded testnet to v0.78.0 and mainnet to v0.78.1
Hedera's status page reported that the testnet upgrade to v0.78.0 completed on October 8 at 17:08 UTC, and that the mainnet upgrade to v0.78.1 started at 17:00 UTC on October 16 and completed successfully at 17:26 UTC. The v0.78 release notes described a CLPR implementation behind a feature flag, a higher maximum number of topics, block node request and buffer changes, and dependency updates for high-severity findings. When opened on October 18 the release notes still listed the v0.78 mainnet date as TBA and did not describe v0.78.1 separately. The sources opened did not state that the CLPR flag was enabled on mainnet.
- Implementation:v0.78 included a flag-gated CLPR implementation
- Release:v0.78 release notes list build 0.78.0; v0.78.1 not described on the page opened
- Activation:testnet v0.78.0 completed 2026-10-08; mainnet v0.78.1 completed 2026-10-16 17:26 UTC per status page
Sources: Hedera Status — Mainnet Upgrade to v0.78.1 (external site) · Hedera Status — Testnet Upgrade to v0.78.0 (external site) · Hedera documentation — Consensus node release notes (external site)
-
stellar-core v30.0.0 released with Protocol 30 support
stellar-core v30.0.0, published on GitHub on 16 October 2026, added support for protocol 30. Its release notes listed as breaking changes CAP-0084 (muxed contract addresses), CAP-0087 (host functions for ML-DSA signature verification) and CAP-0088 (millisecond-resolution close times), enabled in protocol 30, and a move of the protocol 30 Soroban host to rs-soroban-env 30.0.0. The notes said the release raised the minimum overlay version so that nodes older than v29.0.0 could no longer connect, and deprecated account banning now that CAP-0077 was active. The release notes gave no testnet or mainnet upgrade date, and the official software-versions page, opened on 18 October 2026, listed Protocol 29 as its newest entry.
- Proposal:CAP-0087 approved by the CAP Core Team on stellar-dev, last approval 30 Sep 2026; CAP index lists CAP-0084, CAP-0087 and CAP-0088 as Accepted, no dates
- Implementation:implemented in stellar-core v30.0.0
- Release:released 2026-10-16
- Activation:not active; no testnet or mainnet upgrade date stated in the sources opened
Sources: stellar/stellar-core — Release v30.0.0 · stellar/stellar-core (external site) · stellar-dev mailing list (Google Groups) — CAP Core Team vote on CAP-0087 - Host function for ML-DSA signature verification (external site) · stellar/stellar-protocol — Core Advancement Proposals (CAPs) (external site)
-
XDPoSChain scheduled the Prague testnet fork and moved it to block 84,333,000 the same day
The XDPoSChain v3.0.0-testnet release set Prague activation on the testnet at block 87,633,000. Later on 16 October, v3.0.0-testnet-1 moved the activation earlier, to block 84,333,000, and required every testnet masternode and RPC node to run that version before the block; its notes stated that nodes on v3.0.0-testnet or v2.9.x would fork off. The gated rules included set-code transactions, BLS precompiles, a calldata-cost floor and block-history storage. Both builds were explicitly testnet-only; the pages did not state why the block moved, did not establish mainnet activation and did not confirm that the testnet had reached the fork block.
- Proposal:not stated in the sources opened
- Implementation:Prague rules gated at block 84333000 in v3.0.0-testnet-1 (87633000 in v3.0.0-testnet)
- Release:testnet-only prereleases v3.0.0-testnet and v3.0.0-testnet-1 published 2026-10-16
- Activation:testnet scheduled at block 84333000; completion and mainnet activation not established
Sources: XinFinOrg/XDPoSChain — v3.0.0-testnet-1 (external site) · XinFinOrg/XDPoSChain — v3.0.0-testnet (external site)
-
Polygon publicly released Bor v2.10.3 and disclosed denial-of-service fixes
Polygon disclosed two denial-of-service issues in Bor's parallel block execution affecting v2.10.1 and v2.10.2. Bor v2.10.3 bounded shared caches and reused code hashes. Polygon said neither issue was known to have been exploited on mainnet or Amoy. Private builds had been distributed before the stable public release.
- Implementation:fixes included in Bor v2.10.3 and the preceding private builds
- Release:stable public release published 2026-10-15
- Activation:per-node upgrade; no hardfork or activation block
Sources: Polygon Labs / Polygon Community Forum — Bor Security Bug Fix Review (v2.10.3) (external site) · 0xPolygon/bor — v2.10.3 (external site) · Polygon Labs / Polygon Community Forum — Bor v2.10.3 Release Mainnet and Testnet POS (external site)
-
Agave v4.3.2 published with a vendored quinn update for RUSTSEC-2026-0339
Validator-client security patch: the anza-xyz/agave repository published v4.3.2 as a stable release suitable for Testnet, Devnet and Mainnet Beta. Its notes list vendoring quinn for RUSTSEC-2026-0339, an advisory issued October 12, 2026 that describes unbounded memory growth in the quinn-proto QUIC library when a connected peer sends repeated NEW_CONNECTION_ID frames. The linked pull request said it moved the vendored quinn and quinn-proto to newer Anza-maintained forks in response to that advisory. Inference: validators on the v4.3 line receive the change only when they upgrade; adoption is not stated in the sources opened.
- Stage:Released
Sources: anza-xyz/agave — Release v4.3.2 (external site) · anza-xyz/agave — v4.3: vendor quinn for rustsec20260339 (external site) · RustSec Advisory Database — RUSTSEC-2026-0339: Unbounded growth of pending connection ID retirements in quinn-proto (external site)
-
THORChain published v3.21.0 with a proposed upgrade height
THORChain published v3.21.0 with additional security patches and consensus, signing and observation changes. Its notes said the release would use a private binary and proposed block 28,366,100, approximately October 23. They did not establish activation.
- Proposal:proposed upgrade block 28366100
- Implementation:release notes described security and consensus changes
- Release:release entry published 2026-10-15; private binary distribution described
- Activation:proposed approximately October 23, 12:30-15:30 UTC; activation not established
Source: THORChain / THORNode on GitLab — v3.21.0 (external site)
-
Base released v1.5.0 for the scheduled Denim Sepolia upgrade
Base released v1.5.0 and required node operators to upgrade by October 21 at 18:00 UTC for Denim, which was scheduled only on Base Sepolia. The release added Denim support and removed the experimental validity-transaction flag; leaving that flag in a node's startup command would prevent startup. Base's upgrades page listed mainnet Denim as in planning, targeting November 2026, and the release notes said mainnet activation would come in a later release.
- Type:Upgrade
- Proposal:Sepolia scheduled mainnet planning
- Release:required-node-release-v1.5.0
- Activation:Sepolia scheduled mainnet not scheduled
Sources: Base contributors — v1.5.0 (external site) · Base — Denim Overview (external site) · Base — Upgrades (external site)
-
Celestia scheduled Fibre mainnet activation after releasing v10 software
The Celestia Foundation's October 14 server-setup notice placed mainnet Fibre activation in the following week. Celestia-app v10.4.0 had been released for mainnet with Fibre on October 7; its notes said installation alone did not activate v10. An October 8 node notice provided Fibre-compatible client software. The sources opened did not establish mainnet activation.
- Proposal:CIP-51 Implemented in the opened proposal page
- Implementation:Fibre included in app version 10
- Release:celestia-app v10.4.0 released 2026-10-07; compatible node update announced 2026-10-08
- Activation:mainnet activation expected the week after October 14; not established in the sources opened
Sources: Celestia Foundation — Mainnet Beta Fibre server setup (external site) · celestiaorg/celestia-app — v10.4.0 (external site) · Celestia Foundation — Mainnet Beta: celestia-app v10.4.0 upgrade (external site) · Celestia Foundation — Mainnet Beta: celestia-node v0.34.3 upgrade (external site) · Celestia Docs — Network upgrades (external site) · Celestia Improvement Proposals — CIP-051: Fibre Protocol (external site)
-
Cronos scheduled its v1.8 mainnet upgrade for October 22
Cronos Labs scheduled the v1.8 mainnet upgrade for October 22. The announcement described execution, application-side mempool and framework changes. It said libp2p was implemented but not enabled on mainnet. The GitHub release remained labelled prerelease; activation was not confirmed.
- Proposal:mainnet schedule announced by Cronos Labs
- Implementation:execution and mempool changes described; libp2p not enabled on mainnet
- Release:v1.8.0 published 2026-09-24; still labelled prerelease
- Activation:scheduled 2026-10-22; activation not confirmed
Sources: Cronos Labs — Cronos EVM Mainnet v1.8 Upgrade (external site) · crypto-org-chain/cronos maintainers — Cronos v1.8.0 release notes (external site) · crypto-org-chain/cronos maintainers — Cronos releases (external site) · Cronos public REST endpoint — Cronos EVM governance proposals (REST endpoint) (external site)
-
dcrd 2.1.7 fixed denial-of-service weaknesses and added spend safeguards
Decred published dcrd 2.1.7 with fixes for network and mixing denial-of-service attacks, a memory leak, and a testnet synchronization issue. The release added checks that stopped an affected node when it detected certain unexpected transaction spends. The team described those safeguards as a response to the earlier inflation bug.
- Implementation:included in dcrd 2.1.7
- Release:released 2026-10-14
- Activation:per-node behavior on upgrade; adoption not observed
Sources: decred/dcrd — dcrd v2.1.7 (external site) · decred/decred-binaries — v2.1.7 (external site)
-
Kaia announced JPYC eligibility for Contribution Reward Epoch 4
Kaia's Japanese Contribution Reward Mission 1 guide said JPYC deposited through Unifi would become eligible from Epoch 4 at block 230,342,400. It estimated October 21 at 09:40 KST, or 00:40 UTC, for that block. Recognition would not apply retroactively to Epochs 1–3. JPYC would share the existing contribution framework without a separate allocation.
- Implementation:JPYC at Unifi specified as eligible from Epoch 4
- Release:guide published 2026-10-14
- Activation:scheduled from block 230342400; estimated 2026-10-21 00:40 UTC; not yet confirmed
Source: Kaia Marketing Team, Kaia blog (blog.kaia.io) — CR Mission 1 完全ガイド：預け入れ、ステーキング、報酬の獲得 (external site)
-
nearcore 2.14.0-rc.4 set testnet voting for protocol version 88
nearcore 2.14.0-rc.4, a GitHub prerelease marked for testnet, lists a protocol upgrade from version 87 to 88 and states that voting for version 88 starts on 21 October 2026 at 00:00 UTC. Its notes list protocol changes to universal state init deposit refunds and encoding. It follows 2.14.0-rc.2 (17 September) and 2.14.0-rc.3 (28 September), which were not marked as protocol upgrades. A release candidate and a scheduled testnet vote are not a mainnet release or activation.
- Implementation:Release candidate
- Release:Pre release
- Activation:testnet voting scheduled from 2026-10-21; mainnet not asserted
Sources: NEAR nearcore — nearcore Releases (external site) · NEAR nearcore — nearcore 2.14.0-rc.2 (external site)
-
Firedancer published v26.10.2 as a mainnet-ready release
Firedancer marked v26.10.2 as mainnet ready after two testnet-only releases in the 26.10 line. Its notes added support for Solana 4.3 and Alpenglow, with Alpenglow enabled in the default testnet and devnet configurations, and said migration from Tower to Alpenglow would not be supported. The release did not establish mainnet Alpenglow activation.
- Stage:Released
Source: firedancer-io/firedancer — Firedancer Mainnet Release v26.10.2 (external site)
-
Astar completed its Wasm smart-contract sunset
The Astar Foundation reported on October 13 that runtime 2500 had enacted on October 12, removing the Wasm contracts pallet and its storage. Runtime 2400 had blocked contract calls and settled storage deposits on September 19, earlier than the June FAQ described. Runtime 2500 also removed XTokens; direct integrations had to use the replacement XCM call, while the XCM precompile interface remained unchanged. The Foundation said EVM contracts and user-wallet funds were unaffected.
- Proposal:Referendum 64 passed October 10; authorization executed October 12.
- Implementation:Runtime 2400 blocked calls and settled deposits; runtime 2500 removed the contracts pallet and storage.
- Release:Runtime 2500 published September 23; node clients unaffected.
- Activation:Foundation confirmed runtime 2500 enactment on Astar October 12 and sunset completion in its October 13 reply.
Sources: Astar Forum — WASM smart-contract sunset on Astar and Shiden (2026-06-12, updated 2026-08-19) (external site) · Subsquare (Astar democracy) — Referendum 59: Runtime upgrade to 2207 (slot-based Aura migration phase 3; Wasm upload freeze) (external site) · Subsquare (Astar democracy) — Referendum 63: Runtime upgrade to 2400 (WASM smart-contract decommission, step 1 of 2) (external site) · Astar Network (GitHub) — runtime-2400 release notes (external site) · Astar Network — Runtime 2500 release (external site) · Astar governance (SubSquare) — Runtime 2500 Wasm decommission: referendum 64 (external site)
-
Category Labs released Monad node software v0.16.5 with memory-safety fixes
Category Labs published monad-bft v0.16.5, a patch release of the Monad node software. Its notes list hardened RLP decoding of typed transactions and blob hash lists, a fix for list-prefix encoding that wrote past its size, and a triedb range-query fix that closed an over-read of the caller's buffer, among other robustness fixes. The notes do not label these as security fixes and give no advisory, CVE or severity. The release also requires the triedb path setting to name the device itself. Monad's docs listed v0.16.5 for testnet on 15 October 2026 with no mainnet date, and the notes told operators not to upgrade until an official announcement.
- Implementation:fixed in monad-bft v0.16.5
- Release:released 2026-10-13
- Activation:listed for testnet 2026-10-15; the docs table lists mainnet as N/A
Sources: category-labs/monad-bft — Release v0.16.5 · category-labs/monad-bft (external site) · Monad Documentation (Monad Foundation) — Releases (external site)
-
Algorand 5.0.3 corrected DNSSEC bootstrap failures
The Algorand team released 5.0.3 and asked all node operators to upgrade as soon as possible. The release updated a DNSSEC root trust anchor after validation failures prevented newly started or restarted nodes from connecting. The team said already connected nodes continued functioning and the release contained no protocol upgrade.
- Implementation:DNSSEC root trust anchor corrected in 5.0.3
- Release:stable release published 2026-10-12
- Activation:takes effect per node after upgrade; no protocol upgrade was included
Source: algorand/go-algorand — Algorand 5.0.3 (external site)
-
Cosmos Hub governance passed proposal 1058 to return ATOM recovered after the Neutron exploit
Cosmos Hub text proposal 1058 authorised the six signers of the Hub recovery multisig to send the 1,227,121 ATOM moved there at the 23 Sep restart to a Neutron recovery multisig over IBC. It spent no community pool funds and changed no parameters. The Hub team's 8 Oct forum update gave the voting close as 12 Oct at 11:58 UTC, and its 15 Oct update stated that the proposal closed on 12 Oct and passed. On 14 Oct the proposer reported on the proposal's forum thread that the multisig sent 1,227,121.22 ATOM in two IBC transfers and published both transaction hashes. Returning the funds to the affected contracts depended on a separate Neutron governance vote, still open at the cutoff.
- Release:no software release; text proposal
- Activation:not a Cosmos Hub protocol activation; proposal 1058 passed 12 Oct 2026 and the transfer to the Neutron recovery multisig was reported executed 14 Oct 2026
Sources: Cosmos Hub Forum — [DISCUSSION] Move the 1,227,121 ATOM recovered after the Neutron exploit to the Neutron recovery multisig (external site) · Cosmos Hub Forum (forum.cosmos.network), Hub Unit — Hub Weekly Update #20: October 15, 2026 (external site) · Cosmos Hub Forum (forum.cosmos.network) — [DISCUSSION] Move the 1,227,121 ATOM recovered after the Neutron exploit to the Neutron recovery multisig (replies, page 2) (external site) · Cosmos Hub Forum (forum.cosmos.network), Hub Unit — Hub Weekly Update #19: October 8, 2026 (external site)
-
DATA Foundation announced a plan to run the DATA Network as a protocol on Sui and retire its layer 1 chain
The DATA Foundation's documentation described a plan to upgrade the DATA Network to run as a protocol natively on Sui and to retire its independent layer 1 chain once that upgrade is complete. It said $DATA would remain the protocol's token, carried over one-to-one, and that Walrus would become the default storage layer for DATA Foundation apps. It said the existing network would keep running until the upgrade was complete. A detailed timeline and transition plan were to be published before the upgrade; no upgrade date was stated in the sources opened. The announcement linked from the documentation was dated 12 October 2026.
- Proposal:no governance proposal named in the sources opened
- Implementation:planned; no implementation progress stated in the sources opened
- Release:not released
- Activation:not active; the existing network keeps running until the upgrade is complete
Sources: The DATA Foundation documentation (docs.datafdn.org) — DATA on Sui (external site) · Sui Foundation (sui.io blog) — DATA Network joins Sui and Walrus to scale the supply chain for AI training data (external site)
-
dYdX released v9.8 security fixes after the mainnet upgrade applied
The dYdX v9.8.0 release, published 2026-10-12, said it contained security fixes and that the mainnet upgrade had applied at height 109170000, with source published once the upgrade was live. Its listed changes bounded query cost under pagination, tightened signature and transaction validation, capped proposal and short-term transaction sizes, and removed debug output from the mainnet snapshot upload that could leak credentials. Binaries were distributed to validators ahead of the upgrade. The vote result of governance proposal 398 and the block time of the upgrade height were not stated in the sources cited.
- Proposal:forum proposal 2026-10-07; on-chain proposal 398 result not stated in the sources cited
- Implementation:security changes implemented in v9.8.0
- Release:v9.8.0 published 2026-10-12; validator binaries distributed earlier
- Activation:applied on mainnet at height 109170000 before the release was published 2026-10-12 23:31 UTC; block time not stated in the sources cited
Sources: dydxprotocol/v4-chain — Release protocol/v9.8.0 (external site) · dYdX Operations SubDAO, dYdX governance forum — [DRC] Proposal for dYdX Protocol Upgrade to v9.8 (external site)
-
Lotus v1.38.0 added node, gateway and miner hardening
The Lotus team released Node and Miner v1.38.0 with peer-ingress limits, gateway request and subscription limits, revised block-creation permissions, and RPC and sealing corrections. The team recommended this release for Solstice readiness while retaining v1.37.0 as the minimum required version. Mainnet Solstice remained scheduled for October 19.
- Implementation:node, gateway and miner changes included in v1.38.0
- Release:Node and Miner v1.38.0 published 2026-10-12
- Activation:per-node adoption; Solstice remained scheduled for 2026-10-19T12:59:30Z at epoch 6470279
Sources: filecoin-project/lotus — v1.38.0 (external site) · filecoin-project/lotus — miner/v1.38.0 (external site)
-
Taiko upgraded its bridge contracts through Proposals 24 and 25
Taiko's mainnet L1 and L2 contract logs recorded two upgrades of the official bridge, labelled Proposal0024 and Proposal0025; the logs list the bridge's owner as the Taiko DAO controller. Proposal 24 upgraded the Bridge and ERC20Vault contracts on Ethereum and on the Taiko L2 on 8 October 2026 and registered a new bridged ERC20 implementation. Proposal 25 upgraded the Bridge and the ERC20, ERC721 and ERC1155 vaults on both layers on 12 October 2026 and registered new bridged ERC721 and ERC1155 implementations. A merged change to the bridge web interface, released in v2.19.0, stated that the upgrade disables recalls and hid Release and final-retry actions where a bridge reports recalls disabled.
- Proposal:Proposal0024 and Proposal0025 carried out on mainnet per the contract logs; vote records not stated in the sources opened
- Implementation:new Bridge and vault implementations deployed on mainnet L1 and L2
- Release:bridge web interface v2.19.0 released 2026-10-08
- Activation:upgraded on mainnet L1 and L2 on 2026-10-08 (Proposal 24) and 2026-10-12 (Proposal 25)
Sources: taikoxyz/taiko-mono — mainnet-contract-logs-L1.md (external site) · taikoxyz/taiko-mono — mainnet-contract-logs-L2.md (external site) · taikoxyz/taiko-mono — feat(bridge-ui): gate recalls across bridge upgrades (external site) · taikoxyz/taiko-mono — bridge-ui: v2.19.0 (external site)
-
Secret Network released v1.27.3 for a scheduled mainnet upgrade
Secret Network released v1.27.3 for a coordinated mainnet upgrade scheduled for October 13 at 13:00 UTC. The linked operator guide named height 27595508 and proposal 381. It described module migrations with no store additions or removals; only the host binary changed, while the signed enclave remained unchanged. The sources opened did not establish completed activation.
- Proposal:proposal 381 named; result not stated in these sources
- Implementation:host-binary changes and module migrations prepared
- Release:v1.27.3 released 2026-10-10
- Activation:scheduled for 2026-10-13 at 13:00 UTC, height 27595508; completion not established
Sources: Secret3dev/SecretNetwork — v1.27.3 (external site) · Secret Network operator documentation — v1.27.3 (external site)
-
Final mainnet slot-time reduction step to 200ms reported activated
Network-parameter update: the Solana Foundation upgrades page reported that the last of four staged slot-time reductions took effect on mainnet at the start of epoch 1053 on October 9, 2026, at approximately 14:35 UTC, lowering the target slot time from 250ms to 200ms. The Solana Changelog of October 8 said the feature gate was active and that shorter slot times go live one epoch after activation. Observed slot times after the change are not stated in the sources opened.
- Stage:Activated
Sources: Solana Foundation — Reduced Slot Times (external site) · Solana Foundation — Solana Changelog: October 8, 2026 (external site)
-
Taiko released Alethia client v2.8.0 with L1 header compatibility changes
Taiko published Alethia client v2.8.0 with support for preserving L1 header hashes under Ethereum's Glamsterdam upgrade and a change to the proof flow. Its note said operators must upgrade before Glamsterdam activates on their L1, gave a proposed Hoodi time of 26 October 2026 that was not final, and said mainnet was not scheduled. The release also implemented Proposal0026, which raises inbox basefee sharing to 100% and rotates raiko2 to v0.9.0; execution of that proposal was not stated in the sources opened.
- Proposal:Proposal0026 named in the release notes; execution not stated in the sources opened
- Implementation:implemented in Alethia client v2.8.0
- Release:released 2026-10-09
- Activation:L1 Hoodi date provisional; mainnet not scheduled in release note
Source: taikoxyz/taiko-mono — taiko-alethia-client: v2.8.0 (external site)
-
Unichain scheduled its move to OP Enterprise
Uniswap Labs announced that Unichain would move to OP Enterprise, with testnet migration scheduled for October 13 and mainnet migration for October 29. Optimism would operate sequencers, RPC, monitoring and incident response. The announcement did not confirm completed cutover, and described native interoperability as conditional on a future activation.
- Proposal:OP governance maintenance proposal for the mainnet proposer and fee-recipient changes posted 2026-10-16 under optimistic approval; result not stated in the sources opened
- Implementation:planned infrastructure transition
- Release:not stated in the sources opened
- Activation:testnet scheduled October 13; mainnet scheduled October 29; completion not confirmed
Sources: Uniswap Labs — Unichain is Upgrading to OP Enterprise (external site) · Optimism Collective governance forum — Maintenance Upgrade Proposal: Unichain Mainnet Proposer Rotation and L1 Cost Fee Routing (external site)
-
Matter Labs resubmitted ZKsync's delayed v31 upgrade as ZIP-18
Matter Labs resubmitted v31 with regenerated calldata as ZIP-18. The post said ZIP-16 had been approved in July but its upgrade calldata was never executed. It targeted Era protocol v0.33.0, tentatively in the week of October 26, subject to a successful governance vote.
- Proposal:resubmitted as ZIP-18; vote pending in the sources opened
- Implementation:regenerated calldata described; referenced contracts deployed
- Release:required compatible node version named; stable publication not established here
- Activation:tentative week of 2026-10-26, subject to vote; not activated in the sources opened
Sources: Matter Labs on ZK Nation Forum — [ZIP-18] Resubmission of the ZKsync v31 Upgrade (external site) · ZK Nation Forum — [ZIP-16] ZKsync v31 Upgrade (external site)
-
Aztec v5.2.1 fixed two flaws in the Barretenberg native proof verifier for direct users
AztecProtocol published aztec-packages v5.2.1 on 8 October 2026 as a patch release with a security fix for direct Barretenberg users. Two advisories published the same day concern the native UltraHonk verifier's handling of a recursive pairing accumulator with one point at infinity: the first, rated high, let the verifier accept some proofs of recursive circuits whose inner proofs were invalid; the second, rated moderate, made it throw or abort instead of returning a verification failure. Affected tools are the bb CLI, @aztec/bb.js and barretenberg-rs. The release notes say the release does not affect the Aztec network and that node operators, sequencers, provers, contract developers and wallet users do not need to upgrade.
- Implementation:fixed in aztec-packages v5.2.1 (pull request #25616)
- Release:released 2026-10-08
- Activation:no network activation; applies to direct Barretenberg users when they upgrade
Sources: AztecProtocol/aztec-packages — Release v5.2.1 · AztecProtocol/aztec-packages (external site) · AztecProtocol/aztec-packages security advisory — UltraHonk native verifier accepts proofs whose recursive pairing accumulator has one point at infinity (external site) · AztecProtocol/aztec-packages security advisory — UltraHonk native verifier throws or aborts on a recursive pairing accumulator with a point at infinity (external site)
-
Geth v1.17.8 fixed denial-of-service risks
The Geth team published v1.17.8 as a security-focused client upgrade and recommended it for all users. The notes described peer-protocol protections, a STUN-response crash fix and defenses for issues that become possible after the Amsterdam fork. The release did not establish a network activation.
- Type:Upgrade
- Proposal:Not applicable
- Release:Client release published
- Activation:Not established by release
Source: ethereum/go-ethereum — Protein Sludge Pack (v1.17.8) (external site)
-
Parity reported a working parachain-service prototype for JAM
Parity's October update reported that the first parachain-service proof of concept worked on JAM and that work had begun to turn it into production code. PolkaJAM implemented Gray Paper 0.8, with 0.8.1 work underway. The update also described a browser light-client prototype and local Zombienet integration. It did not confirm a mainnet migration or set an activation date.
- Proposal:Roadmap remained in development.
- Implementation:Parachain-service proof of concept worked; production work began; PolkaJAM implemented Gray Paper 0.8, with 0.8.1 work underway.
- Release:No release stated in the sources opened.
- Activation:No JAM mainnet migration or activation date established.
Sources: Parity Technologies / Polkadot Forum — The road to JAM — October update (external site) · Parity Technologies (Polkadot Forum) — The Road to JAM (external site) · Polkadot Forum — Polkadot Technical Fellowship OpenDev Call proceedings, 15 September 2026 (external site) · Polkadot Wiki — JAM Chain (external site)
-
Sei migrated testnet EVM state to FlatKV and asked node operators to update before the mainnet migration
The sei-chain v6.7.1 release, published 8 October 2026, reported that the migration of EVM state from memIAVL to FlatKV ran on the atlantic-2 testnet from 1 to 2 October 2026. It said the pacific-1 mainnet migration would start around 17:00 UTC on 9 October 2026 when the migration proposal passed, and asked mainnet validators and node operators to update to v6.7.1 first. v6.7.1 was a non-mandatory patch on v6.7.0 with fixes for the migration, state sync and rollback. The result of the mainnet migration proposal and the start or completion of the mainnet migration were not stated in the sources opened.
- Proposal:mainnet migration proposal pending when v6.7.1 was published; result not stated in the sources opened
- Implementation:migration code in v6.7.0; migration, state-sync and rollback fixes in v6.7.1
- Release:v6.7.1 released 2026-10-08 as a non-mandatory patch
- Activation:testnet (atlantic-2) migration ran 1 to 2 October 2026; mainnet start targeted about 17:00 UTC on 9 October 2026, not established
Sources: sei-protocol/sei-chain — v6.7.1 (external site) · Sei Blog — The Eidos Upgrade: replacing Sei's storage database while the chain is running (external site) · Sei documentation (docs.sei.io) — Sei Blockchain Network Chains Overview (external site)
-
Aleo published snarkOS v4.12.0 after its testnet announcement
The snarkOS maintainers announced the v4.12.0 testnet schedule on October 7 and published stable v4.12.0 on October 13. Testnet V22 was scheduled at height 20,415,000. The stable release updated snarkVM; neither notice established actual activation.
- Implementation:V22 testnet support shipped
- Release:testnet-v4.12.0 published October 7; stable v4.12.0 published October 13
- Activation:testnet V22 scheduled at height 20,415,000; testnet and mainnet activation not stated in the sources opened
Sources: aleo-labs-protocol/snarkOS — testnet-v4.12.0 (external site) · aleo-labs-protocol/snarkOS — v4.12.0 (external site) · ProvableHQ/snarkOS maintainers — ProvableHQ/snarkOS releases (external site)
-
Cardano Foundation announced CIP-0113 programmable tokens on mainnet
The Cardano Foundation announced that the CIP-0113 programmable token standard was live on Cardano mainnet. It stated that issuers select modular rule sets, or write their own, that are enforced when tokens are transferred, minted or burned, and that the standard followed joint development with community experts and multiple independent security audits; a quoted partner referred to the Foundation's Aiken implementation. The Foundation stated that no hard fork was required.
- Proposal:CIP-0113 listed as Proposed, not Active, on the Cardano CIP site (updated 2026-09-29)
- Implementation:Foundation cited modular rule sets, an Aiken implementation and completed independent security audits
- Release:mainnet availability announced 2026-10-07
- Activation:Foundation reported live on Cardano mainnet on 2026-10-07; no hard fork required
Sources: Cardano Foundation — Cardano Foundation launches programmable token standard, bringing ledger-enforced compliance to tokenized assets (external site) · Cardano Improvement Proposals (cips.cardano.org) — CIP-0113: Programmable token-like assets (external site)
-
IOTA node release v1.33.1 for Mainnet introduced protocol version 37
The iotaledger/iota repository published release v1.33.1 for Mainnet on 7 October 2026, the first stable Mainnet release of the 1.33 line after v1.32.1. It introduced protocol version 37, which the release notes said could be enabled on mainnet no earlier than 2026-10-08 07:42 UTC (start of epoch 521), and asked validators to update before that epoch change. The notes said version 37 enables validation of input object versions, so transactions naming versions in the range reserved for cancelled transactions are rejected. The notes also listed Move verification changes, a TLS requirement for validator gRPC, new request and connection limits, and a fix for rate-limit bypass through malformed forwarding headers. Whether protocol version 37 was activated is not stated in the sources opened.
- Implementation:implemented in node release v1.33.1
- Release:released for Mainnet 2026-10-07
- Activation:can be enabled on mainnet no earlier than 2026-10-08 07:42 UTC (epoch 521); activation not stated in the sources opened
Sources: iotaledger/iota — Release [Mainnet] v1.33.1 (external site) · iotaledger/iota repository — iotaledger/iota releases (external site)
-
Linea's Security Council replaced a verifier to address proof-generation failures
Linea's Security Council recorded L1 nonce 80, replacing an unused verifier at index 1 to correct issues that prevented proof generation in some cases. Its record identified the verifier-change event.
- Implementation:verifier replacement recorded
- Release:not stated in the sources opened
- Activation:L1 action recorded 2026-10-07
Source: Linea Documentation — Linea Security Council transaction record (external site)
-
OP Labs released op-reth v2.6.0 with engine configuration changes
OP Labs recommended op-reth v2.6.0 for operators. It updated its upstream reth base to v2.5.2, removed two engine flags, changed persistence defaults and corrected transaction-pool handling of data and operator fees. The release warned that removed startup flags would prevent node startup.
- Type:Release
- Proposal:Not applicable
- Release:Released recommended
- Activation:Client release not protocol activation
-
Polkadot approved and executed the dotUSD setup
Polkadot OpenGov confirmed referendum 1944 on October 7 and recorded successful execution on October 8. The calls configured the protocol-owned dotUSD asset, its sufficiency flag, peg-stability parameters and an initial pool. The governance execution did not establish public frontend availability or a wider product launch.
- Proposal:Confirmed 2026-10-07.
- Implementation:Asset and peg-stability configuration included in referendum 1944.
- Release:No separate software release stated.
- Activation:Executed successfully 2026-10-08; public frontend availability not established.
-
Sonic v2.2.5 restricted custom JavaScript RPC tracers by default
Sonic released v2.2.5 with debug tracing restricted to built-in tracers by default. Custom JavaScript tracers required an explicit operator option. The release warned that enabling custom scripts was unsafe on publicly exposed nodes and recommended the release to RPC operators.
- Implementation:default restriction and operator opt-in included in v2.2.5
- Release:stable release published 2026-10-07
- Activation:per-node upgrade; network activation not stated in the sources opened
-
SV Node 1.2.3 fixed memory-access errors
The SV Node team released 1.2.3. Its notes listed two memory-safety fixes: one for invalid memory access in CScript and one for a use-after-free in mempool eviction tracking. The release also changed database and socket handling and added a wallet rescan RPC. The notes did not identify a CVE, exploit or severity for the memory errors.
- Implementation:fixes included in SV Node 1.2.3
- Release:released 2026-10-06
- Activation:per-node software change; network adoption not observed
Source: bitcoin-sv/bitcoin-sv — Bitcoin SV Version 1.2.3 Release Notes (external site)
-
Chiliz scheduled two Spicy testnet forks for October 8
Chiliz's v2.10.9-rc1 notes required Spicy testnet operators to upgrade for DeployerProxySunset at 08:00 UTC and Snake8Fix at 10:00 UTC on October 8. The notes said the first would turn off the DeployerProxy deployment and invocation hooks and the second would make validator-frequency data in block headers consensus-verified. The notes explicitly scheduled neither fork on mainnet. The opened sources did not confirm that either testnet activation completed.
- Proposal:not stated in the sources opened
- Implementation:included in v2.10.9-rc1
- Release:v2.10.9-rc1 published 2026-10-06
- Activation:Spicy scheduled 2026-10-08 at 08:00 and 10:00 UTC; completion unconfirmed; neither scheduled on mainnet
-
Solstice scheduled for mainnet on 19 October 2026
The existing Solstice development has advanced from release candidate to Lotus v1.37.0 stable, released on 6 October. It schedules network version 29 for mainnet epoch 6470279 on 19 October 2026. FIP-0118 would retire Filecoin Plus, assign maximum power to new sectors and split issuance into consensus, service and burn streams. Mainnet activation remains future.
- Proposal:FIP-0118 Accepted
- Implementation:implemented in Lotus v1.37.0 with built-in actors v19.0.1
- Release:stable release published 2026-10-06
- Activation:mainnet scheduled for epoch 6470279, 2026-10-19T12:59:30Z; not yet activated as of 2026-10-10
Sources: filecoin-project/lotus — Lotus v1.37.0-rc1 (network version 29, Solstice) (external site) · Filecoin Improvement Proposals — FIP-0118: (Solstice) Deprecate Fil+ and Fund Services via Block-Reward Split (external site) · Filecoin (filecoin.io) — Solstice: Towards a Filecoin Service Economy (external site) · filecoin-project/lotus — Lotus v1.37.0 stable (Solstice) (external site)
-
Monero released v0.18.5.3 with node and wallet hardening fixes
The Monero Project released CLI and GUI v0.18.5.3. The CLI notice described protections against malicious remote nodes, restricted RPC privacy corrections, multisig nonce handling and log-injection fixes. The GUI notice described connection-scoped daemon credentials, proxy fixes and stopping wallet saves when password setup failed. The release notices did not announce a network activation.
- Stage:Stable release
- Activation:Not claimed
Sources: The Monero Project — Monero 0.18.5.3 'Fluorine Fermi' released (external site) · The Monero Project — Monero GUI 0.18.5.3 'Fluorine Fermi' released (external site) · monero-project/monero — Fluorine Fermi, Point Release 5.3 (external site)
-
SKALE reported IMA Bridge incident findings and validator security changes
SKALE reported that the IMA Bridge infrastructure for SKALE on Ethereum was exploited on 27 August and that ERC-20 assets held in it were taken; it said SKALE on Base was not affected. It attributed the incident to externally reachable internal validator node services and insufficient network isolation. It also reported unauthorized transfers from some validator node wallets and a new skale-node version with security changes rolled out across validators. The affected bridge remained paused while investigation, remediation and review continued. Loss figures and recovery results were not stated in the sources opened.
- Implementation:validator network-isolation measures and a node security update reported
- Release:node update rolled out; version not stated in the sources opened
- Activation:affected IMA Bridge functionality remained paused
Source: SKALE — Security Incident Update: SKALE IMA Bridge Update (external site)
-
Zcash Foundation reported NU7 active on Testnet, with no Mainnet height set
A September 17 forum timeline listed NU7 code completion for September 30, a Testnet upgrade on October 6 at height 4,465,026, a final Mainnet decision on October 20 and Mainnet activation on November 5, 2026. The Zcash Foundation published Zebra 7.0.0-rc.0 on October 2 as a release candidate supporting NU7 on Testnet only; its notes said Mainnet node operators were not required to upgrade. The Foundation's engineering update of October 6 reported that NU7 activated on public Testnet at block 4,465,026 on 4 October, said no Mainnet activation height had been set, and gave a tentative Mainnet date of 5 November. The planned changes included 25-second block spacing (ZIP 218), disabling version 4 transactions (ZIP 2003) and Network Sustainability Mechanism changes (ZIPs 234 and 235); the ZIP index listed these and the deployment ZIP 259 as Draft.
- Stage:Proposal
Sources: Zcash Foundation — ZF Engineering Update: 21 September - 5 October 2026 (external site) · Zcash Community Forum — NU7 Timeline (external site) · Zcash ZIP editors — Zcash Improvement Proposals (external site) · Zcash ZIP editors — ZIP 218: 25-second Block Target Spacing (external site) · Zcash Foundation — Zebra 7.0.0-rc.0 release (external site) · Zcash Foundation — Zebra 7.0.0-rc.0: NU7 Arrives on Testnet (external site)
-
Teranode released stable v0.16.0
The Teranode team published stable minor release v0.16.0. Its notes described upgrading from v0.15.x while retaining persisted node state, changes to service authentication and transport configuration, and removed settings. The source listed security and validation fixes in its changes.
- Implementation:implemented in Teranode v0.16.0
- Release:stable release published 2026-10-05
- Activation:network deployment not stated in the sources opened
-
Canton 3.6.1 and Splice 0.9.0 were released with support for protocol version 36
Canton 3.6.1 was published in the digital-asset/canton GitHub repository on 5 October 2026 as a minor release of the Canton node software, and the Splice 0.9.0 release notes added to the official documentation the same day say Splice 0.9.0 upgrades to it. The Canton notes listed support for protocol versions 34, 35 and 36, a redesigned ACS commitment pipeline, Daml external calls and the rejection of TLS 1.0 and 1.1 by public API servers; external calls, synchronizer limits and zstd compression take effect only on protocol version 36. The Splice notes say adopting protocol version 36 requires a Logical Synchronizer Upgrade, and list removed endpoints including the scan v0 and v1 ACS and holdings endpoints. Splice patches 0.9.1 and 0.9.2 followed on 9 and 15 October. A network adoption date is not stated in the sources opened.
- Implementation:implemented in Canton 3.6.1 and Splice 0.9.0
- Release:Canton 3.6.1 and Splice 0.9.0 released 2026-10-05; Splice patches 0.9.1 (2026-10-09) and 0.9.2 (2026-10-15)
- Activation:protocol version 36 needs a Logical Synchronizer Upgrade; network adoption not stated in the sources opened
Sources: digital-asset/canton (GitHub) — Release canton v3.6.1 (external site) · Canton Network documentation (docs.canton.network) — Canton 3.6.1 release notes (external site) · Canton Network Docs — Splice release notes (external site) · canton-network/cf-docs (GitHub API) — Commit history of docs-main/global-synchronizer/release-notes/splice.mdx (canton-network/cf-docs) (external site)
-
CantonBFT MainNet adoption scheduled for October 10; completion unverified
After the September delay, the Foundation's October 5 notice scheduled MainNet CantonBFT adoption for Saturday October 10 at 9 a.m. US Eastern, following a 24-hour topology freeze. Normal Daml transactions were expected to continue during the freeze, with a short pause at the switch. The review found this schedule but no completion notice.
- Proposal:scheduled by the October 5 notice after the September delay
- Implementation:CantonBFT in Canton 3.5; Splice 0.8.0 prepared the ordering layer for the switch
- Release:live on DevNet since 29 July 2026
- Activation:MainNet scheduled for 2026-10-10 13:00 UTC; successful completion not independently verified
Sources: Canton Network Forum (Announcements) — Logical Synchronizer Upgrade (LSU) Updates (external site) · Canton Network Forum (Announcements) — Canton 3.4 to canton 3.5 transition (external site) · Canton Network Docs — Splice release notes (external site) · Splice (GitHub) — Splice 0.8.0 release (external site) · Canton Network Forum — Topology Freeze Friday 9 am US Eastern (external site)
-
Ankr confirms Harmony's September halt and retires RPC support
Ankr's 5 October notice confirms Harmony stopped producing blocks on 10 September 2026 and retires its Harmony endpoint. The migration repository separately sets its accounting cutoff at 14:00 UTC on 10 September. It prepares replacement ONE on Ethereum, with active stake assigned to validator vaults and distinct eligibility routes for ordinary wallets and exchanges. Distribution was not verified.
- Proposal:migration policies documented; binding governance record not verified
- Implementation:snapshot taken; accounting toolkit published
- Release:replacement token source published; deployment not verified
- Activation:chain halted since 2026-09-10; distribution not verified
Sources: Ankr — Harmony reaches end of support (5 October 2026) (external site) · harmony-migration repository (polymorpher) — Harmony migration accounting (external site) · harmony-migration repository (polymorpher) — Harmony migration user FAQ (external site) · Harmony (GitHub) — HarmonyONEToken.sol (external site)
-
Robinhood Chain Testnet required Nitro v3.11.4 before Sepolia's Glamsterdam upgrade
Robinhood Chain's status page posted a testnet notice on October 5, 2026. It said Ethereum's Glamsterdam upgrade was set to activate on Sepolia on October 6 at 13:53:36 UTC, and that operators of any Robinhood Chain Testnet nodes, including RPC and indexer nodes, needed to be on Nitro v3.11.4 before then. Nodes on older versions would not be able to follow the parent chain after activation. The notice said no ArbOS upgrade was required and no impact on the chain was expected. Robinhood's Notices & Upgrades table had listed Nitro v3.11.4 on September 14 as a recommended release with no chain consensus changes. The sources opened did not say whether operators upgraded or confirm the Sepolia activation.
- Type:Operations
- Proposal:Not applicable
- Release:Nitro v3 11 4 required for testnet operators
- Activation:Parent testnet upgrade scheduled 2026 10 06 no arbos upgrade
Sources: Robinhood Chain status page (hosted at offchain.io) — Robinhood Chain - Status (external site) · Robinhood — Notices & Upgrades (external site)
-
SKALE published skaled 5.3.0 as a stable release
The skalenetwork/skaled repository published version 5.3.0 of skaled, the SKALE chain node client, as its latest stable release on 5 October 2026, after a series of 5.3.0 beta and development prereleases. The release page carried no release notes, so its changes, any security content and whether operators must upgrade were not stated in the sources opened. Deployment to SKALE chains was also not stated in the sources opened.
- Implementation:changes not stated in the sources opened
- Release:stable release published 2026-10-05
- Activation:deployment to SKALE chains not stated in the sources opened
Sources: skalenetwork/skaled — Release 5.3.0 · skalenetwork/skaled (external site) · SKALE (GitHub) — skaled releases (external site)