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 9 of 14.
One chain's developments, A to Z
-
Circle-issued USDC and CCTP went live on Injective mainnet
Injective announced that USDC issued by Circle and Circle's Cross-Chain Transfer Protocol were live on mainnet, usable from both CosmWasm and the EVM. Circle's pages list an Injective USDC address and Injective as CCTP V2 domain 29.
- Implementation:issued by Circle on Injective mainnet
- Release:announced live
- Activation:listed by Circle as of 2026-09-27
Sources: Injective — USDC and CCTP live on Injective mainnet (external site) · Circle — USDC contract addresses (external site) · Circle — CCTP supported blockchains (external site) · Injective — USDC migration guide (external site)
-
iotex-core v2.4.0 shipped the Yap hard fork: four Pectra changes and a delegate exit queue
IoTeX released node version 2.4.0, a mandatory upgrade activating at block 48,985,561 (estimated 7 June 2026). Under IIP-60 it adds delegated code for ordinary accounts (EIP-7702) with an IoTeX abuse-prevention blacklist, a calldata cost floor, recent block hashes kept in state and BLS12-381 precompiles. It also replaces immediate delegate exits with a queue that admits at most one departing candidate every 24 epochs (the default interval); the candidate's self-stake stays locked from the exit request until the scheduled exit height is reached and the owner confirms the exit. A mandatory fix, v2.4.1, followed on 14 May 2026.
- Proposal:IIP-60, created 2026-01-08
- Implementation:shipped in iotex-core v2.4.0, with fixes in v2.4.1
- Release:mandatory release published 2026-05-07
- Activation:scheduled for block 48,985,561 (estimated 2026-06-07); mainnet was past that height on 2026-09-29
Sources: IoTeX (GitHub) — iotex-core v2.4.0 release (Yap hard fork) (external site) · IoTeX (iotex-bootstrap, GitHub) — v2.4.0 release note (Yap hard fork) (external site) · IoTeX Improvement Proposals (GitHub) — IIP-60: Enable Ethereum Pectra Upgrade (external site) · IoTeX (iotex-bootstrap, GitHub) — v2.4.1 release note (external site) · IoTeX Foundation — IoTeX mainnet Ethereum JSON-RPC endpoint (read 2026-09-29) (external site)
-
Sei scheduled the end of Cosmos-format transactions for 15 June 2026
Sei told exchanges and custodians to switch to 0x-address integrations before 15 June 2026, after which Cosmos-native transaction interfaces and new address associations through Cosmos wallets would stop working. Funds under sei1 addresses that were never associated would not be accessible.
- Proposal:part of SIP-3
- Implementation:announced; activation not observed
- Release:no release or upgrade height named in reviewed sources
- Activation:not confirmed as of 2026-09-27
Sources: Sei Blog — What SIP-03 means for exchanges and custodians (external site) · Sei Documentation — Sei EVM Upgrade for Exchanges and Custodians (external site) · Sei Documentation — SIP-03 Migration Guide (external site)
-
Theta node v4.1.3 released as a recommended, non-hard-fork update
Theta Labs released node version 4.1.3, which its notes describe as further block synchronization improvements and several security hardening fixes; the listed change serialises block-branch downloads and prioritises queued blocks. It follows v4.1.1 (October 2025) and v4.1.2 (December 2025), which also targeted block synchronization.
- Implementation:shipped in theta-protocol-ledger v4.1.3
- Release:recommended upgrade; no deadline stated
- Activation:no activation height; takes effect when each node upgrades
Sources: Theta Labs (GitHub) — Theta v4.1.3 release notes (external site) · Theta Labs (GitHub) — theta-protocol-ledger releases (external site) · Theta Labs (GitHub) — Theta v4.1.2 release notes (external site) · Theta Labs (GitHub) — Theta v4.1.1 release notes (external site)
-
Litecoin Core 0.21.5.5 hardened MWEB consensus checks
A patch release adding validation for MWEB inputs, peg-ins, kernel fees and lock heights, overflow protection in amount and fee arithmetic, consensus parameters for frozen or approved MWEB items, and a larger peer-to-peer message limit so valid MWEB blocks fit.
- Implementation:merged and released
- Release:Released
- Activation:effective for nodes that upgrade; adoption not measured
Source: litecoin-project — Litecoin Core v0.21.5.5 (external site)
-
Protocol 26 (Yardstick) added validator-voted freezing of ledger entries
Protocol 26, listed on Mainnet from 6 May 2026, lets validators keep an on-chain list of frozen ledger keys through network configuration votes: transactions that touch a frozen account, trustline or contract entry are rejected and affected order-book offers are removed, with an allow-list for approved recovery transactions. It also added checked 256-bit arithmetic, limited time-to-live extensions, muxed-address conversions and more zero-knowledge helper functions for contracts.
- Proposal:CAP-77 final
- Implementation:shipped in Protocol 26 builds of the node software
- Release:stable releases available from 8 April 2026
- Activation:Mainnet upgrade listed for 6 May 2026
Sources: Stellar Docs (Stellar Development Foundation) — Software Versions (external site) · Stellar Development Foundation — Stellar Yardstick, Protocol 26 Upgrade Guide (external site) · Stellar Protocol (GitHub) — CAP-0077: Freeze Ledger Entries via Network Configuration (external site)
-
v4.3.0 fixed two security flaws and removed phantom bitcoin voting power left by stake extensions
Babylon Labs released node version v4.3.0 with fixes for two security advisories. The first covered a stake extension (called stake expansion in the code) that was unbonded early, before its Bitcoin inclusion proof was recorded; the original stake could then stay active on Babylon, with voting power, although its bitcoin output had already been spent. The v4.3 upgrade handler finds such original stakes and force-unbonds them. The second fix stops a validator's checkpoint signature for the wrong epoch from being folded into an epoch's aggregate signature, which could seal a checkpoint whose signature does not verify.
- Proposal:expedited software-upgrade vote in May 2026, per the on-chain proposals list read earlier on 27 September 2026
- Implementation:two advisory fixes plus a v4.3 upgrade handler that force-unbonds affected original stakes
- Release:released as v4.3.0 on GitHub on 5 May 2026
- Activation:mainnet upgrade described in the governance record; activation height not re-checked in this pass
Sources: Babylon Labs — babylon v4.3.0 release (external site) · Babylon Labs — Babylon node CHANGELOG at tag v4.4.0 (external site) · Babylon Labs — Changes between babylon v4.2.7 and v4.3.0 (external site) · Babylon Labs — v4.3 upgrade handler source (external site) · Polkachu public REST endpoint for bbn-1 — Babylon governance proposals list (on-chain query) (external site)
-
Bitcoin Core disclosed CVE-2024-52911
Bitcoin Core disclosed a high-severity use-after-free crash issue in versions after 0.14.0 and before 29.0 when processing a specially crafted invalid block. The project states that the issue was fixed in 29.0, released in 2025, and disclosed after the last vulnerable 28.x line reached end of life.
- Stage:Reported
Source: Bitcoin Core contributors — Disclosure of CVE-2024-52911 (external site)
-
v8 upgrade activated after Hibiscus (v7) was skipped
Celestia v8 activated at height 10,960,599 and carried the changes first planned for Hibiscus (v7): a forwarding module for single-signature onward Hyperlane transfers, a zero-knowledge proof security module for Hyperlane, and validator commission bounds of 20% to 60%. v7 never activated on Mainnet Beta because a forwarding-module bug surfaced during the testnet rollout.
- Proposal:CIP-049 Final
- Implementation:released in celestia-app v8
- Release:activated on Mainnet Beta
- Activation:active from height 10,960,599
Sources: Celestia Docs — Network upgrades (external site) · Celestia Improvement Proposals — CIP-049: v8 Network Upgrade (external site) · Celestia blog — Upcoming Celestia Upgrade: Hibiscus (V7) (external site) · celestiaorg — celestia-app release notes (external site)
-
Linea's rollup stack was contributed to Linux Foundation Decentralized Trust as Lineth
Linux Foundation Decentralized Trust announced that the Linea Consortium joined as a premier member and contributed the open-source ZK rollup stack behind Linea, renamed Lineth, as its newest code project under vendor-neutral governance; Linea's post calls it an incubating project. The announcement says the same team keeps building it; neither it nor Linea's own post describes changes to how Linea Mainnet is operated.
- Implementation:code contributed and repository moved to the Lineth organization
- Release:not a software release
- Activation:incubating project at Linux Foundation Decentralized Trust
Sources: Linux Foundation Decentralized Trust — Linea Consortium Becomes Premier Member of Linux Foundation Decentralized Trust; Contributes Linea Stack as Newest Code Project (external site) · Linea — Building a credible neutral infrastructure: Linea Stack joins Linux Foundation Decentralized Trust as Lineth (external site) · Linea Documentation — Linea and Lineth (external site) · Lineth (GitHub) — LFDT-Lineth/lineth-monorepo (external site)
-
Protokit application-chain framework went live on Mina devnet
o1Labs announced that Protokit, a framework for application chains that run a sequencer off-chain and settle recursive proofs to Mina, is live on devnet and asked developers for feedback before any mainnet launch.
- Implementation:alpha framework
- Release:Devnet
- Activation:not on mainnet as of review
Sources: Mina Protocol blog (o1Labs) — Introducing Protokit: Privacy-Enabled Applications on Mina (external site) · Mina documentation — Protokit (external site) · Protokit — Protokit (external site)
-
Aurora DAO approved 2026 funding for Aurora Labs and its NEAR validator
Two forum proposals were posted on 2026-05-04 and marked approved on 2026-05-22. One grants Aurora Labs 25,000,000 AURORA for 2026 and reports 2025 work on engine upgrades, Virtual Chains and NEAR Intents tooling. The other continues the NEAR validator the DAO runs, with a new delegator reward farm.
- Proposal:Approved
- Implementation:approval stated by staff reply
- Release:not applicable
- Activation:not independently verified
Sources: Aurora Forum — [APPROVED] Aurora Labs Grant Allocation for 2026 (external site) · Aurora Forum — [APPROVED] Aurora Validator on NEAR 2026 (external site)
-
Governance caps Kava Mint and Lend debt near current usage (proposal 215)
Proposal 215 passed when voting closed on 4 May 2026. It lowered the debt limits for Kava Mint collateral types and Kava Lend markets to roughly their existing usage, left incentive schedules unchanged and set the deadline for claiming incentive rewards to 30 June 2026.
- Proposal:Passed
- Implementation:parameter change applied on-chain
- Release:no software release involved
- Activation:in force since 4 May 2026
Sources: Kava Labs public REST endpoint — Proposal 215: Phase 1, Cap Kava CDP and Lend Debt, Extend Incentive Claims (external site) · Kava Labs public REST endpoint — Kava CDP parameters (REST endpoint) (external site)
-
Validators cut TON network fees about six-fold
After a validator software update on April 28, 2026 and a validator vote on gas prices that began on April 30, 2026, the official channel announced on May 4, 2026 that fees had dropped about six times. ton.org quoted about 0.00039 Gram for a simple transfer at review time.
- Proposal:validator configuration vote reported as started 2026-04-30
- Implementation:validator software update scheduled for 2026-04-28 (node release v2026.04-1 is dated that day), then a network configuration change
- Release:fee change made by configuration vote rather than by a software release
- Activation:reported active by 2026-05-04
Sources: Gram of TON (Telegram channel) — Fees in TON have dropped 6x (external site) · Gram of TON (Telegram channel) — Blockchain fee reduction plan (external site) · Gram of TON (Telegram channel) — Gram of TON (official channel, public web view) (external site) · ton-blockchain maintainers — TON releases (external site) · TON (ton.org) — TON: The Open Network (external site) · TON Docs — Transaction fees (external site)
-
Evmos turns off incoming IBC transfers and moves funds out of channels
Proposal 329 set IBC transfers into Evmos to disabled and moved pending funds in the Gravity Bridge and Axelar channels. The day before, proposal 328 had moved funds held in channels with the Cosmos Hub, Noble, Kava and Axelar toward the Cosmos Hub.
- Proposal:Passed
- Implementation:executed by governance
- Release:parameter change and governance transfers; no software release
- Activation:effective from proposal execution in early May 2026
Sources: Stakeflow — Evmos Proposal #329: Disable receipt of IBC tokens & Gov IBC transfer from Gravity (external site) · Stakeflow — Evmos Proposal #328: Gov IBC Transfer to Cosmoshub (external site)
-
Governance blocked new CosmWasm deployments on Sei
As part of SIP-3, Proposal 115 made new CosmWasm code uploads and contract instantiations fail on Sei. Existing CosmWasm contracts keep running and can still be queried, and new tokens are expected to use ERC standards.
- Proposal:Proposal 115 passed, per Sei's migration guide
- Implementation:uploads and instantiations blocked
- Release:governance change; no separate client release named in reviewed sources
- Activation:active per Sei's blog and migration guide
Sources: Sei Blog — SIP-03: No new CosmWasm contract deployments (external site) · Sei Documentation — SIP-03 Migration Guide (external site) · Sei Documentation — Token Standards (external site) · sei-protocol/sips — SIP-3: EVM only (external site)
-
World Chain activated the OP Stack Jovian upgrade
The Superchain Registry sets World Chain's Jovian activation at 1 May 2026, 00:00 UTC, five months after OP Mainnet. Optimism's notice describes Jovian as adding a configurable minimum base fee, a per-block limit on estimated data use and a revised operator fee formula.
- Implementation:Activated
- Release:part of the OP Stack Jovian release
- Activation:active since 2026-05-01 per the Superchain Registry
Sources: Optimism (ethereum-optimism/superchain-registry) — Superchain Registry: mainnet/worldchain.toml (external site) · Optimism Docs — Upgrade 17: Jovian (external site)
-
ParyonUSD launched a BCH-collateralized stablecoin on Bitcoin Cash
ParyonUSD (formerly ParityUSD) announced its mainnet launch: users can borrow the dollar-pegged PUSD CashToken against BCH or stake PUSD in a stability pool. At launch the minimum collateral ratio was temporarily 180% and redemptions were disabled.
- Implementation:contracts deployed on mainnet per the project
- Release:launched 2026-04-30
- Activation:live since launch; redemptions enabled 2026-05-08 per the project; not a protocol change
Sources: ParyonUSD — ParyonUSD Launch Day (external site) · ParyonUSD — ParyonUSD (external site) · ParyonUSD — New Name, Familiar Face (external site) · ParyonUSD — State of PUSD #1 (external site)
-
Chia published a Proof of Space 2.0 community Q&A
Protocol roadmap communication, not activation: Chia described the proposed Proof of Space 2.0 design, CHIP-48 and CHIP-49, replotting and a transition plan. The described schedule and parameters are historical publisher statements; this record does not establish mainnet activation or final parameters.
- Claim:Announced
Source: Chia Network Inc. — Proof of Space 2.0: Community Q&A Summary (external site)
-
Oasis announced a shift toward building its own applications
Co-founder Jernej Kos wrote that Oasis is realigning internally and focusing on the application layer. The post said the first result, Privana (private trading, yield and automation with self-custody), was live, and that Oasis would keep supporting third-party developers. The post announced no protocol or token change.
- Implementation:internal realignment announced
- Release:post called Privana live; its site showed a waitlist on 2026-09-27
- Activation:no network change
Sources: Oasis blog — Oasis: New Chapter (external site) · Oasis blog — Privana: A Practical Liquefaction Implementation (external site) · Privana — Privana (external site)
-
Unichain's official node setup switched from op-geth to op-reth
Uniswap's unichain-node repository replaced the op-geth execution client with op-reth, a month before Optimism ended op-geth support on 31 May 2026. The versions that meet Optimism's Karst minimums (op-node 1.19.2 and op-reth 2.3.3) were pinned on 15 July 2026, a week after Karst activated; before that the repository pinned op-node 1.19.0 and op-reth 2.3.1.
- Implementation:merged in the official node repository
- Release:released as unichain-node v0.6.0 on 2026-04-29; op-reth images published by OP Labs
- Activation:required for mainnet since Karst on 2026-07-08
Sources: Uniswap on GitHub — Uniswap/unichain-node commit history (external site) · Uniswap on GitHub — Unichain op-reth Migration (v0.6.0) (external site) · Uniswap on GitHub — Uniswap/unichain-node (external site) · Optimism Docs — End of Support for op-geth and op-program (external site) · Uniswap Labs (Unichain docs) — Set Up a Node (external site)
-
xChain Accounts let EVM wallets control linked Algorand accounts
The Algorand Foundation announced xChain Accounts, which create an Algorand account linked to an EVM address and check the EVM wallet's signatures in an on-chain smart account, so MetaMask, Rabby and Coinbase Wallet users can use Algorand apps. The announcement named Alpha Arcade as live with it.
- Implementation:smart-account contract and integration SDK described as available
- Release:announced as live
- Activation:live with one integrating app at announcement; wider adoption not verified
Sources: Algorand Foundation — Use EVM Wallets on Algorand: xChain Accounts are now live with MetaMask, Rabby & Coinbase Wallet (external site) · Algorand Foundation — xChain Accounts (external site)
-
SV Node 1.2.2 relaxed post-Chronicle standardness checks
SV Node 1.2.2, an optional update, relaxed and corrected the node's standard-transaction checks after Chronicle, including the allowed transaction version range and the push-only check on unlocking scripts. It also added a parser that streams large peer-to-peer messages to disk, and it lets operators accept non-standard transactions on mainnet with -acceptnonstdtxn.
- Implementation:shipped in SV Node 1.2.2
- Release:optional upgrade
- Activation:takes effect when each node upgrades; no activation height
Sources: BSV Association (GitHub) — Bitcoin SV Version 1.2.2 release notes (external site) · BSV Association (GitHub) — bitcoin-sv releases (external site)
-
CHZ and Fan Tokens began moving to Base and Solana through LayerZero
The Chiliz Group announced LayerZero-based omnichain transfers that let CHZ and PEPPER, followed by selected Fan Tokens, exist on Solana and Base with one supply shared across chains, through its new omnichain bridge. Chiliz describes a multi-verifier (multi-DVN) setup and says that 10% of Fan Token sale revenue across chains will fund CHZ buy-backs that are burned. A February 2026 governance proposal (CIP-050) asked validators to clean up the contract registry as a prerequisite for the LayerZero integration; its vote result was not found.
- Proposal:registry clean-up proposal CIP-050 put to validators in February 2026
- Implementation:LayerZero endpoint contracts deployed on Chiliz Chain, per the docs
- Release:omnichain bridge live at bridge.chilizchain.com
- Activation:the docs say support started in April 2026 with CHZ and PEPPER first; by the review date Chiliz's token list showed every Fan Token on Base and Solana, and CHZ and PEPPER also on Robinhood Chain
Sources: Chiliz blog — Chiliz brings Fan Tokens to Solana and Base (external site) · Chiliz Chain Docs — Using Chiliz Bridge (external site) · Chiliz Chain Docs — Smart Contract Addresses (external site) · Chiliz Chain Docs — Token Contract Addresses (external site) · Chiliz Chain Docs — February 2026: Contract Removal and Clean-Up Proposal (CIP-050) (external site)
-
FAssets v1.3 announced as live on mainnet, with direct FXRP minting
Flare announced that FAssets v1.3 is live on Flare Mainnet after an earlier Songbird deployment. Users now mint FXRP by sending XRP on the XRP Ledger to the FAssets system address with a destination tag, a memo or a Flare Smart Account instruction; an executor relays an FDC payment proof, and FXRP is minted without choosing an agent. Agents still handle redemptions under the existing collateral model, and v1.3 adds executor restrictions, hourly and daily mint caps, delays on large mints and a governance path to release delayed mints.
- Implementation:FAssets v1.3 deployed, per Flare's announcement
- Release:announced as live on Flare Mainnet on 28 April 2026
- Activation:live on mainnet per the April announcement, after a Songbird deployment; Flare's September 2026 post dates mainnet arrival to mid-May 2026 (not reconciled)
Sources: Flare — FAssets v1.3 is live: direct FXRP minting fits the rails XRP already uses (external site) · Flare Developer Hub — Core Vault (external site) · Flare Developer Hub — Flare Smart Accounts (external site) · Flare — One year of FXRP on Flare (external site)
-
IOTA mainnet switched its consensus protocol from Mysticeti to Starfish
The IOTA Foundation announced that mainnet had adopted Starfish, its successor to Mysticeti. Node release v1.21.1 (protocol version 24), published on 22 April 2026, switched consensus to Starfish on all networks, and the Foundation's Q2 2026 update gives 23 April 2026 as the mainnet go-live date. Starfish separates block headers from transaction data and is designed to keep committing when some validators lag.
- Implementation:implemented in node v1.21.1
- Release:mainnet release v1.21.1 published 2026-04-22
- Activation:live on mainnet from 23 April 2026 according to the Foundation's Q2 2026 update
Sources: IOTA Foundation blog — Starfish on Mainnet: Reliable Blockchain Consensus for Global Trade (external site) · iotaledger/iota releases — [Mainnet] v1.21.1 (external site) · IOTA Foundation blog — IOTA & TWIN Progress Update: Q2 2026 (external site) · IOTA Foundation blog — Why Starfish Matters (external site)
-
Litecoin Foundation published a postmortem of the 2026 MWEB inflation bug and invalid-chain reorg
The postmortem describes a March 2026 MWEB validation bug that created an inflated 85,034.47 LTC peg-out, its containment by freezing outputs with miner-only builds and a negotiated recovery, and an April 25 attempt that led unupgraded miners to build a 13-block invalid chain later reorganized away.
- Implementation:fixes shipped in emergency miner-only builds and then public releases
- Release:Litecoin Core 0.21.5.4 released (GitHub timestamp 2026-04-26)
- Activation:fixes enforced by upgraded nodes; frozen outputs enforced in consensus code
Sources: Litecoin Foundation — Litecoin MWEB Security Incident Postmortem (external site) · litecoin-project — Litecoin Core v0.21.5.4 (external site)
-
Radix Foundation moved to maintenance mode and pre-funded core services through 2026
The Foundation said that from May 2026 it would reduce to essentials: minimal new development, critical-only social updates and minimal support. The Gateway, Signalling Server and Radix Connect Relay moved to a standalone operation run by its former DevOps team, pre-funded through December 2026. The Dashboard, docs and developer console moved to community or free hosting, the eXRD route runs over Hyperlane, and the remaining treasury is to pass to a community entity once one exists.
- Proposal:set out in the January 2026 strategy
- Implementation:services transferred or moved to community hosting as described
- Release:announced 28 April 2026
- Activation:maintenance mode from May 2026
Sources: Radix Blog — Foundation Update: Moving to Maintenance Mode (external site) · Radix Blog — 2026 Strategy: The Next Chapter of Radix (external site) · Radix Blog — The Foundation Operational Stack: Mapping the 2026 Transition (external site)
-
v3.17.0 burned most of the Reserve and set RUNE's maximum supply to 360 million
THORNode v3.17.0 implemented ADR-023, burning about 64.9 million RUNE from the protocol Reserve and setting the maximum supply to 360 million RUNE. The same release moved the developer fund to a 2-of-3 multisig and retired the bug bounty program.
- Proposal:ADR-023 accepted; the April 2026 blog post says it had passed
- Implementation:shipped in THORNode v3.17.0
- Release:v3.17.0 tagged 2026-04-21
- Activation:upgrade set for block 25,959,000, estimated 28 April 2026; THORChain's tokenomics page now gives the 360 million maximum supply
Sources: THORChain blog — Protocol Upgrade - v3.17.0 (external site) · THORChain (GitLab) — THORNode v3.17.0 release (external site) · THORChain Dev Docs — ADR 023: $RUNE Supply Restructure (external site) · THORChain blog — ADR023 - Changing RUNE FDV (external site) · THORChain blog — THORChain Exploit Report #2 (external site) · THORChain Docs — Tokenomics of RUNE and TCY (external site)
-
Neo Council cut Neo N3 block time to 3 seconds and GAS issuance to 1 per block
The Neo Council approved and executed a single proposal setting the Neo N3 mainnet block time to 3,000 milliseconds and new GAS issuance to 1 GAS per block, with 13 of 21 Council votes against a quorum of 11. The change had been proposed in April 2025 alongside the Echidna hard fork, which made block time a Policy contract setting; before it, blocks came about every 15 seconds with 5 GAS each.
- Proposal:proposed April 2025; approved by 13 of 21 Council votes
- Implementation:executed as an on-chain Council proposal through native contracts
- Release:relied on the Echidna hard fork in Neo-CLI v3.8.0 (mainnet block 7,300,000)
- Activation:announced as executed on mainnet, and Neo's July 2026 upgrade notice assumed 3-second blocks; the actual block interval was not measured in this review
Sources: Neo — Neo N3 Network Update: 3-Second Block Time and GAS Adjustment (external site) · Neo — Neo N3 Releases Neo-CLI v3.8.0 & Proposes Block Time and GAS Generation Rate Adjustments (external site) · Neo — Neo-CLI v3.10.1 TestNet and MainNet Upgrade Notice (external site)
-
Cargo Linux containers went live on Acurast Canary
Acurast launched Cargo, which runs Linux containers in any language on attested Android phones, on the Canary network, with admission limited to phones that pass hardware key attestation with a locked bootloader. Release v0.25.5 (8 May 2026) added the shell job module Cargo needs to both Canary runtime 57 and Mainnet runtime 13, and Acurast's Cargo quickstart now describes Mainnet deployments.
- Implementation:live on Canary; runtime support shipped for Mainnet in v0.25.5
- Release:announced 2026-04-24
- Activation:active on Canary; Mainnet availability described in Acurast's quickstart but not independently verified
Sources: Acurast blog — Codename: Cargo Now Live on Canary (external site) · Acurast (GitHub) — acurast-v0.25.5 release notes (Canary Runtime 57, Mainnet Runtime 13) (external site) · Acurast Docs — Quickstart - Cargo (external site)
-
Confidential APT transfers enabled on mainnet
Governance executed a proposal enabling confidential transfers for APT under AIP-143, followed on 30 April 2026 by a proposal enabling the batch Bulletproofs natives that confidential assets depend on. Users who opt in hold encrypted APT balances and send hidden amounts; sender and recipient addresses stay public.
- Proposal:AIP-143 marked Accepted
- Implementation:confidential asset framework with APT allow-listed
- Release:delivered by governance proposals 188 and 189
- Activation:live on mainnet per the Aptos confidential asset docs
Sources: Aptos Governance (Aptos Foundation) — AIP 143: Enable APT for Confidentiality (external site) · Aptos Governance (Aptos Foundation) — Enable Bulletproofs Batch Natives (external site) · Aptos Foundation AIPs — AIP-143: Confidential APT (external site) · Aptos Docs — Confidential Asset (CA) (external site)
-
Fan Tokens moved to 18-decimal contracts
Chiliz announced that from 27 April 2026 Fan Tokens would move across exchanges from whole-unit (0-decimal) contracts to new 18-decimal CAP-20 contracts. Most exchanges migrate balances for their customers; holders in self-custody swap through Chiliz's migration app, which takes the old tokens and returns the same amount in the new contract. The docs say every Fan Token had moved by the second quarter of 2026.
- Implementation:new 18-decimal contracts deployed per token
- Release:exchange-wide transition announced to start 2026-04-27
- Activation:docs say all Fan Tokens migrated by Q2 2026; per-token dates are given by quarter only
Sources: Chiliz blog — Decimal Fan Token Rollout: Upgrading the Digital Asset Class for Sport (external site) · Chiliz Chain Docs — 2026 Migration to Decimal Fan Tokens (external site) · Chiliz Chain Docs — Doc Updates (external site)
-
FIP.16 accepted: lower FLR inflation, a higher base fee floor and a single block builder roadmap
Flare holders accepted FIP.16, written by the Flare Foundation, with 98.06% of votes cast in favour. It sets annual FLR inflation at 3% (down from 5%) with a 3 billion FLR yearly cap, raises the minimum base fee from 25 to 500 gwei, raises the base FDC request fee for most attestation types from 1 to 20 FLR, sends most FDC fees and part of FAssets fees to new FIRE pools, gives P-chain stake five times the weight of WFLR delegations in data-provider signing weight, sets a 20% minimum entity fee, raises the per-validator stake cap to 300M FLR, and lays out stages that move block building, then proposing, to one governance-designated entity, starting with the Flare Foundation.
- Proposal:accepted on 24 April 2026
- Implementation:fee floor, stake cap and minimum delegation fee shipped in go-flare v1.14.0; Flare reports the first emissions cut executed in mid-May 2026; FDC fee, FIRE and signing-weight changes not verified
- Release:hard-fork parts released in go-flare v1.14.0 on 17 June 2026
- Activation:hard-fork parts scheduled for Flare Mainnet on 14 July 2026; inflation cut reported by Flare as executed, not checked on chain; block-builder stages not verified as active
Sources: Flare Governance Proposals — FIP.16: Restructure FLR Tokenomics for Long-Term Network Sustainability (external site) · Flare Foundation (GitHub) — Release Notes: Flare and Songbird networks (external site) · Flare Foundation (GitHub) — go-flare v1.14.0 (external site) · Flare — One year of FXRP on Flare (external site)
-
Osmosis v31.0.2 updated CometBFT to v0.38.22 with stricter sync and evidence checks
Osmosis v31.0.2 was released on 22 April 2026. Its notes list one change, an update of the bundled CometBFT consensus engine to its latest version, and the dependency file at that tag pins CometBFT v0.38.22. The CometBFT v0.38.22 notes, published 10 April 2026, add checks on reported validator-misbehaviour evidence and make a node fully verify block commits while it catches up through block sync. Neither set of notes ties these changes to a security advisory.
- Implementation:CometBFT v0.38.22 included in Osmosis v31.0.2
- Release:released 2026-04-22
- Activation:takes effect on each node when its operator installs it; how many validators run it was not checked
Sources: Osmosis maintainers — Osmosis v31.0.2 release (external site) · Osmosis maintainers — Osmosis v31.0.2 go.mod (external site) · CometBFT maintainers — CometBFT v0.38.22 release (external site)
-
Polygon set 1 July 2026 as the Polygon zkEVM sunset date and announced a claims process
Polygon's final reminder said the sequencer would be switched off on 1 July 2026 and urged users to bridge to Ethereum first. Balances left in ordinary wallets would be snapshotted and made claimable on Ethereum, and funds locked in DeFi protocols could not be migrated automatically. Assets not claimed would be considered abandoned after 31 December 2027.
- Implementation:sunset plan and claims process announced
- Release:claims interface to be published after the sunset
- Activation:carried out two days later than announced: Polygon's sunset page gives 3 July 2026 as the sequencer sunset date
Sources: Polygon Community Forum — Polygon zkEVM Mainnet Beta Sunset: Claim Your Funds (external site) · Polygon Community Forum — Sunsetting Polygon zkEVM Mainnet Beta in 2026 (external site)
-
Laplace hard fork proposed for 100 ms opBNB blocks; alpha builds only
BNB Chain opened pull requests in its op-node and op-geth repositories for a hard fork named Laplace, which would cut opBNB's block interval to 100 ms, and tagged v0.6.0.alpha builds of both. The pull requests were still open at review and no testnet or mainnet date had been published.
- Proposal:open pull requests in bnb-chain/opbnb and bnb-chain/op-geth
- Implementation:alpha builds tagged v0.6.0.alpha
- Release:no stable release
- Activation:no testnet or mainnet date published
Sources: BNB Chain (GitHub, bnb-chain/opbnb) — feat: implement Laplace hardfork in op-node (pull request #337) (external site) · BNB Chain (GitHub, bnb-chain/op-geth) — feat: op-geth supports Laplace hardfork (pull request #320) (external site) · BNB Chain (GitHub) — bnb-chain/opbnb releases Atom feed (external site) · BNB Chain (GitHub) — bnb-chain/op-geth releases Atom feed (external site)
-
Starknet v0.14.2 went live with in-protocol proof verification for private transactions
StarkWare announced v0.14.2 on mainnet. Transactions can now carry an off-chain execution proof that the network verifies natively (SNIP-36), which enables the STRK20 shielded-token framework. The release also raised storage costs while lowering base L2 gas prices, and upgraded StarkGate token contracts.
- Proposal:SNIP-36, SNIP-37 and SNIP-13 changes
- Implementation:Released
- Release:v0.14.2 on mainnet
- Activation:active on mainnet from the announcement date
Source: Starknet — Starknet v0.14.2: The Privacy Engine Arrives (external site)
-
Bitcoin Core 31.0 released
Bitcoin Core 31.0 introduced implementation changes including cluster-mempool-related behavior and the initial PrivateBroadcast feature. It is a major client-software release; later security guidance corrected the privacy expectations for PrivateBroadcast and 31.1 contains the related fix.
- Stage:Release
Sources: Bitcoin Core contributors — Bitcoin Core 31.0 release notes (external site) · Bitcoin Core contributors — Disclosure of an IP address leak in PrivateBroadcast (external site) · Bitcoin Core contributors — Bitcoin Core 31.1 release notes (external site)
-
NNS governance release enabled Mission 70 changes to dissolve delays and voting rewards
DFINITY's NNS governance changelog records proposal 141441, which enabled the Mission 70 voting-reward changes: the maximum neuron dissolve delay fell from eight years to two (existing neurons were capped), neurons can vote with two weeks of dissolve delay instead of six months, the dissolve-delay bonus became quadratic with a three-times maximum, the voting-rewards pool was scaled down by about 36.71%, and neurons that had held the old eight-year maximum were given a 10% bonus.
- Proposal:NNS proposal 141441
- Implementation:implemented in the NNS governance canister
- Release:released per the changelog entry dated 2026-04-17
- Activation:reflected in current governance documentation
Sources: dfinity/ic maintainers — NNS governance changelog (external site) · Internet Computer Developer Docs (DFINITY) — Governance (external site)
-
Metis reported that average Andromeda block time slowed from about 12 to about 17 to 18 seconds
A Metis post on its governance forum says average L2 block time rose from around 12 seconds to roughly 17 to 18 seconds over the previous year, describing it as an adjustment in block production speed. Because sequencer rewards are fixed per block, Metis recalculated its expected sequencer reward rate and said block-time performance remains a focus.
- Implementation:observed change in block production reported by Metis
- Release:no associated software release named
- Activation:in effect at the time of the post
Source: Metis CEG forum — Metis Expected Sequencer Mining Rewards Rate (MRR) Update (external site)
-
op-geth v0.5.10 limits single transactions to 16,777,216 gas in its pool and block building
BNB Chain released op-geth v0.5.10, which enforces a per-transaction gas limit of 16,777,216 (EIP-7825) both when a transaction enters the pool and when blocks are packed, to stop oversized transactions from affecting the network. The release also adds bundle-pool logging and sets the bundle lifetime to 240 blocks to match the current 250 ms block time.
- Implementation:shipped in op-geth v0.5.10
- Release:released; no deadline stated
- Activation:applies on nodes running v0.5.10 or later; sequencer adoption date not confirmed
Sources: BNB Chain (GitHub) — op-geth v0.5.10 release notes (external site) · BNB Chain (GitHub) — bnb-chain/op-geth releases Atom feed (external site)
-
Osaka/Mendel hard fork announced for 28 April 2026
BNB Chain announced the Osaka/Mendel hard fork, nine BEPs combining six Ethereum improvements with BNB Chain changes. It caps gas per transaction at 16,777,216, caps block size, adds a count-leading-zeros opcode, adjusts some gas costs, limits blob transactions, speeds fast-finality voting with an in-memory vote pool and adds an eth_config RPC method. The docs mark it enabled on mainnet from 28 April 2026 at 02:30 UTC.
- Proposal:BEP-658 meta proposal including BEP-652
- Implementation:shipped in client v1.7.2
- Release:mandatory mainnet release
- Activation:enabled on mainnet 2026-04-28 02:30 UTC
Sources: BNB Chain Blog — Osaka/Mendel Hard Fork: Strengthening BNB Chain After Sub-Second Speed Gains (external site) · BNB Chain Docs — Mendel Upgrade of BSC (external site) · BNB Chain (GitHub) — bsc v1.7.2 (Osaka/Mendel hardfork) (external site) · BNB Chain Blog — BNB Chain H2 2026 Tech Roadmap: Doubling Down on Speed (external site)
-
Osmosis approved, and the Cosmos Hub rejected, a plan to move Osmosis onto the Hub
Osmosis proposal 1007 passed on 14 April 2026. It proposed redeploying the Osmosis exchange onto the Cosmos Hub, ending OSMO inflation and offering a one-year optional OSMO-to-ATOM conversion. The matching Cosmos Hub proposal 1029 was rejected on 16 April 2026. The plan stated nothing would be implemented unless both chains approved.
- Proposal:passed on Osmosis; rejected on the Cosmos Hub
- Implementation:not implemented
- Release:no release
- Activation:not active
Sources: Osmosis on-chain state via Osmosis public REST endpoint — Osmosis proposal 1007: Integration and Migration of Osmosis into the Cosmos Hub (on-chain record) (external site) · Cosmos Hub on-chain state via PublicNode REST endpoint — Cosmos Hub proposal 1029: Acquisition and Merger of Osmosis into the Cosmos Hub (on-chain record) (external site) · Cosmos Hub on-chain state via PublicNode REST endpoint — Cosmos Hub governance proposals, newest 80 (on-chain query) (external site)
-
Node v0.21.0 scheduled RANDAO leader randomness and a deposit contract upgrade
Zilliqa released node version 0.21.0 with a mainnet hard fork: the deposit_v8 staking contract upgrade at block 25,902,000 and RANDAO randomness for leader selection at block 25,905,600, both estimated for 5 May 2026. The release also adds state pruning and flexible checkpoint versions.
- Implementation:shipped in zq2 v0.21.0
- Release:required upgrade
- Activation:scheduled for blocks 25,902,000 and 25,905,600 (estimated 2026-05-05); listed in the v0.21.10 mainnet specification
Sources: Zilliqa (GitHub) — zq2 v0.21.0 release notes (external site) · Zilliqa (zq2 repository, GitHub) — zq2-mainnet chain specification at tag v0.21.10 (external site) · Zilliqa (zq2 repository, GitHub) — deposit_v8.sol at tag v0.21.10 (external site)
-
DFINITY documented cloud engines, operator-configured subnets
An Internet Computer wiki article dated 15 April 2026 describes cloud engines: subnets an operator configures by choosing node providers from a marketplace, filtering by jurisdiction, hardware and uptime, and setting a replication level, while running the same protocol, canisters and cycles model as public subnets. The project home page now advertises configuring private cloud engine subnets.
- Implementation:documented by DFINITY; setup is directed to opencloud.org
- Release:not confirmed
- Activation:live use not verified
Sources: Internet Computer Wiki — Cloud engines (external site) · Internet Computer (internetcomputer.org) — Internet Computer (external site) · dfinity/ic maintainers — NNS governance changelog (external site)
-
Official Python SDK adds support for priority fees
Release 0.23.0 of Hyperliquid's official Python SDK added priority-fee support. The docs describe two mechanisms: auctions on a three-minute cycle for earlier delivery of network data to a chosen IP address, and per-order fees that speed up immediate orders or improve queue position for post-only orders. All priority fees are burned.
- Implementation:documented and supported in the official SDK
- Release:SDK 0.23.0 released
- Activation:live per current docs; activation date not confirmed
Sources: hyperliquid-dex (GitHub) — hyperliquid-python-sdk 0.23.0 (external site) · Hyperliquid Docs — Priority fees (external site) · hyperliquid-dex (GitHub) — node commit f4b32f9: document node priority gossip config (external site)
-
Node 1.6.2 put deterministic finality to a mainnet producer vote
Waves node 1.6.2 brought feature 25, Deterministic Finality, to mainnet voting together with P-256 signature verification, and it requires Java 17. Once active, committed producers with a 100 WAVES deposit endorse blocks, and a block endorsed by two-thirds of the committed generating balance cannot be rolled back. On 27 September 2026 the node API still showed the feature in voting, with 3,007 of the 8,000 supporting blocks needed in the current window.
- Proposal:released for mainnet voting
- Implementation:implemented in node 1.6.2 and later
- Release:node 1.6.2 released 2026-04-14
- Activation:not activated as of 2026-09-27; missed the height 5,200,000 activation target named in the release and was still in voting
Sources: wavesplatform on GitHub — Waves node v1.6.2 release notes (external site) · Waves documentation (docs.waves.tech) — Waves: Block Finality (external site) · Waves public node pool (nodes.wavesnodes.com) — Waves mainnet feature activation status (node REST API, read at height 5,419,632) (external site) · Waves documentation (docs.waves.tech) — Release Notes (external site)
-
Fraxtal nodes moved from op-geth to Frax's op-reth fork
Frax's mainnet node release of 13 April 2026 replaced the op-geth execution client with Frax's fork of op-reth, ahead of upstream op-geth's deprecation on 31 May 2026. A follow-up release published on 26 April 2026 added new bootnodes to speed up first sync and was marked strongly recommended.
- Implementation:Released
- Release:mainnet-20260413 and mainnet-20260425 node releases
- Activation:operator upgrade; no hard fork
Source: Frax Finance on GitHub — fraxtal-node releases (external site)
-
Scroll proposed ending its Security Council in favor of a Scroll admin multisig
A Scroll-led forum post proposed dissolving the independent Security Council and moving protocol admin control to a Scroll admin multisig, citing cost relative to use, and wound down four DAO contributor roles. L2BEAT records the change as executed on 1 June 2026, with a 3-of-4 team multisig replacing the 9-of-12 council.
- Proposal:Scroll-led proposal posted 2026-04-13
- Implementation:executed on Ethereum on 2026-06-01 according to L2BEAT
- Release:governance change; no software release
- Activation:active according to L2BEAT
Sources: Scroll Governance Forum — Governance Update: Security Council Transition, Contributor Roles & Operational Adjustments (external site) · L2BEAT — Scroll (external site)