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
707 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 2 of 14.
One chain's developments, A to Z
-
Aptos node v1.49.1 released for mainnet, first as a private hotfix
Aptos Labs published a mainnet node release, v1.49.1-hotfix, as binaries and a Docker image only, stating that the source code was not available. Validators were told to upgrade and fullnode operators were advised to. On 23 September the same build was published as open-source v1.49.1, with a change log covering everything since v1.48.6. The log lists a gas schedule version bump to 49, Block-STM v2 turned on by default, and the API returning HTTP 410 for reads of pruned transactions and events.
- Implementation:node software v1.49.1; binaries published 2026-09-17, source and change log 2026-09-23
- Release:released as [Mainnet] node releases on GitHub (v1.49.1-hotfix, then v1.49.1)
- Activation:each operator upgrades separately; no v1.49 framework upgrade proposal was listed on the governance site on 2026-09-27
Sources: Aptos Labs (aptos-core GitHub releases) — [Mainnet] Aptos Node Release v1.49.1-hotfix (external site) · Aptos Labs (aptos-core GitHub releases) — [Mainnet] Aptos Node Release v1.49.1 (external site) · Aptos Labs — aptos-core releases (external site) · Aptos Governance (Aptos Foundation) — Multi-step proposal to upgrade mainnet framework, version v1.48.0 (external site) · Aptos Foundation — Aptos Governance proposals (external site) · Aptos Docs — Governance (external site)
-
Aurora Engine 3.11.0 released with Osaka execution rules
Engine 3.11.0 switches execution and gas validation to Ethereum's Osaka rules, improves EIP-7702 authorization handling and fixes several gas-accounting and precompile bugs. On 2026-09-27 the mainnet engine still reported 3.10.1, so this release was published but not yet active there.
- Implementation:Released
- Release:published 2026-09-17
- Activation:not active on mainnet as of 2026-09-27
Source: Aurora Labs — Aurora Engine Release 3.11.0 (external site)
-
B² rollup nodes switch from data snapshots to importing published block files
B² changed its rollup node guide so new nodes load history by importing block files that B² publishes in ranges of about 500,000 blocks, instead of downloading a full snapshot of another node's data directory. Archive-node instructions were merged into the same guide.
- Implementation:Documented
- Release:guide updated
- Activation:applies to new node setups
Sources: B² Network (GitHub) — Replace snapshot downloads with geth import for rollup nodes (external site) · B² Network Documentation — Deploy a rollup node (external site)
-
cardano-node 11.1.2 released
cardano-node 11.1.2 was published as a stable release that optimizes memory use in time-lock scripts; Intersect asked stake-pool operators to prioritize it because it superseded 11.1.1 after an issue found in testing.
- Implementation:released source and artifacts
- Release:stable release; supersedes 11.1.1
- Activation:operator adoption varies; not a hard-fork activation
Sources: IntersectMBO — cardano-node 11.1.2 (external site) · Intersect — Intersect weekly update #129 Sep 19, 2026 (external site)
-
IOG announced Plutus stewardship transition to Midgard Labs
Input Output announced that the Plutus team and management responsibility would move from IO Labs to Midgard Labs effective October 1, with both organizations collaborating during the transition.
- Implementation:transition coordination announced
- Release:organizational announcement published
- Activation:scheduled stewardship transition on 2026-10-01; not yet effective at review
Source: Input Output — Plutus moves to Midgard Labs (external site)
-
Governance cut the active validator set to 21
Proposal 396 lowered the maximum number of active validators from 31 to 21. The forum post behind it said only 29 of 31 slots were filled (a later passage says 30) and the ten validators ranked 22 to 31 held about 5.4% of active stake. Block proposing stays with the eight designated proposers.
- Proposal:passed 17 September 2026
- Implementation:parameter change executed on-chain
- Release:no software release required
- Activation:maximum of 21 validators observed on 27 September 2026
Sources: Allnodes public REST endpoint for dydx-mainnet-1 — Governance proposal 396: Reduce the active validator set to 21 (external site) · dYdX Forum — [DRC] Reduce Active Set to 21 (external site) · Allnodes public REST endpoint for dydx-mainnet-1 — dYdX Chain staking parameters (on-chain query) (external site)
-
nearcore 2.14.0-rc.2 published for testing
The direct nearcore tag identifies 2.14.0-rc.2 as a prerelease with no protocol upgrade. A release candidate is testing evidence, not proof that mainnet validators adopted it.
- Implementation:Release candidate
- Release:Pre release
- Activation:Not asserted
Source: NEAR nearcore — nearcore 2.14.0-rc.2 (external site)
-
CKB node v0.210.0 released with no consensus change; node releases since v0.208.0 use a new signing key
Version 0.210.0 of the CKB full node was published on 17 September 2026. Its release note calls it a regular minor release: it lists no new features, keeps mainnet on the ckb2023 rules active since epoch 12,293 with v0.200.0 as the oldest compatible version, updates the default assumed-valid blocks for mainnet and testnet, and says CentOS binaries will stop being provided at a later date. The substantive changes an operator picks up when upgrading from v0.207.0 or older came in two July releases: v0.208.0 (15 July) added the block hash to live-cell RPC responses and switched to a new release signing key, and v0.209.0 (29 July) replaced the Tor library with the node's own implementation, stopped unbounded memory growth in logging and relay queues, and added bearer-token authentication for the miner notify mode.
- Implementation:Released
- Release:v0.210.0 published 2026-09-17; preceded by v0.208.0 (2026-07-15) and v0.209.0 (2026-07-29)
- Activation:not a consensus change; takes effect for each operator on install
Sources: Nervos Network (nervosnetwork/ckb) — CKB v0.210.0 (external site) · Nervos Network (nervosnetwork/ckb) — CKB v0.209.0 (external site) · Nervos Network (nervosnetwork/ckb) — CKB v0.208.0 (external site) · Nervos Network (nervosnetwork/ckb) — CKB release integrity check (external site) · Nervos Network (nervosnetwork/ckb) — CKB releases (external site)
-
Foundation report: engine flaw exploited on 31 August 2026 and ledger halted by validators
The Radix Foundation's incident report says an attacker used a Radix Engine flaw, introduced in a June 2023 code tidy-up and missed by a 2024 audit, to withdraw Hyperlane-bridged ETH, WBTC, USDT, USDC, BNB and SOL from vaults it did not own, including liquidity pools, and moved them off Radix. Hyperlane removed Radix from its validator and relayer operations and was asked to shut the remaining routes, and within about three hours of the first report validators took enough stake offline to stop all commits. The fix was reviewed by audit firms, and the report, version 1.4, described restoration as in progress.
- Implementation:engine fix written and independently reviewed
- Release:incident report published (version 1.4)
- Activation:commits halted from 31 August 2026; they resumed on 11 September 2026 with the Eagle Ray update
Sources: Radix Foundation (Radix Blog) — Public Incident Report: Vault-Authorisation Vulnerability and Loss of Network Liveness (external site) · Radix DLT (babylon-node repository, GitHub) — mainnet_protocol_config.rs at v1.4.0.0 (external site) · Radix Foundation Gateway — Radix mainnet Gateway transaction stream from epoch 339,898 (read 2026-09-29) (external site)
-
Robinhood Chain websocket feeds changed to compressed-only transmission
Robinhood's notices table says the Mainnet and Testnet websocket feeds moved to RFC 7692 per-message compression on September 17. Nitro node and relay operators were unaffected; custom direct-feed scripts had to add compression support or read uncompressed JSON from a Nitro relay.
- Type:Operations
- Proposal:Not applicable
- Release:Feed configuration change effective
- Activation:Activated mainnet and testnet
-
Community engineering timeline targets NU7 for November
A September 17 community engineering update reported planned NU7 testnet activation on October 6 and mainnet activation on November 5, 2026, with 25-second target spacing among the planned changes.
- Stage:Proposal
Sources: Zcash Community Forum — NU7 Timeline (external site) · Zcash ZIP editors — Zcash Improvement Proposals (external site)
-
USDCx on Aleo began accepting deposits from Arc
Aleo announced that its USDCx bridge was integrated at the launch of Arc mainnet, so USDC deposited on Arc through Circle xReserve can mint USDCx on Aleo. Ethereum remains supported, and the bridge docs list Ethereum and Arc as the only burn destinations.
- Implementation:integration described as live at Arc mainnet launch
- Release:announced 2026-09-16
- Activation:Circle's xReserve page lists Arc as a mainnet source chain; deposit volumes not observed
Sources: Aleo — Arc mainnet is live: USDCx on Aleo supports xReserve on Arc deposits from day one (external site) · Circle — xReserve supported blockchains and domains (external site) · Aleo documentation — Aleo USDCx Bridge: Integrator Manual (V2) (external site)
-
Nitro v3.11.4 was released
Offchain Labs published Nitro v3.11.4 on GitHub on September 16 (its release notes carry a September 9 version date) with bounded proof and fee-history request behavior plus fixes. A node-software release does not itself prove deployment or activation on Arbitrum One.
- Type:Release
- Proposal:Not applicable
- Release:Released
- Activation:Not established by release
Source: Offchain Labs — Arbitrum Nitro v3.11.4 (external site)
-
Governance moved the Cabal rollup's bridge to IBC, continuing a 2026 series
Proposal 92 passed on 2026-09-16 and registered migration information that routes Cabal's bridge (bridge 42) over IBC channel-97, ending its 1-day withdrawal wait. Earlier proposals did the same for Civitia and Echelon (January 2026) and Inertia (May 2026). Users keep the same bridged tokens, but withdrawals now rely on IBC checks of the rollup's single operator.
- Proposal:passed (proposal 92)
- Implementation:migration information registered on chain
- Release:no software release needed
- Activation:passed; IBC client for the channel observed 2026-09-27
Sources: Initia L1 governance (on-chain record) — Proposal 92: Migrate Cabal OPbridge to IBC (external site) · Initia L1 governance (on-chain record) — Proposal 67: Migrate Civitia OPbridge to IBC (external site) · Initia L1 governance (on-chain record) — Proposal 68: Migrate Echelon OPbridge to IBC (external site) · Initia L1 governance (on-chain record) — Proposal 81: Migrate Inertia OPbridge to IBC (external site) · Initia Labs public REST endpoint — IBC client state for transfer channel-97 (Cabal) (external site) · Initia Labs public RPC endpoint (cabal-1) — Cabal rollup validator set (external site)
-
Protocol 28 (Adapter) activated on Mainnet with earlier consensus voting and shared contract code
Protocol 28 took effect on Mainnet on 16 September 2026 at the scheduled 17:00 UTC vote; the foundation had announced it on 13 August 2026, the day stellar-core v28.0.0 was released. It lets validators begin voting before a full transaction set arrives and vote to drop a late or invalid set, lets many contracts point at one shared, upgradable piece of code, and makes contract data easier to migrate.
- Proposal:CAP-83, CAP-85 and CAP-86 listed for Protocol 28
- Implementation:stellar-core v28.0.0 released 2026-08-13
- Release:stable releases scheduled from 13 to 21 August 2026
- Activation:active on Mainnet from ledger 64458446, closed 2026-09-16T17:00:06Z; parallel transaction-set downloading is to be enabled gradually afterwards
Sources: Stellar Development Foundation — Introducing Adapter, Protocol 28 on Stellar (external site) · Stellar Development Foundation — Adapter, Protocol 28 Upgrade Guide (external site) · Stellar Development Foundation (GitHub) — stellar-core v28.0.0 (external site) · Stellar Development Foundation (Horizon API) — Horizon ledger record 64458446 (external site) · Stellar Protocol (GitHub) — CAP-0083: Allow validators to vote to drop the transaction set from the current ledger (external site) · Stellar Docs (Stellar Development Foundation) — Software Versions (external site)
-
xrpld 3.4.0 released with two new amendments that are not yet active
Version 3.4.0 of the reference server added two amendments. LendingProtocolV1_1 extends the Lending Protocol and Single Asset Vault features with closed-ended vaults and interest counted only when payments arrive. fixCleanup3_4_0 bundles fixes for trust lines, the permissioned DEX, AMM clawback rounding, Multi-Purpose Token checks, NFT offers and escrow reserves. The release also retired fixAMMOverflowOffer, told operators to upgrade as soon as possible, and moved Linux packages to packages.xrplf.org with XRPLF signing keys.
- Proposal:LendingProtocolV1_1 and fixCleanup3_4_0 amendments introduced; fixAMMOverflowOffer retired
- Implementation:implemented in xrpld 3.4.0
- Release:released; xrpl.org announcement dated 2026-09-16, GitHub release published 2026-09-17
- Activation:neither new amendment enabled on mainnet at review; explorer data showed 16 and 0 of the 28 validator votes needed
Sources: XRP Ledger blog (xrpl.org) — Introducing XRP Ledger version 3.4.0 (external site) · XRPLF (GitHub releases) — Version 3.4.0 of xrpld (external site) · XRPScan — XRPScan amendments API (external site) · XRP Ledger documentation (xrpl.org) — Amendments (external site) · XRPLF (GitHub) — Release notes from rippled (external site)
-
snarkOS v4.10.0 scheduled the V20 consensus upgrade and encrypted validator links
The v4.10.0 mainnet release scheduled consensus version 20 for mainnet height 22,175,000, estimated for 22 September 2026. V20 tightens how deployed programs are type-checked and bounds the size of declared data types. It also starts a switch to an encrypted, mutually authenticated handshake between validators, with the old handshake refused from version 21.
- Implementation:released in snarkOS v4.10.0, followed by v4.10.1
- Release:mainnet release published 2026-09-15
- Activation:Provable's API shows block 22,175,000 produced on 22 September 2026 and the chain past it by 27 September 2026; that the new rules took effect was not separately confirmed
Sources: ProvableHQ/snarkOS maintainers — snarkOS v4.10.0 release notes (external site) · Provable — Aleo mainnet latest block (Provable Explorer API) (external site) · Provable — Aleo mainnet block 22,175,000 (Provable Explorer API) (external site) · ProvableHQ/snarkOS maintainers — ProvableHQ/snarkOS releases (external site)
-
go-algorand 5.0.2 tightened agreement message checks without a protocol upgrade
The maintainers published go-algorand 5.0.2 as a stable node release aimed at safer, more durable node operation. Its changelog lists three changes to the agreement (block voting) code: stale certificate bundles are discarded following the specification's bundle relay rule, a bound check is added on the voting step, and bundle verification is kept apart from untrusted periods. The notes state that the release contains no protocol upgrade.
- Implementation:three agreement changes listed in the 5.0.2 changelog
- Release:5.0.2 stable released 2026-09-15
- Activation:no network activation: the notes say there is no protocol upgrade; changes apply only on nodes that install it, and how many have was not verified
Sources: algorand/go-algorand maintainers — Algorand 5.0.2 release notes (external site) · algorand/go-algorand maintainers — algorand/go-algorand releases (external site)
-
Firo announces FIRO live on Rosen Bridge as rsFIRO
Firo announced that FIRO is live on Rosen Bridge. Bridged FIRO appears as rsFIRO on Ergo, Ethereum and BNB Chain, with trading pools on Mew Finance (Ergo), Uniswap and PancakeSwap. Rosen coordinates the transfers through Ergo, and Firo gives the current guard set as ten.
- Implementation:Firo support in released Rosen watcher and guard software
- Release:announced live 2026-09-15
- Activation:reported by Firo; not independently tested
Sources: Firo — FIRO goes multichain: rsFIRO is live on Rosen Bridge (external site) · ErgoDocs (Ergo Platform) — Rosen Bridge (external site) · ErgoDocs (Ergo Platform) — Rosen Bridge security model (external site)
-
rsFIRO launched on Rosen Bridge for Ethereum, BNB Chain and Ergo
Firo announced that FIRO can be bridged as rsFIRO to Ethereum, BNB Chain and Ergo through Rosen Bridge, with pools on Uniswap, PancakeSwap and Mew Finance. Rosen's guards control the reserves of native FIRO.
- Implementation:announced live by Firo
- Release:live on Ethereum, BNB Chain and Ergo per the announcement
- Activation:live use not independently observed in this review
Sources: Firo — FIRO goes multichain: rsFIRO is live on Rosen Bridge (external site) · Rosen Bridge — Rosen Bridge: Concept and Assumptions (external site)
-
Lisk publishes withdrawal steps: move every asset to Ethereum before 31 October
Lisk's notice says every asset on Lisk must be withdrawn to Ethereum by 31 October 2026 through bridge.lisk.com, which it calls the only bridge that still works. Bridging takes about 8 days (a prove transaction on Ethereum about an hour after starting, then a 7-day wait); stakers must unlock, wait 3 days and unstake first, about 11 days in total. The bridge interface itself warns against new deposits.
- Implementation:guidance published; bridge interface shows a shutdown banner
- Release:Published
- Activation:withdrawal deadline 31 October 2026
Sources: Lisk — Action required: withdraw all assets from Lisk Chain by 31 October 2026 (external site) · Lisk Support — Lisk Chain Closure (FAQ) (external site) · Lisk — Lisk bridge (external site)
-
Scroll announced a prover upgrade to OpenVM v2.0.0 with a new verifier contract
Scroll announced moving its prover from OpenVM v1.6.0 to v2.0.0, which moves to a new proof system called SWIRL and includes three security fixes from OpenVM v1.7.0, two of them in the Solidity verifier wrapper. A new verifier contract was deployed on Ethereum, the mainnet switch was scheduled for 22 September 2026 with finalization paused for about an hour, and a Scroll reply on the thread that day said the upgrade had been executed.
- Proposal:announcement only; no DAO vote required per Scroll
- Implementation:new mainnet verifier address published
- Release:OpenVM v2.0.0; Scroll monorepo tag v4.8.0 (prover and coordinator code) published 2026-09-22 13:44 UTC
- Activation:executed on mainnet on 2026-09-22, per a Scroll reply on the announcement thread
Sources: Scroll Governance Forum — Announcement: OpenVM v2.0.0 Upgrade on Scroll (external site) · Scroll (GitHub) — v4.8.0 (external site)
-
v4.5 security upgrade shipped with binaries released shortly before activation
Governance approved the v4.5 software upgrade, described as containing important security fixes. The upgrade height 4,511,100 was reached at 12:01 UTC on 14 September 2026. Binaries were made available through a download link 30 minutes before the upgrade, with details of the fixes to follow after mainnet and testnet upgraded.
- Proposal:passed (proposal 24)
- Implementation:security fixes applied; details undisclosed at review
- Release:binary shared by download link 30 minutes before activation; no public GitHub release at review
- Activation:active since height 4,511,100
Sources: Babylon on-chain governance (via Polkachu REST endpoint) — Governance proposal 24: v4.5 Software Upgrade (external site) · Polkachu public REST endpoint for bbn-1 — Applied upgrade plan v4.5 (on-chain query) (external site) · Polkachu public REST endpoint for bbn-1 — Babylon block 4511100 (v4.5 upgrade height) (external site) · Babylon Labs — babylonlabs-io/babylon releases (external site) · Polkachu public REST endpoint for bbn-1 — Babylon governance proposals list (on-chain query) (external site) · Babylon Labs — Release notes from babylon (Atom feed) (external site)
-
Release v9.7.1 makes nodes turn away short-term orders from subaccounts below the collateral floor
protocol/v9.7.1 restores a check that an earlier change had removed. When a node first screens a new short-term order (the CheckTx step), it now rejects the order if the subaccount’s net collateral falls in an equity tier that allows no open orders. Reduce-only orders stay allowed so a position can still be closed, and cancellations are not gated. The pull request says mainnet’s settings already put this floor at $20, and that the change is not consensus-breaking, so operators install it one node at a time with no upgrade proposal.
- Proposal:none required; the pull request describes a rolling upgrade without an upgrade handler
- Implementation:fix merged 14 September 2026 (pull request 3392)
- Release:released as protocol/v9.7.1 on 14 September 2026
- Activation:takes effect per node as operators install it; how many nodes run v9.7.1 was not checked
Sources: dydxprotocol maintainers — protocol/v9.7.1 release notes (external site) · dydxprotocol maintainers — Pull request 3392: fix(clob): enforce short-term order equity tier in CheckTx (external site)
-
Core-Geth v1.13.0 released from the ethereumclassic repository, with MESS on by default
Core-Geth v1.13.0, the first release from the ethereumclassic/core-geth fork, fixes six client vulnerabilities and a GraphQL nesting limit, is built with a current Go toolchain and asks operators to rotate their node key. It removes the ECIP-1110 switch-off, so MESS applies again by default; starts an Ethereum Classic node when no network is named; and ships bootnodes and discovery lists run by its maintainers, saying the ETC Cooperative is winding down and etc.rivet.link has gone offline.
- Implementation:shipped in ethereumclassic/core-geth v1.13.0
- Release:released; every v1.12.x node is asked to upgrade
- Activation:no activation block; the MESS default applies on each node when it upgrades unless switched off
Sources: Core-Geth maintainers (GitHub) — Core-Geth v1.13.0 release notes (external site) · Core-Geth documentation (docs.coregeth.com) — MESS: Modified Exponential Subjective Scoring (external site) · Core-Geth documentation (docs.coregeth.com) — The ETC Cooperative transition (external site) · Core-Geth maintainers (GitHub) — Core-Geth releases (external site) · Core-Geth maintainers (etclabscore, GitHub) — Recent commits to etclabscore/core-geth master (Atom feed) (external site)
-
Robinhood recommended Nitro v3.11.4 for node operators
Robinhood's notices table lists offchainlabs/nitro-node:v3.11.4-7d5ac27-stripped as an available recommended node-software upgrade. The notice explicitly says this release has no chain consensus changes and that nodes on the prior version continue to sync normally.
- Type:Release
- Proposal:Not applicable
- Release:Released recommended node software
- Activation:No consensus change
-
Security Council disclosed temporary restrictions on six addresses after the Vesu oracle incident
Following the Vesu and Pragma oracle incident on 4 September 2026, the Starknet Security Council instructed that six addresses associated with it be temporarily restricted. The note says all restrictions were lifted after the Council finished its investigation.
- Implementation:restrictions applied and later lifted
- Release:notice posted on the forum
- Activation:no restrictions in force according to the notice
Sources: Starknet Community Forum — Vesu incident Note (external site) · Starknet Documentation — Security Council (external site)
-
Mandatory security upgrade v4.0.1-patch.3 applied on 24 September 2026
Terra Classic core maintainers published v4.0.1-patch.3, a mandatory release applying a fix for a critical wasmd and wasmvm vulnerability handled through responsible disclosure, with details due from Cosmos Labs on 28 September 2026. Because the fix changes consensus behaviour, it was rolled out as governance upgrade v14_3 (proposal 12227) at height 30,544,730, which the chain reached at 15:51 UTC on 24 September 2026. A follow-up release, v4.0.2, needs no coordinated upgrade.
- Proposal:passed as proposal 12227 (voting ended 2026-09-22)
- Implementation:shipped in classic-terra/core v4.0.1-patch.3
- Release:mandatory release published 2026-09-14
- Activation:applied at height 30,544,730 on 2026-09-24; nodes read on 2026-09-29 reported 4.0.1-patch.3
Sources: Terra Classic core developers (GitHub) — Terra Classic Core v4.0.1-patch.3 release notes (external site) · Terra Classic on-chain state via PublicNode REST endpoint — Terra Classic proposal 12227: Upgrade to v4.0.1-patch.3 (external site) · Terra Classic on-chain state via PublicNode REST endpoint — Terra Classic applied upgrade plan v14_3 (external site) · Terra Classic on-chain state via PublicNode REST endpoint — Terra Classic block 30,544,730 header (v14_3 upgrade height) (external site) · Terra Classic on-chain state via PublicNode REST endpoint — Terra Classic node info (application, Cosmos SDK and CometBFT versions) (external site) · Terra Classic core developers (GitHub) — Terra Classic Core v4.0.2 release notes (external site)
-
Litecoin Core 0.21.5.8 revalidates MWEB blocks and adds another soft-fork rule
A maintenance release that revalidates the full MWEB block just before it is connected, including blocks reloaded during reorganization or crash recovery, and includes a pool-only 0.21.5.7 security fix whose soft-fork rule from height 3,172,640 rejects MWEB kernels signalling extra data with an empty payload.
- Implementation:merged and released
- Release:Released
- Activation:rule scheduled from height 3,172,640; chain tip is past that height
Sources: litecoin-project — Litecoin Core v0.21.5.8 (external site) · Litecoin Space — Litecoin Space API: chain tip height (external site)
-
Lotus v1.36.3 fixed a remote memory-exhaustion flaw
Lotus Node v1.36.3 is a recommended patch that closes a remote memory-exhaustion issue in the default WebTransport listener (CVE-2026-57497) and stops Ethereum-style log and receipt queries from returning incomplete results while event indexing is unfinished.
- Implementation:patched in Lotus v1.36.3
- Release:released 2026-09-11
- Activation:takes effect per node when operators upgrade; adoption not observed
Source: filecoin-project/lotus — Lotus Node v1.36.3 (external site)
-
Octez EVM node 0.66 released for Etherlink operators; Seoul-era Michelson blocks dropped
Version 0.66 of the Octez EVM node, the node software Etherlink operators run, was published on 11 September 2026. It moves its WebAssembly runtime from Wasmer 3.3.0 to 7.2.1 to fix crashes on macOS ARM64, adds named downloads for the Etherlink 7 kernels ganesha and ganesha-r1, and refuses raw transactions with non-canonical RLP integer encodings at submission instead of leaving them for the kernel to reject. It also fixes several debug and subscription RPCs. Its one breaking change: the node's Michelson runtime no longer decodes or serves blocks tagged with the Seoul (S023) protocol, so Tallinn is now the oldest protocol it supports. No store migration is applied, so operators can downgrade.
- Implementation:implemented in octez-evm-node 0.66
- Release:released 2026-09-11
- Activation:takes effect when each operator installs it; no kernel or network activation
Sources: Tezos project on GitLab (tezos/tezos) — Octez EVM Node Release 0.66 (external site) · Tezos project on GitLab (tezos/tezos) — Octez EVM node changelog (CHANGES_NODE.md at tag octez-evm-node-v0.66) (external site) · Tezos project on GitLab (tezos/tezos) — tezos releases (GitLab Atom feed) (external site)
-
Superhero Wallet 2.11.0 adds default name setting and signing fixes
Superhero Wallet 2.11.0 lets users set a default Aeternity name through a new name contract and adds an account switcher in the confirmation screen. It moves to Aeternity SDK 15.0.0 and fixes several issues, including checking that the transaction shown is the one actually signed, fee double-charging with multiple recipients, and lost account names after network switches.
- Implementation:Implemented
- Release:released 2026-09-10
- Activation:available to users who update
Source: superhero-com/superhero-wallet releases on GitHub — Superhero Wallet v2.11.0 (external site)
-
Chia 2.7.4 released with security hardening and hard-fork readiness
Protocol/reference-client release: Chia 2.7.4 added security, node, wallet, mempool, DataLayer and GUI changes. It also shipped hard-fork-ready plot, harvester, cost and pooling code; the publisher says those rules activate only with the later hard fork, so this release is not evidence of consensus activation.
- Claim:Released
Sources: Chia Network Inc. — Chia 2.7.4 (external site) · Chia Network Inc. — chia-blockchain 2.7.4 release (external site)
-
Client 2.9.5 fixed archive resync failures and was marked a mandatory upgrade
A change in client 2.7.3 made nodes charge 2,500 more gas when replaying the historical blocks that ran a runtime upgrade of the DeployerProxy system contract (mainnet block 31,384,697), so archive nodes resyncing from scratch failed there. Client 2.9.5 restores the canonical gas, adds a replaycheck tool that re-executes blocks and compares them with the chain's receipts, and says governance must not run another DeployerProxy runtime upgrade until every validator runs a patched build.
- Implementation:fix shipped in client 2.9.5
- Release:mainnet release published 2026-09-10; notes call the fleet upgrade mandatory
- Activation:no fork height; applies as each node upgrades; how many validators have upgraded was not checked
Sources: Chiliz (GitHub) — Chiliz Chain client v2.9.5 release notes (external site) · Chiliz (GitHub) — chiliz-chain/v2 releases (external site)
-
Migration snapshot taken and Harmony stops producing blocks
Four days after Harmony announced on X that it would retire its chain, the migration cutoff fell at 14:00 UTC on 10 September 2026 (shard 0 block 93,623,067, shard 1 block 95,882,100). Shard 0 produced its last block 41 minutes later and shard 1 stopped soon after; no blocks have followed. Balances are to be reissued as a new fixed-supply ONE token on Ethereum, with staked ONE moved to validator vaults, subject to thresholds and exclusions.
- Proposal:announced by Harmony on X on 2026-09-06, per press reports; no on-chain governance record found
- 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: harmony-migration repository (polymorpher) — Harmony migration accounting (external site) · harmony-migration repository (polymorpher) — Harmony migration user FAQ (external site) · Harmony — Harmony shard 0 public RPC (external site) · Harmony — Harmony shard 1 public RPC (external site) · The Block — Harmony to fully sunset Layer 1, proposes token migration to Ethereum for AI video initiative (external site) · Harmony Community Forum — Voluntary winding down (external site)
-
Injective USDC announced as the successor to Noble USDC across Cosmos chains and dYdX
Injective said Noble USDC holders could migrate to Circle-issued USDC on Injective through Skip:Go from 11 September 2026, and that dYdX would adopt it as the sole eligible trading collateral on dYdX Chain. The post gives 13 October 2026 as the date Circle Mint stops new USDC minting to Noble and 13 January 2027 as the end of Circle Mint and CCTP access for Noble.
- Proposal:announced migration plan
- Implementation:migration flow announced to open on 11 September 2026
- Release:in progress according to the announcement
- Activation:Noble minting stop scheduled for 13 October 2026; not yet observed
Sources: Injective — Injective USDC Becomes the Canonical Standard Across Cosmos & dYdX (external site) · Injective — Injective USDC will be Adopted by Cosmos and dYdX as the Canonical Stablecoin Standard (external site)
-
Parity outlined how parachain validation would move to JAM
Parity Technologies described four projects for the switch: a production JAM node (PolkaJAM), a minimal relay chain with no DOT and no user transactions, off-chain messaging between parachains, and a Parachain Service that would take over block validation, code upgrades and coretime handling on JAM.
- Proposal:announced plan
- Implementation:in development; the Parachain Service design was presented at the 2026-09-15 OpenDev call
- Release:not released
- Activation:not active
Sources: 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)
-
System-chain runtime 2.5.0 enacted: two new OpenGov tracks and the Individuality pallets
Referendum 1942 upgraded Polkadot's system chains to Fellowship runtime 2.5.0. On Polkadot Hub it adds two OpenGov tracks: technical_maintenance, for operational settings such as quotas, allowances, limits and fees, and prosperity_emergency, for guarding dotUSD's monetary mechanisms. It also adds the pallets of the Individuality framework to the People chain and Polkadot Hub, enables the privileged force_create call for assets on Polkadot Hub and updates the Hub's contract pallet to pallet-revive 0.19.1.
- Proposal:Referendum 1942 executed on 2026-09-10 after Fellowship whitelisting
- Implementation:implemented in Fellowship runtimes 2.5.0 (spec version 2005000)
- Release:released 2026-09-05
- Activation:active on Polkadot Hub by 13:57 UTC on 2026-09-10; the People chain and other system chains were not checked
Sources: Polkadot Fellowship (GitHub) — Runtimes 2.5.0 (external site) · Polkadot Forum — Runtime release notification for v2.5.0 [07.09.2026] (external site) · Subsquare (Polkadot OpenGov) — Referendum 1942: Upgrade System Chains To 2.5 (external site) · Subscan — Polkadot Asset Hub block 20482000 (external site) · Subscan — Polkadot Asset Hub block 20490000 (external site) · Subsquare (Polkadot OpenGov) — Referendum 1944: dotUSD: A Native Stablecoin for Polkadot (external site)
-
Eagle Ray protocol update (node v1.4.0.0) released with the engine fix
Radix's node repository published Eagle Ray v1.4.0.0 on 10 September 2026, two days after a release candidate. The mainnet protocol configuration in that release enacts Eagle Ray unconditionally at the start of epoch 339,898, with user transactions barred during epoch 339,897, so it does not wait for the stake-weighted readiness signal used for earlier updates. The node release notes contain only licence text; the matching engine release, Scrypto v1.4.0 (7 September 2026), moves the engine to a new system version that checks whether a caller may invoke the object it names.
- Implementation:engine change in Scrypto v1.4.0; shipped in babylon-node v1.4.0.0
- Release:released 10 September 2026 (release candidate 8 September)
- Activation:enacted at epoch 339,898; the Gateway records that epoch's first transactions at 11:39 UTC on 11 September 2026
Sources: Radix DLT (babylon-node repository, GitHub) — Eagle Ray v1.4.0.0 (external site) · Radix DLT (babylon-node repository, GitHub) — mainnet_protocol_config.rs at v1.4.0.0 (external site) · Radix DLT (radixdlt-scrypto repository, GitHub) — Scrypto v1.4.0 (Eagle Ray) (external site) · Radix DLT (radixdlt-scrypto repository, GitHub) — system_callback.rs at v1.4.0 (caller access check enabled from system version 5) (external site) · Radix Foundation Gateway — Radix mainnet Gateway transaction stream from epoch 339,898 (read 2026-09-29) (external site)
-
Transaction v1 activation was delayed to epoch 1035
The September 10 changelog announced a delay to give applications more preparation time. The later September 18 activation record supersedes the delay as current activation evidence while preserving the rollout history.
- Stage:Announced
Sources: Solana Foundation — Solana Changelog: September 10, 2026 (external site) · Solana Foundation — Solana Changelog: September 18, 2026 (external site)
-
First Bitcoin bond period (Genesis Bond) opened
Stacks Labs reported that the first institutional bond period closed with 250 BTC locked by standard Bitcoin scripts alongside STX, with four named institutions taking part and a second bonding period opening with limited capacity.
- Implementation:first bond period filled
- Release:live for allowlisted participants
- Activation:second bonding period registration open with limited capacity
Source: Stacks Labs — The Genesis Bond Is Live: Institutions Begin Bitcoin Staking on Stacks (external site)
-
Upgrade 20 moves Ink's fault proofs to super-root dispute games
An OP Labs proposal to Optimism governance bundled Ink with OP Mainnet, Soneium and Unichain for Upgrade 20, an Ethereum-side contract upgrade that replaces Ink's output-root dispute games with super-root games that can later cover several chains at once. It does not switch on cross-chain interop. Optimism's notice set a 24 September 2026 target for mainnet execution.
- Proposal:protocol upgrade proposal posted 2026-09-09; governance vote scheduled to close 2026-09-16
- Implementation:OP Contracts Manager v8.0.0 contracts named in the proposal; Sepolia execution was targeted for 2026-09-17, a week before mainnet
- Release:L1 contract upgrade with no L2 hard fork or activation timestamp
- Activation:targeted for 2026-09-24; Ink's Ethereum portal returned the new game type when read on 2026-09-27, but no dated execution notice was reviewed
Sources: Optimism Collective governance forum — Upgrade 20 - Super Root Dispute Games & OPCM v8.0.0 (external site) · Optimism Docs — Upgrade 20 (external site)
-
Upgrade 20 proposed super-root dispute games and OPCM v8.0.0
The governance proposal described an L1 contract upgrade and a September 24 target that was pending approval and soak at publication; this snapshot does not infer execution from the target date.
- Type:Proposal
- Proposal:Proposed at source publication
- Release:Release candidate evidence cited
- Activation:Not asserted by this snapshot
Sources: Optimism Collective — Upgrade 20 - Super Root Dispute Games & OPCM v8.0.0 (external site) · OP Labs — Optimism monorepo releases (external site)
-
AvalancheGo v1.15.0 released for Helicon
Ava Labs published AvalancheGo v1.15.0 and identified it as the Helicon-capable mainnet release. Release publication is implementation evidence and is kept separate from the later activation record.
- Proposal:six referenced ACPs
- Implementation:Released
- Release:Stable release
- Activation:scheduled-at-release; see later activation record
Sources: Ava Labs — AvalancheGo v1.15.0 (external site) · Ava Labs — AvalancheGo releases (external site)
-
CantonBFT ordering runs on DevNet; TestNet and MainNet adoption delayed
A Logical Synchronizer Upgrade on 29 July 2026 moved DevNet's ordering to CantonBFT, Canton's own BFT orderer. On 8 September 2026 the Foundation said the Splice and Canton teams recommended a temporary delay on TestNet and MainNet; if ready, MainNet would adopt it at the upgrade window of 9 to 10 October 2026. Splice 0.8.0 (4 September 2026) prepared the ordering layer for the switch.
- Proposal:planned; the June 2026 schedule had set MainNet adoption for 8 August 2026
- 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:not active on TestNet or MainNet; MainNet adoption possible on 9 to 10 October 2026 if ready
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)
-
Cardano Foundation published its August 2026 activity update
The monthly report covered partnerships, governance votes, community funding, and developer-infrastructure activity during August.
- Implementation:organizational report published
- Release:published update
- Activation:mixed underlying activities; not one protocol activation
Source: Cardano Foundation — Cardano Foundation Monthly Update: August 2026 (external site)
-
AstralBeam bridge between Casper and other chains introduced on public testnet
The Casper Association announced AstralBeam, a bridge from MAKE Group connecting Casper with Ethereum, Base, Polygon and Robinhood Chain, with a planned link to the T-REX Network's compliance ledger. Tokens are locked on the source chain and minted on Casper once at least three of five relayers attest. AstralBeam's site says its public testnet is live and mainnet is planned for October 2026.
- Implementation:public testnet
- Release:testnet announced
- Activation:mainnet planned for October 2026 per the AstralBeam site; not live at review
Sources: Casper Association — AstralBeam Connects Casper to the Cross-Chain Market for Tokenized RWAs (external site) · AstralBeam (MAKE Group) — AstralBeam: Move value across worlds (external site) · Casper Association — Killing the Honeypot: How AstralBeam Delivers Secure Cross-Chain Infrastructure for RWAs (external site) · Casper Association — The latest from the Casper Association (news index) (external site)
-
Kraken launched kHYPE, a HYPE-backed token, on Ink
Kraken introduced kHYPE, a token backed one-to-one by HYPE held in Kraken's custody, and made it available first on Ink so HYPE holders can use it in Ink applications. Kraken says it plans to extend kHYPE to other networks.
- Implementation:token contract deployed on Ink, per Kraken's post
- Release:announced as available at launch on Ink
- Activation:live from 2026-09-08, per Kraken
-
Scroll team outlined a plan to move the chain to a private, permissioned network
In a forum update the Scroll team said it plans to transition Scroll from a general-purpose public network into a private, application-specific network designed around its AI products, gradually over about nine months. SCR would move to Ethereum mainnet with no change to its supply or tokenomics and would remain the governance token. A later DAO update called the target a permissioned chain and gave indicative dates running from late 2026 to early 2027.
- Proposal:direction announced; formal DAO proposal not yet posted
- Implementation:migration details still under discussion; no migration path published
- Release:indicative: SCR and USX contracts on Ethereum mainnet from mid-November to December 2026
- Activation:not active; chain transition targeted for early 2027
Sources: Scroll Governance Forum — What We've Been Working On at Scroll (external site) · Scroll Governance Forum — Scroll DAO Monthly Update, September 2026 (external site)
-
java-tron GreatVoyage-v4.8.2.2 (Parmenides) mandatory maintenance release
GreatVoyage-v4.8.2.2 (Parmenides) was published and marked mandatory. It refines validation of contract-deployment transactions, improves edge-case handling of Stake 2.0 and SELFDESTRUCT, and reuses virtual-machine jump tables to speed up contract execution.
- Implementation:shipped in java-tron v4.8.2.2
- Release:mandatory release; no deadline stated in the release notes
- Activation:not stated in the reviewed sources
Sources: tronprotocol (GitHub) — GreatVoyage-v4.8.2.2 (Parmenides) release notes (external site) · TRON Developer Hub — Release Announcements (external site)