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 3 of 14.
One chain's developments, A to Z
-
Arweave 2.9.6 ends acceptance of format 1 transactions from height 2,000,000
Arweave node 2.9.6 proposes a soft fork that ends the grace period for format 1 transactions, deprecated since April 2020, from block height 2,000,000, estimated for 13 September 2026 at 12:00 UTC. The notes say format 1 now makes up about 0.007% of base-layer interactions and complicates the node's transaction handling; after the activation height, blocks that include a format 1 transaction are not accepted by upgraded peers.
- Proposal:proposed in the 2.9.6 release notes as a soft fork
- Implementation:shipped in N.2.9.6 and carried in the 2.9.7-alpha1 build
- Release:stable release published 2026-09-07
- Activation:scheduled at height 2,000,000; the network passed that height by 2026-09-29, but enforcement across miners was not verified
Sources: ArweaveTeam (GitHub) — Arweave 2.9.6 release notes (external site) · ArweaveTeam (GitHub) — Arweave 2.9.7-alpha1 release notes (external site) · arweave.net gateway — arweave.net /info network read (external site)
-
EF Protocol published Hegotá priorities and an opinionated EIP tier list
The Ethereum Foundation Protocol cluster published its priorities and evaluated 62 EIPs proposed for Hegotá. It described FOCIL and Frame Transactions as its headliner commitments and documented a maturity pipeline from research through EIP, prototype, devnet and inclusion stages to Mainnet. This is protocol scoping input from one coordinating cluster; it is not final fork scope, a client release or network activation.
- Type:Roadmap
- Proposal:Proposed ef protocol scoping input
- Release:Research and scoping publication
- Activation:Not activation
Sources: Ethereum Foundation Protocol Cluster — EF Protocol: The Hegotá EIP Opinion Post and Tier List (external site) · Ethereum Foundation Protocol Cluster — EF Protocol: Current and Emerging Priorities (external site)
-
Ronin withdrawals switched back from Kailua ZK proofs to a permissioned game
An Ethereum transaction on 7 September 2026 set Ronin's withdrawal contracts back to the permissioned dispute game, about two months after Boundless Kailua zero-knowledge proofs were enabled in early July 2026 (L2BEAT links a transaction dated 1 July). L2BEAT reports that the permissioned game's proof program cannot execute Ronin's state, so security now rests on the permissioned proposer.
- Implementation:executed on Ethereum
- Release:mainnet contracts
- Activation:permissioned game active since 2026-09-07; reason not published in reviewed sources
Sources: Etherscan — Ethereum transaction switching Ronin withdrawals to the permissioned game (external site) · Etherscan — Ethereum transaction enabling Kailua proofs for Ronin (external site) · L2BEAT — Ronin (external site)
-
Node 7.3.0 released with the Arcus protocol upgrade built in but not yet scheduled
Aeternity node 7.3.0 adds code for Arcus, protocol version 7, which charges contract storage reads in proportion to the size of the value read. It also brings performance work, an endpoint listing consensus parameters, and a database format change that prevents downgrading. The release says Arcus is not enabled on mainnet and its switch height will be announced in a future release. Version 8 (Salus) is reserved as a placeholder for Hyperchains, which remain experimental.
- Proposal:defined in node code; activation height to be announced
- Implementation:implemented in node 7.3.0
- Release:released 2026-09-06
- Activation:not active; mainnet reported protocol version 6 on 2026-09-27
Sources: aeternity/aeternity releases on GitHub — Aeternity node v7.3.0 (external site) · aeternity/aeternity pull requests on GitHub — Size-proportional FATE store-read gas at Arcus (v7), plus Salus (v8) placeholder (external site) · Aeternity public mainnet node (mainnet.aeternity.io) — Aeternity mainnet protocol parameters (read on 2026-09-27) (external site)
-
Release v9.7 moves settled isolated-market insurance funds into the main fund and narrows what governance can transfer
protocol/v9.7.0 is a governance-scheduled upgrade from v9.6.4. At the upgrade, insurance fund balances of isolated markets that had already reached final settlement move into the main cross-market insurance fund, and later isolated-market settlements do this automatically. It removes MsgSendFromAccountToAccount, a governance-only transfer message added in v9.5 that the developers say no proposal ever used. It also stops governance-set transfers, vesting and rewards from drawing on the staking pools or the module account that holds subaccount collateral. The dYdX Operations subDAO proposed block 105,000,000 on 11 September 2026, and a validator reported submitting the vote as proposal 395.
- Proposal:forum draft 6 September 2026; a validator reported on-chain proposal 395 on 7 September; vote result not read in this pass
- Implementation:changes merged 3 September 2026 (pull requests 3384 and 3386) with a v9.7 upgrade handler
- Release:released as protocol/v9.7.0 on 6 September 2026, after a release candidate on 5 September
- Activation:not confirmed on-chain in this pass; planned for block 105,000,000 on 11 September 2026; chain registry recommended v9.7.0 on 27 September 2026
Sources: dydxprotocol maintainers — protocol/v9.7.0 release notes (external site) · dydxprotocol maintainers — Pull request 3389: Backport v9.7 changes to release/protocol/v9.x (external site) · dydxprotocol maintainers — Pull request 3384: Sweep isolated insurance funds to the cross insurance fund and remove MsgSendFromAccountToAccount (external site) · dydxprotocol maintainers — Pull request 3386: Block protected module accounts as transfer sources in sending, vest, and rewards (external site) · dYdX Community Forum (post by dYdX Operations subDAO) — [DRC] Proposal for dYdX Protocol Upgrade to v9.7 (external site) · Cosmos chain-registry maintainers — dYdX chain registry record (external site)
-
Governance paused uploading and creating new contracts
Proposal 370 used the chain's circuit breaker to switch off uploading new contract code and creating new contract instances, citing a CosmWasm security disclosure. Existing contracts, IBC transfers and wrapping of existing tokens keep working. The switch can be reversed by a later governance action.
- Proposal:passed on chain
- Implementation:circuit breaker active
- Release:no software release required
- Activation:in effect at review; no end date set
Sources: Secret Network governance (public REST endpoint) — Proposal 370: Pause new contract uploads and instantiations (external site) · Lavender.Five Nodes public endpoint — Circuit breaker disabled messages (public REST endpoint) (external site)
-
Security fixes in Mainnet runtimes 14 to 16 were deployed before their source was published
After a community member disclosed three security issues (the two post-mortems date their reports to 20 July 2026), Acurast deployed Mainnet runtimes 14, 15 and 16 and then published their source as releases v0.26.3 to v0.26.5. The fixes stopped a double payout of delegation rewards, closed a replay path in the Canary-to-Mainnet conversion, deactivated and then removed the Hyperdrive job-messaging pallet, reduced the conversion pallet to unlocking only, upgraded the Polkadot SDK and hardened attestation checks. Acurast published post-mortems and says it has returned to publishing code before votes.
- Proposal:not itemized; Acurast says it deployed the fixes before publishing their source, reversing its usual order of publishing code before a governance vote, and names no referenda
- Implementation:shipped in acurast-substrate v0.26.3, v0.26.4 and v0.26.5 (Mainnet runtimes 14, 15 and 16)
- Release:source published 2026-09-02
- Activation:deployed on Mainnet before 2026-09-02 according to Acurast; exact enactment blocks not verified
Sources: Acurast blog — Acurast Security Protocol Upgrades (external site) · Acurast (GitHub) — acurast-v0.26.3 release notes (Mainnet Runtime 14) (external site) · Acurast (GitHub) — acurast-v0.26.4 release notes (Mainnet Runtime 15) (external site) · Acurast (GitHub) — acurast-v0.26.5 release notes (Mainnet Runtime 16) (external site) · Acurast Docs — Post mortem: Acurast Compute, double claiming of staking rewards (external site) · Acurast Docs — Post mortem: Acurast Token Conversion, replay of conversion messages (external site)
-
HIP 150 approved: 80% target minimum, deployer pool at 94% and per-Hotspot multipliers
Helium announced that veHNT holders approved HIP 150 and that it applies from 31 August 2026. It raises the Mobile target minimum from half to 80% of what payers pay for rewardable data for one year, with a second year pre-authorized; mints the HIP 149 top-up straight into the deployer data pool; moves Nova Labs' Service Provider share into that pool, taking it from 70% to 94% until 31 July 2027; and allows per-Hotspot multipliers of up to 5, granted by Nova Labs.
- Proposal:HIP 150 approved by veHNT vote; HIP index status Approved
- Implementation:oracle release 4.6.0 (HIP-150) published 2026-08-31
- Release:announced by Helium on 2026-09-04
- Activation:applies from 31 August 2026 per Helium's post; the HIP index does not yet mark it deployed
Sources: Helium blog — HIP-150: Higher Earnings for Deployers, Premium Rates for High-Demand Venues (external site) · Helium (HIP repository) — HIP 150: Mobile Deployer Prioritization (external site) · Helium governance (hiptron gist linked from HIP 150) — HIP-150 vote summary (external site) · Helium (GitHub) — helium/oracles release 4.6.0 (HIP-150) (external site) · Helium (HIP repository) — Helium Improvement Proposals: index and status table (external site)
-
Mainnet configuration scheduled Supernova for epoch 2233; it activated on 10 September 2026, cutting rounds from 6 seconds to 0.6 seconds
The mainnet configuration release v2.0.6.0 set Supernova to activate at epoch 2233. That epoch began on 10 September 2026, and the configuration changes the round duration from 6,000 to 600 milliseconds from it, with 144,000 rounds per epoch. Supernova has validators vote on a block before executing it and records execution results in later headers. It had been approved by an on-chain vote in January 2026, according to MultiversX.
- Proposal:MIP-27 proposed August 2025; approved by on-chain vote in January 2026 according to MultiversX
- Implementation:node v2.0.x
- Release:mainnet configuration v2.0.6.0 released 2026-09-04
- Activation:active from epoch 2233 (10 September 2026) per mainnet configuration and live network data
Sources: multiversx/mx-chain-mainnet-config repository — mx-chain-mainnet-config v2.0.6.0 (external site) · multiversx/mx-chain-mainnet-config — Mainnet config.toml (v2.1.5.0) (external site) · MultiversX public gateway — Mainnet gateway network configuration (external site) · MultiversX Agora forum — MIP-27: Supernova - Sub-second Finality (external site) · MultiversX Docs — Preparing SCs for Supernova (external site) · MultiversX Docs — Terminology (external site)
-
Taiko released version 2.18.0 of its bridge web interface with fixes from an audit
Release 2.18.0 of the bridge interface in Taiko's main repository ships fixes that the underlying pull request says came from an in-depth audit of the app. Examples it lists: releasing funds from a failed bridge message could error indefinitely in the interface whenever the source chain was ahead of the destination's synced height; the server-side NFT lookup could return another user's NFTs; a temporary polling error could drop pending transactions from local history; and ERC-20 amounts could show with the wrong decimals. The release also corrects rounding in manual relayer fee estimates, fixes how relayer claims are matched to on-chain records, and gives a clearer message when a claim or retry is blocked by a bridge quota.
- Implementation:fixes merged in taiko-mono pull requests between 2026-07-03 and 2026-09-03
- Release:bridge-ui v2.18.0 published on GitHub 2026-09-04
- Activation:deployment to bridge.taiko.xyz not confirmed; the latest mainnet-labelled bridge interface tag found (v3.0.6) is dated 2026-08-21, before this release
Sources: Taiko contributors (GitHub) — bridge-ui: v2.18.0 (external site) · Taiko contributors (GitHub) — fix(bridge-ui): perform a total refactor of the bridge app with many fixes (external site) · Taiko contributors (GitHub) — feat(bridge-ui): check if retry failed is wrapped quota error (external site) · Taiko contributors (GitHub) — bridge-ui-mainnet-v3.0.6 (external site) · Taiko contributors (GitHub) — taikoxyz/taiko-mono releases (Atom feed) (external site)
-
Etherlink 7.0 (Ganesha) added a Michelson interface and cross-interface calls
Etherlink's 7.0 kernel, Ganesha, went live on 21 August 2026 after bakers approved it. It added a Michelson runtime next to the EVM on Etherlink and native atomic composability, letting EVM and Michelson contracts call each other in one all-or-nothing transaction. Bakers were asked to reject the first proposal after a vulnerability was found in testing, and a patched kernel then passed through the fast governance track.
- Proposal:approved by Tezos bakers through Etherlink fast governance after a first proposal was rejected
- Implementation:kernel 7.0 deployed
- Release:requires octez-evm-node 0.64 or later
- Activation:live on Etherlink mainnet since 2026-08-21
Sources: Tezos Commons on Tezos Spotlight — Month At A Glance: August 2026 (external site) · Etherlink documentation — Kernel upgrades (external site) · Etherlink documentation — Etherlink's architecture (external site) · Nomadic Labs on Tezos Spotlight — Announcing Ganesha: A 7th Upgrade Proposal for Etherlink Mainnet (external site)
-
Matter Labs announced a transition retiring EraVM, to begin within six months, with new security measures
Matter Labs said that within the next six months ZKsync Era and other EraVM chains will begin a transition that retires the EraVM execution environment; it named no replacement or end date. Regular wallets need no action for now, while funds held in contracts will need action, with exact steps and dates promised in the coming weeks. It also announced security measures: a recommended 24-hour execution delay, independent second nodes confirming batches, publishing covered Era protocol code three months after each upgrade ships, emergency upgrades renamed instant upgrades, and a second proving system still subject to testing and audit.
- Proposal:announced by Matter Labs; migration steps and dates still to be published
- Implementation:security measures announced, several of them recommendations that each chain decides on; replacement for EraVM not named
- Release:no release for the retirement yet
- Activation:not active; the transition is to begin within six months of 2026-09-04, with no end date given
-
ZIP-17 proposed letting EraVM chains raise their execution delay to 24 hours
A Matter Labs author posted ZIP-17, which updates the validator timelock contract so each EraVM chain can raise its execution delay from 3 hours to 24 hours. Chains that keep the 3-hour default are unaffected. The proposal text also gives a 7-day maximum; L2BEAT's governance team said on 17 September that it voted in favour, and noted that the implementation allows delays of up to 30 days.
- Proposal:ZIP-17 posted 2026-09-04; L2BEAT's delegate team reported voting for it on 2026-09-17; final result not confirmed
- Implementation:updated validator timelock contract deployed at the address in the proposal
- Release:governance change; no software release
- Activation:not confirmed for Era; L2BEAT still showed a 3-hour delay at review time
Sources: ZK Nation Forum — [ZIP-17] Increase Execution Delay for EraVM ZK Chains (external site) · L2BEAT — ZKsync Era (external site)
-
Mainnet halt after a faulty emergency runtime upgrade, and the Technical Committee's recovery
Avail's incident report says that on 31 August 2026 an emergency runtime upgrade for a privately reported vulnerability, applied at block 3,403,608, broke production of the next epoch-transition block. Block production stopped for about three hours and 45 minutes until validators ran an earlier runtime through an override (release 2.3.6.0-hotfix). Slashing during the halt changed the validator set and stalled finality until 04:58 UTC on 1 September. Transparency Report 21 lists the emergency proposals: slashes cancelled, the set cut to 10 and then 15, and the earlier runtime and then a corrected one applied on chain.
- Proposal:emergency Technical Committee proposals, starting with proposal 44
- Implementation:runtime override for validators; earlier runtime v55, then corrected runtime v56, applied on chain; code substitute in node v2.4.0.0
- Release:hotfix published 2026-08-31, node v2.4.0.0 on 2026-09-02, reports on 2026-09-03
- Activation:block production and finality restored by 1 September 2026; validator set still being rebuilt at the time of the reports
Sources: Avail Project (GitHub governance repository) — Avail DA Mainnet Incident Report (Mainnet Liveness and Finality Incident) (external site) · Avail Project (GitHub governance repository) — Transparency Report 21: Technical Committee Actions During Mainnet Recovery (external site) · Avail Project (GitHub) — Avail Validator Hotfix 2.3.6.0-hotfix (external site) · Avail Project (GitHub) — Avail node v2.4.0.0 release notes (external site) · Avail Project (GitHub) — Avail DA mainnet chain specification (raw) (external site)
-
Mesa hard fork activated on Mina mainnet
o1Labs published the Mesa mainnet release on 3 September 2026, completing the scheduled hard fork. Mesa halves slot time to 90 seconds and the per-block coinbase to 360 MINA. It raises zkApp on-chain storage from 8 to 32 fields, raises event, action and account-update limits, and adds automated hard-fork tooling.
- Proposal:MIP6 to MIP9 approved in the December 2025 on-chain vote
- Implementation:implemented in Mina daemon 4.0.0
- Release:mainnet release 4.0.0-mainnet-mesa published 2026-09-03
- Activation:active on mainnet per o1Labs release notes and blog
Sources: MinaProtocol/mina maintainers (o1Labs) — Mina Mainnet Stable 4.0.0 Mesa Release (external site) · Mina Protocol blog (o1Labs) — Welcome to Mesa: Mina's Latest Upgrade (external site) · Mina documentation — Mesa Upgrade Glossary (external site) · Mina documentation — Mesa Upgrade: Requirements (external site) · Mina Protocol blog (o1Labs) — Mina's Mesa Upgrade: What to Expect (external site) · Mina documentation — Mesa Fork Schedule (external site)
-
nearcore 2.13.4 security release
nearcore 2.13.4 included a critical denial-of-service fix. Its notes did not announce a protocol upgrade, so node-release and protocol-version status remain separate.
- Implementation:Released
- Release:Stable
- Activation:Not applicable to protocol version
-
Interstellar upgrade aligned VeChainThor's contract engine with Ethereum's Cancun, Prague and Osaka rules
Thor v2.5.0 was released as a mandatory upgrade activating the Interstellar hard fork (VIP-255) at mainnet block 25,902,540. It adds transient storage, memory copy and leading-zero opcodes, restricts SELFDESTRUCT, adds BLS12-381 curve and secp256r1 signature-verification precompiles and a historical block-hash contract, caps a single transaction at 16,777,216 gas and limits encoded blocks to 8 MiB. VeChain announced the VeVote ballot for VIP-255 on 6 August 2026, with voting from 10 to 17 August.
- Proposal:VIP-255, marked Draft in the VIP repository; put to a VeVote ballot 10 to 17 August 2026
- Implementation:shipped in Thor v2.5.0
- Release:mandatory release published 2026-09-03
- Activation:mainnet passed fork block 25,902,540 on 2026-09-16
Sources: vechain/thor maintainers — Thor v2.5.0 release notes (Interstellar hardfork) (external site) · VeChain VIPs repository — VIP-255: Interstellar EVM Upgrade Specification (external site) · VeChain — VeChain Renaissance: Interstellar Sets Course (external site) · VeChain (public node, Thorest API) — Mainnet block 25,902,540 (Interstellar fork height) (external site)
-
BB reissued on BNB Smart Chain; Bitget completes its 1:1 swap
BB was reissued 1:1 as a BEP-20 token on BNB Smart Chain against balances at block 20,697,260. Reports of BounceBit's plan say addresses holding 10 BB or more receive it automatically at the same address, with smaller balances left for a later claim portal. Bitget announced its 1:1 swap on 1 September 2026 and said on 2 September that the swap was complete and BEP-20 BB deposits and withdrawals had reopened.
- Implementation:reissued BB deployed on BNB Smart Chain
- Release:exchange swaps announced 1 September and completed at Bitget on 2 September 2026
- Activation:automatic distribution reported; completion for every eligible address and the small-balance claim portal not confirmed
Sources: Bitget — Bitget Will Support the BounceBit (BB) Contract Swap (external site) · Bitget — Bitget Has Completed the BounceBit (BB) Contract Swap (external site) · CryptoSlate — Chain shutdown strips BounceBit token utility after authorization flaw exposes 286M tokens (external site) · Crowdfund Insider — Bitcoin Restaking Platform BounceBit To Wind Down L1 Blockchain Following Exploit (external site)
-
Validator-only release v1.7.9 follows the 30 August halt and rollback
After an exploit of the Tectonic lending app, Cronos EVM validators halted block production on 30 August 2026 and restarted the chain from the state before the exploit, discarding 10,961 blocks (about 1 hour 54 minutes). On 2 September the project published v1.7.9, a validator-only release to restore consensus consistency following the rollback.
- Implementation:rollback executed by validator coordination on 2026-08-30
- Release:v1.7.9 pre-release for validators published 2026-09-02
- Activation:block production resumed at height 90,896,190 at 23:49 UTC on 2026-08-30, per the chain's block record
Sources: crypto-org-chain/cronos maintainers — Cronos v1.7.9 release notes (external site) · crypto-org-chain/cronos issue tracker — Post-rollback: mempool checkState desync across RPC nodes (issue 2200) (external site) · The Block — Cronos says $9.2 million remains unrecovered after Tectonic exploit, chain rollback (external site) · CoinDesk — Cronos erases two hours of transactions to recover $111M in Tectonic hack (external site) · Cronos public REST endpoint — Cronos EVM block 90,896,190 (REST endpoint) (external site) · Cronos public REST endpoint — Cronos EVM validators, all statuses (REST endpoint) (external site)
-
Optimism governance transferred Mode's admin keys to Conduit
An Optimism maintenance upgrade proposal moved ownership of Mode's Ethereum-side admin contract, dispute-game factory and Mode-side admin contract from an Optimism-controlled safe to a Conduit safe, ending Optimism governance of Mode. L2BEAT records the change as executed on 16 September 2026 and now lists a 4-of-11 Conduit multisig that can upgrade the contracts instantly.
- Proposal:maintenance upgrade proposal posted 2026-09-02 under the standard veto period
- Implementation:ownership transferred, per L2BEAT
- Release:not a software release
- Activation:active since 2026-09-16, per L2BEAT
Sources: Optimism Collective governance forum — Maintenance Upgrade Proposal: Mode, Metal, Zora, and Dust Ownership Transfer to Conduit (external site) · L2BEAT — Mode Network (external site)
-
Node templates v1.1.0 move to consensus 1.1.0 and set mainnet Aquila committee rotation
Plasma released node templates v1.1.0, which update the PlasmaBFT consensus client to 1.1.0 and add the Aquila settings for testnet and mainnet: a committee rotation read from a contract, with 20,000-block epochs and a set activation height. The release also disables vote fanout.
- Implementation:shipped in node templates v1.1.0 with consensus client 1.1.0
- Release:released 2026-09-02
- Activation:configured mainnet activation height passed per a 2026-09-29 block-height read; rotation behaviour not observed directly
Sources: Plasma (PlasmaLaboratories, GitHub) — node-templates v1.1.0 release (external site) · Plasma (PlasmaLaboratories, GitHub) — feat: Mainnet Aquila activation (pull request 25) (external site) · Plasma (PlasmaLaboratories, GitHub) — config/mainnet/non-validator.toml (node templates) (external site) · Plasma (PlasmaLaboratories, GitHub) — Plasma Node Templates README (external site) · Plasma — Plasma public RPC (eth_blockNumber read) (external site)
-
USDT0 launched on Stellar
The Stellar Development Foundation announced that USDT0, a token backed one-to-one by USDT locked on Ethereum and moved with LayerZero, is live on Stellar, naming SushiSwap and several wallets and exchanges as supporting it. USDT0's own deployment list includes a Stellar token contract and a matching classic asset.
- Implementation:Stellar deployment listed in USDT0 contract documentation
- Release:announced live
- Activation:live per announcement; partner availability not independently verified
Sources: Stellar Development Foundation — USDT0 is now live on Stellar (external site) · Stellar Development Foundation — Stellar blog (external site) · USDT0 — USDT0 Contract Deployments (external site) · USDT0 — USDT0 Technical Documentation (external site) · Tether — Supported protocols (external site)
-
Octez 25.2 released: security hardening for nodes and data-availability nodes
Octez 25.2, a maintenance release of the Tezos reference node software, was published on 2 September 2026. Its release notes say the node now rejects ill-formed operations before applying them and rejects too deeply nested Micheline values early in parsing. The data-availability (DAL) node now limits the memory and processing it spends on peer-to-peer traffic, and an unresponsive DAL node no longer holds up a baker's proposing and attesting. The release ships bakers for the Tallinn and Ushuaia protocols. With it, the Octez team marked its GitLab release pages as deprecated and moved release announcements to octez.tezos.com/releases.
- Implementation:implemented in Octez 25.2
- Release:released 2026-09-02
- Activation:takes effect when each operator installs it; no network activation
Sources: Octez and Tezos protocol documentation — Version 25 release notes (external site) · Tezos project on GitLab (tezos/tezos) — Octez Release 25.2 - GitLab Releases Deprecated, See octez.tezos.com/releases/ (external site) · Octez (Tezos reference implementation) — Octez releases (external site) · Octez (Tezos reference implementation) — Octez (releases RSS feed) (external site)
-
Legacy balances move to EVM addresses by hard fork and zero-knowledge escrow
On 2 September 2026 a hard fork moved the balances of ten exchanges from legacy addresses to their EVM addresses and blocked the old ones. Node v0.21.9 (8 September) scheduled a second account sweep, an escrow contract and an escrow-only rule for legacy transfers; the chain reached that fork height on 22 September, and on 24 September Zilliqa published a guide to its ZKP Migration App for self-custody holders. Zilliqa also said it would put a proposal to mint new ZIL for affected holders to a community vote.
- Proposal:compensation mint proposed for a community vote; not yet posted
- Implementation:exchange sweep forks and escrow contract in the node; migration app released
- Release:zq2 v0.21.9 and ZKP Migration App v0.6.0 released
- Activation:first exchange batch moved 2 September 2026; second sweep and escrow fork reached 22 September 2026 (block 36,383,378); third list (block 37,410,000) not reached by 29 September
Sources: Zilliqa blog — Where We Stand: Migration Progress, the Path to Compensation, and Getting Back to Building (external site) · Zilliqa (GitHub) — zq2 v0.21.9 release notes (external site) · Zilliqa blog — Migrate ZIL from a Legacy account to Zilliqa EVM (external site) · Zilliqa (GitHub) — zkp_recovery_app releases (ZKP Migration App) (external site) · Zilliqa — Zilliqa Governance forum (external site) · Zilliqa — Zilliqa mainnet public API (JSON-RPC read of block 36,383,378 on 2026-09-29) (external site)
-
Optimism governance transferred Zora Network's admin keys to Conduit
An Optimism maintenance upgrade proposal moved ownership of Zora Network's Ethereum-side admin contract, dispute-game factory and Zora-side admin contract from an Optimism-controlled safe to a Conduit safe, ending Optimism governance of Zora. L2BEAT records the change as executed on 16 September 2026 and now lists a 4-of-11 Conduit multisig that can upgrade the contracts instantly.
- Proposal:maintenance upgrade proposal posted 2026-09-02 under the standard veto period
- Implementation:ownership transferred, per L2BEAT and a read of the Ethereum contracts
- Release:not a software release
- Activation:active since 2026-09-16, per L2BEAT
Sources: Optimism Collective governance forum — Maintenance Upgrade Proposal: Mode, Metal, Zora, and Dust Ownership Transfer to Conduit (external site) · L2BEAT — Zora Network (external site)
-
Provable opened early access to Shield Swap on Aleo
Provable opened early access to Shield Swap, an exchange on Aleo that keeps trader identities and portfolios confidential while pool reserves, prices, trade sizes and fees stay public. It listed USDCx, wrapped Bitcoin, ETH, SOL and ALEO, and Provable expects a public launch in the fourth quarter of 2026.
- Implementation:early access open
- Release:public launch expected in Q4 2026
- Activation:early access at review
Sources: Aleo — Provable opens early access to Shield Swap on Aleo (external site) · Shield — Shield Swap (external site)
-
Base node development and releases moved to base/base
The v1.3.0 release moved the public node image to the base/base repository. The older base/node repository is archived and directs new installations and upgrades to base/base, so release monitoring should follow the new repository.
- Type:Release
- Proposal:Not applicable
- Release:Released
- Activation:Repository migration observed
Sources: Base contributors — Base v1.3.0 (external site) · Base contributors — base/node repository (external site)
-
BNB Chain announced BSC Payment Lane for Q4 2026
BNB Chain described a planned reserved-blockspace floor for payments: native BNB transfers, USDT and USDC transfers and governance-approved tokens would get a minimum share of block gas that grows during congestion and shrinks as demand falls. Priority fees would still order transactions, and validators are to vote on the reserve size and thresholds before launch.
- Proposal:announced design; parameters pending a validator vote
- Implementation:not observed
- Release:planned for Q4 2026
- Activation:not active at review
Source: BNB Chain Blog — BSC Payment Lane: Reserved Blockspace That Keeps Payments Moving (external site)
-
Emergency hard fork fixed a validator reward exploit on 3 September 2026
In late August 2026 some Core validators credited block rewards more than once through a system contract that had no per-block limit. On 1 September Core committed a contract fix and released client v1.0.24 scheduling a mainnet hard fork; v1.0.25 limited zero-fee transactions to system contracts and v1.0.26 moved activation to 13:00 UTC on 3 September. A news report citing Core says about 255 million CORE was released early, about 186 million was removed from affected addresses at the fork and about 69 million had already moved elsewhere.
- Implementation:system-contract fix committed; client releases v1.0.24 to v1.0.26 published
- Release:emergency mainnet hard-fork release
- Activation:scheduled for 2026-09-03 13:00 UTC; a news report says it activated at block 38,376,795; not checked on-chain
Sources: Core DAO (GitHub) — ValidatorSet per-block reward guard (core-genesis-contract commit fb35c941) (external site) · Core DAO (GitHub) — core-chain v1.0.24 (mainnet validator upgrade) (external site) · Core DAO (GitHub) — core-chain pull request 98: network upgrade v1.0.25 (external site) · GitHub — core-chain pull request 99 (v1.0.26) changed files (GitHub API) (external site) · Cointelegraph — Core DAO plans hard fork over excess validator rewards (external site) · The Crypto Times — Core DAO fixes reward exploit, claws back 186M CORE (external site)
-
Ergo reference node 6.0.5 released, with a RocksDB prerelease 6.1.5
The Ergo reference client 6.0.5 checks NiPoPoW proof parameters and the proof of work in proof headers, rejects invalid NiPoPoW parameters from inbound peers, caps outbound buffering per peer and closes all live connections from blacklisted IP addresses. It also fixes fee-estimation bounds and a wallet case where a burn request placed before a token issuance made transaction building fail, and lets the extra indexer resume catch-up without a full reindex. 6.1.5, published as a prerelease the same day, is the same code on a RocksDB database backend.
- Implementation:Released
- Release:6.0.5 published 2026-09-01; the RocksDB build 6.1.5 was published as a prerelease the same day; superseded by 6.0.6 on 2026-09-21
- Activation:not a consensus change; applies to each node once installed
Sources: Ergo Platform (GitHub) — Ergo protocol reference client 6.0.5 (external site) · Ergo Platform (GitHub) — Ergo protocol reference client 6.1.5 (external site) · ErgoDocs (Ergo Platform) — Non-interactive Proof-of-Proof-of-Work (NIPoPoWs) (external site)
-
Flow Foundation responded to an exploit of Ankr's ankrFLOW contract
Flow said a flaw in Ankr's ankrFLOW contract on Flow EVM let an attacker mint about 8.6 million unbacked ankrFLOW on 31 August and use them as collateral to drain roughly 15.5 million WFLOW from MORE Markets. Ankr and MORE Markets paused the contracts, and the Foundation said it would replace the drained reserve.
- Implementation:affected contracts paused
- Release:no protocol release involved
- Activation:replacement of funds announced
Source: Flow Foundation — Statement on the Ankr Liquid Staking Exploit (external site)
-
System-chain runtime 2.4.0 enacted: peg stability modules on Polkadot Hub and Bulletin chain storage
Referendum 1937 upgraded Polkadot's system chains to Fellowship runtime 2.4.0, and Referendum 1938 did the same for the Bulletin chain. The release lets Polkadot Hub run several independent peg stability modules for stablecoin issuance, each created by the asset's owner or by Root with a fixed 100 DOT deposit and accepting up to five external assets. It also gives the Bulletin chain the storage logic that lets authorized accounts store data within their allowances, raises the People chain's block weight limit and fixes under-priced XCM weights.
- Proposal:Referenda 1937 (system chains) and 1938 (Bulletin chain) executed on 2026-09-01 after Fellowship whitelisting
- Implementation:implemented in Fellowship runtimes 2.4.0 (spec version 2004000)
- Release:released 2026-08-26
- Activation:active on Polkadot Hub by 18:51 UTC on 2026-09-01; the People, Bulletin and other system chains were not checked
Sources: Polkadot Fellowship (GitHub) — Runtimes 2.4.0 (external site) · Polkadot Forum — Runtime release notification for v2.4.0 [28.08.2026] (external site) · Subsquare (Polkadot OpenGov) — Referendum 1937: Upgrade System Chains To 2.4 (external site) · Subsquare (Polkadot OpenGov) — Referendum 1938: Upgrade Bulletin System Chains To 2.4 (external site) · Subscan — Polkadot Asset Hub block 20135000 (external site) · Subscan — Polkadot Asset Hub block 20150000 (external site)
-
Pathfinder v0.24.0 added support for Starknet v0.14.4 and changed WebSocket behaviour
Software Mansion released Pathfinder v0.24.0, a Starknet full node. It updates the node's execution libraries so it can follow Starknet v0.14.4, and StarkWare's v0.14.4 pre-release notes list Pathfinder v0.24.0 as the required version. The release is marked breaking: WebSocket clients of the node's RPC must now answer server pings, which the node uses to detect inactive connections. It also caps WebSocket connections (1,024 by default) and puts a 30-second default timeout on trace requests forwarded to the feeder gateway.
- Implementation:released as a stable version (not a pre-release)
- Release:v0.24.0 published on GitHub on 2026-09-01 and marked Latest at review time
- Activation:takes effect when an operator installs it; the v0.14.4 network upgrade it supports is scheduled for mainnet on 2026-10-05, after this review, pending governance approval
Sources: Software Mansion (GitHub) — Pathfinder v0.24.0 (external site) · Starknet Community Forum — Starknet v0.14.4 Prerelease Notes (external site) · Software Mansion (GitHub) — Releases: software-mansion/pathfinder (external site) · Pathfinder (Software Mansion) — Pathfinder introduction (external site)
-
stellar-core v28.0.1 released with three stability fixes
stellar-core v28.0.1, a patch to the Protocol 28 node software, was published on GitHub on 1 September 2026, ahead of the 16 September Mainnet vote. Its release notes list three stability changes: repeated query messages between peers are deduplicated, transactions arriving from peers that have not finished authenticating no longer get background signature checks, and the functions that add up a transaction set's fees now cap their totals so the sums cannot overflow. The notes describe no protocol change and no network vote.
- Implementation:three stability fixes in stellar-core; no protocol change listed
- Release:stable release (not a pre-release) published 2026-09-01; shown as Latest on the releases page at retrieval
- Activation:takes effect on each node when its operator installs it; no network vote involved
Sources: Stellar Development Foundation (GitHub) — stellar-core v28.0.1 (external site) · Stellar Development Foundation (GitHub) — Clamp additions in tx set fee summing functions (external site) · Stellar Development Foundation (GitHub) — stellar-core releases (external site) · Stellar Development Foundation (GitHub) — stellar-core releases (Atom feed) (external site)
-
Security Council disclosed five 2026 instant upgrades that patched ZKsync Era
The ZKsync Security Council published a notice listing five instant upgrades for ZKsync Era, signed between 23 January and 15 August 2026. They were circuit patches that fixed reported vulnerabilities (one a soundness issue), an over-constraint that could have blocked proofs for valid batches, miscomputation in some EraVM operations and a cryptographic weakness in the proof system. The notice said user funds were not believed to be actively at risk and there was no evidence of active exploitation when each upgrade was approved.
- Implementation:five circuit patch versions applied (v0.29.3 to v0.30.1)
- Release:disclosed after deployment
- Activation:applied to Era mainnet; the notice lists signing dates rather than execution times
Source: ZK Nation Forum — Notice of 2026 Instant Upgrades: Security Patches (external site)
-
go-algorand 5.0.1 tightened State Proof verification without a protocol upgrade
The maintainers published go-algorand 5.0.1 as a stable node release, nine days after the 5.0.0 protocol upgrade took effect on mainnet. The notes say it improves node safety and the verification and performance of State Proofs, and the one changelog entry makes nodes reject State Proof data that uses a mismatched hash type. The notes state that the release contains no protocol upgrade.
- Implementation:one State Proof verification change listed in the 5.0.1 changelog
- Release:5.0.1 stable released 2026-08-31; superseded by 5.0.2 on 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.1 release notes (external site) · algorand/go-algorand maintainers — algorand/go-algorand releases (external site)
-
Astrovault, Archway's main exchange, says it has closed
Astrovault's homepage now carries a one-line notice that it closed on 31 August 2026. Astrovault is the exchange Archway's own homepage features, and its AXV token appears in Archway's asset list. No fuller closure announcement was found by the review tools.
- Implementation:closure stated on the project's homepage
- Release:no software release involved
- Activation:closed as of 31 August 2026 per the notice; contract state not checked
Sources: Astrovault — Astrovault homepage (closure notice) (external site) · Archway — Archway homepage (external site) · Cosmos chain-registry maintainers — Archway asset list (external site)
-
Mainnet block production paused for a security review, then resumed with v3.1.5
On 31 August 2026 Ontology suspended mainnet block production after its daily security check found a potential concern. On 1 September it said it had found malicious attack activity that did not involve user assets and would upgrade the network. On 2 September it announced that the mainnet had resumed and told sync nodes to upgrade to v3.1.5.
- Implementation:security remediation and network upgrade completed, per Ontology
- Release:ontology v3.1.5 released 2 September 2026
- Activation:mainnet resumed on 2 September 2026; a REST read on 2026-09-29 showed the chain producing blocks
Sources: Ontology News — Ontology Mainnet Emergency Pause for Comprehensive Security Review (external site) · Ontology News — Ontology Mainnet Pause: Security Update and Network Upgrade (external site) · Ontology News — Ontology Mainnet Has Resumed: Sync Nodes Required to Upgrade to v3.1.5 (external site) · Ontology (GitHub) — ontology v3.1.5 release (external site) · Ontology — Ontology public node REST: current block height (read 2026-09-29) (external site)
-
Symbol SDK 3.3.3 fixes fee calculation for transactions with cosignatures
The JavaScript and Python SDK 3.3.3 releases fix the Symbol transaction fee calculator added in 3.3.2 in June 2026, which had not multiplied the size of cosignatures by the fee multiplier. The Python release also adds functions that build a transaction or embedded transaction from a raw descriptor. The 3.3.1 releases in April 2026 added TypeScript 6 and Python 3.14 support and JSON output for multisig workflows, and the 3.3.2 releases in June 2026 added the fee-calculation helpers.
- Implementation:released in the JavaScript and Python SDKs 3.3.3
- Release:published on GitHub 2026-08-31
- Activation:takes effect when an application upgrades; no network activation
Sources: Symbol (GitHub) — Symbol Javascript SDK 3.3.3 release notes (external site) · Symbol (GitHub) — Symbol Python SDK 3.3.3 release notes (external site) · Symbol (GitHub) — Symbol Javascript SDK 3.3.1 release notes (external site) · Symbol (GitHub) — symbol/symbol releases (external site) · Symbol (GitHub) — Symbol Javascript SDK 3.3.2 release notes (external site) · Symbol (GitHub) — Symbol Python SDK 3.3.1 release notes (external site)
-
Migration-contract replay exploit led the Foundation to halt ICON for about 25 hours
On 27 August 2026 an attacker replayed two signed withdrawal messages 1,492 times through the ICON migration contract and SODAX Asset Manager, releasing 119,866,000 ICX and 531,600 bnUSD of foundation-held funds. The Foundation paused the contract, halted the chain at block 117,479,936, deployed a fix and a relayer allowlist, and restarted the chain on 28 August. It reports net confirmed losses of about 150.2 ETH and 31,204 USDC, with most ICX frozen at exchanges.
- Implementation:serialization fix and relayer allowlist deployed during the restart
- Release:post-mortem published
- Activation:chain resumed about 07:51 UTC on 28 August 2026; recovery of exchange-held funds ongoing
Source: ICON Foundation — ICON Network: Replay Exploit Post-Mortem (external site)
-
Oasis disclosed a simulation attack on upgradeable confidential contracts
An Oasis engineer described how someone holding upgrade rights over a confidential Sapphire contract could recover a stored private key bit by bit by simulating upgrades, because simulated calls never reach the chain. Oasis says it found the issue internally and held its deployments until it was remediated. The fix, a two-step upgrade that cannot complete within one block, shipped in version 0.2.18 of the sapphire-contracts library, and the post says the Privana services that prompted the work now run on it.
- Implementation:mitigation pattern released in a library
- Release:sapphire-contracts 0.2.18
- Activation:applies only to contracts that adopt the pattern
Sources: Oasis blog — Accessing a Vault Key With Simulated Upgrades (external site) · npm registry — @oasisprotocol/sapphire-contracts package metadata (external site)
-
MANTRA published its post-mortem of the 20 August 2026 exploit and 30-hour halt
MANTRA reported that an integer-underflow bug in the shared cosmos/evm component let an attacker move about 721 million MANTRA from the burn address and an old multisig. Validators halted the chain for 30 hours and 13 minutes and restarted on v8.4.0 without a rollback; about 38 million MANTRA stayed frozen in the attacker's account.
- Implementation:fix shipped in v8.4.0
- Release:released 21 August 2026
- Activation:chain restarted 22 August 2026; the post-mortem set out no fund recovery plan
Sources: MANTRA — 20th August 2026 Full Incident Post Mortem (external site) · CryptoSlate — Cosmos misjudged a critical bug for 4 months before hackers stole nearly $6 million across 6 chains (external site) · MANTRA Chain Status — Security vulnerability in Cosmos-EVM module (incident log) (external site) · The Block — Cosmos Labs says it wrongly cleared the bug behind a $5.7 million six-chain hack (external site) · MANTRA-Chain/mantrachain on GitHub — MANTRA Chain v8.4.0 release notes (external site)
-
sei-chain v6.6.3 fixed validator snapshot problems and added a freeze mode for historical EVM RPC
The v6.6.3 patch release, published on 28 August 2026, is recommended for validators, full-node operators and RPC operators. For validators it fixes a memory leak in memiavl snapshot writes, closes a race that could publish a truncated snapshot file, and checks snapshots before they are made current. For RPC operators it adds a freeze mode that holds a node at an upgrade boundary while it keeps serving historical EVM state, plus a router that sends each block-specific request to the matching frozen node. The notes say it contains no state-machine or consensus-breaking changes.
- Implementation:Released
- Release:v6.6.3 published 28 August 2026 as a recommended patch release
- Activation:no network activation; changes apply on each node that installs the release
Sources: Sei Protocol contributors — sei-chain v6.6.3 release notes (external site) · Sei Protocol contributors — sei-chain releases (external site) · Sei Protocol contributors — Release notes from sei-chain (Atom feed) (external site)
-
IOG reported Leios Earth-phase public-testnet results
IOG reported that the 41-day Earth phase of the MusashiNet public testnet peaked near six times the transaction-byte throughput of Cardano mainnet at the compared parameters, while also documenting bugs, forks, crashes, fixes, and remaining prototype work.
- Proposal:CIP-164 design and ongoing engineering
- Implementation:public prototype testnet Earth phase completed; Water phase continuing
- Release:testnet engineering report
- Activation:not activated on Cardano mainnet
Source: Input Output — Leios hits 6x Cardano's throughput on its first testnet (external site)
-
Hard fork at block 1,371,000 restores multi-input Spark spends
Firo v0.14.18.0 introduced a new versioned Spark spend format with the permanent fix, activating by hard fork at block 1,371,000. Everyone running a node had to upgrade. Block 1,371,000 was mined on 4 September 2026 and marked ChainLocked. On 6 September Electrum-Firo released a fix because the light wallet did not recognise the new spend type and could not keep syncing.
- Implementation:shipped in v0.14.18.0
- Release:v0.14.18.0 released 2026-08-27; v0.14.18.1 followed on 2026-09-26
- Activation:fork height passed on 2026-09-04; the explorer node runs 0.14.18.1
Sources: Firo — Firo v0.14.18.0 released: Spark functionality to be fully restored (external site) · Firo developers (firoorg) — Firo releases (external site) · Firo — Firo Insight API: block 1,371,000 (external site) · Firo — Firo Insight API status (external site) · Firo developers (firoorg) — Electrum-Firo releases (external site)
-
Polygon disclosed denial-of-service fixes shipped in the Austin and Kyoto hardforks
Polygon disclosed vulnerabilities fixed by two mandatory hardforks. Austin (Bor v2.10.0, mainnet block 91,949,700) capped gas used by bridge state-sync events and removed an unbounded network field that could crash peers. Kyoto (Heimdall v0.11.0, mainnet height 51,533,000) added eight consensus-hardening fixes; the most severe let one cheap transaction force costly decoding on every validator.
- Implementation:fixed in Bor v2.10.0 and Heimdall v0.11.0
- Release:mandatory releases published
- Activation:active on mainnet per the disclosure
Sources: Polygon Community Forum — Security releases review: Bor v2.10.0 (Austin HF) and Heimdall v0.11.0 (Kyoto HF) (external site) · Polygon Community Forum — Bor v2.10.0 release (external site) · Polygon Labs (GitHub) — Bor v2.10.0 - Austin hardfork (external site) · Polygon Community Forum — Heimdall v0.11.0 (external site)
-
Node 1.6.4 proposed a 20 WAVES reward split; the boost ended without it
Node 1.6.4 introduced feature 26, Adjusted Block Reward Distribution: once active, the total block reward would be 20 WAVES, with 10 to the Waves DAO, 8 to the producer and 2 to the XTN buy-back address (10 and 10 if the buy-back is ceased). It was meant to replace the tenfold boost if activated before height 5,410,000. That did not happen: the boost ended at that height on 20 September 2026, the reward returned to 6 WAVES, and on 27 September the feature was still in voting.
- Proposal:proposed in node 1.6.4
- Implementation:implemented in node 1.6.4
- Release:node 1.6.4 released 2026-08-27
- Activation:in voting on mainnet as of 2026-09-27; missed the height 5,400,000 activation target
Sources: wavesplatform on GitHub — Waves node v1.6.4 release notes (external site) · Waves public node pool (nodes.wavesnodes.com) — Waves mainnet block reward status (node REST API) (external site) · Waves public node pool (nodes.wavesnodes.com) — Waves mainnet block header at height 5,410,000 (node REST API) (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)
-
Release v9.6.4 fixed a flaw where an order with a bad builder address could halt the chain
protocol/v9.6.4 carries the fixes for security issue SEC-76. Nodes now reject orders whose builder address (the address an order names to receive a builder fee) is invalid or belongs to a blocked module account, and they skip any such stored order when loading orders into the order book. The pull request says these orders could otherwise cause a crash during fee transfer, and its end-to-end test treats the case as a chain halt. The release also makes two permissioned-key filters, which limit a key to chosen markets or subaccounts, refuse message types they do not recognise instead of letting them through.
- Proposal:no governance proposal named in the release or pull request
- Implementation:SEC-76 fixes merged 20 August 2026 (pull request 3380)
- Release:released as protocol/v9.6.4 on 26 August 2026
- Activation:rollout method and timing not stated; the v9.7 upgrade names v9.6.4 as its starting version (inference that validators ran it)
Sources: dydxprotocol maintainers — protocol/v9.6.4 release notes (external site) · dydxprotocol maintainers — Pull request 3380: Port SEC-76 fixes to main (external site) · dydxprotocol maintainers — Pull request 3389: Backport v9.7 changes to release/protocol/v9.x (external site)
-
opBNB node v0.5.6 and op-geth v0.5.11 fix sync and recovery problems without a hard fork
BNB Chain released opBNB node v0.5.6, which fixes a peer-to-peer sync stall that could leave a restarted node's latest block stuck for minutes, and op-geth v0.5.11, which makes path-based state recovery after an unclean shutdown reliable and keeps withdrawal proofs collected during recovery. Both update the Go toolchain and security-related dependencies.
- Implementation:shipped in opbnb v0.5.6 and op-geth v0.5.11
- Release:optional upgrade
- Activation:no activation; takes effect when each node upgrades
Sources: BNB Chain (GitHub) — opBNB v0.5.6 release notes (external site) · BNB Chain (GitHub) — op-geth v0.5.11 release notes (external site)
-
Revolut launched the EURR euro stablecoin on Ethereum and Polygon
Polygon announced that Revolut's EURR, a euro token meant to be redeemable one for one through its regulated issuer under the EU's MiCA rules, launched on Ethereum and Polygon, with a first rollout to customers in Denmark, Poland and Portugal.
- Implementation:announced as launched
- Release:initial customer rollout
- Activation:rollout limited to named countries at announcement
Source: Polygon Labs — Revolut Launches EURR, a Euro-Backed Stablecoin, on Polygon (external site)