A "Block Validation Flaw" on Meter Mints Unbacked MTR and MTRG That Leak to BNB Chain via Passport: A Bridge Can Be No Safer Than the Source Chain's Validation

What happened

Meter.io posted on X on September 24: "On Sep 23 at 21:14 UTC, an attacker exploited a block validation flaw to mint unbacked MTR and MTRG, dump them on DEXs, and bridge funds out. Mainnet and the bridge are paused. Please stop all activity on Meter." In follow-ups, the team said "we've preserved the chain state. The recovery method is still to be decided." It warned that transactions after block number 100731417 may not be treated as valid in the recovery process, and it asked centralized exchanges to suspend MTR and MTRG deposits and withdrawals.

Blockaid was first to report from outside. It flagged the attack on Meter Passport on BNB Chain on September 24, reporting that about $2.3 million (about ¥360 million) of unbacked wrapped MTRG had been minted in roughly two mint transactions, with part sold on PancakeSwap. Reports put MTR down about 80% and MTRG down about 75% over 24 hours.

Meter has not yet disclosed the nature of the flaw, the full set of affected contracts and assets, or whether further minting is possible. SlowMist's incident database classifies the attack method as a "smart contract vulnerability," but Meter's own description is a "block validation flaw." This article treats the latter as the primary account.

How it worked: the bridge trusts accepted blocks

With limited primary information, the details cannot be stated with certainty. But if Meter's description is right and the flaw was in mainnet block validation, the structural reason the bridge minted unbacked assets is clear.

A lock-and-mint bridge generally watches the source chain for a "locked" event and uses it as grounds to mint the corresponding wrapped token on the destination chain. Relayers and verifiers check that the event is in a canonical source-chain block with the required confirmations. They do not usually re-validate whether that block contained a state transition that should never have been valid. If source-chain nodes accept an invalid block as canonical, the bridge copies it faithfully. Unbacked minting can then happen even when the bridge code is correct.

This series has covered the same pattern repeatedly. On Liquid Network in September, a proof-verification cache flaw created unbacked L-BTC. At Nomic, a forwarding bug let nBTC be double-spent, leaving about 36% of allBTC on Osmosis unbacked. In each case, one layer inherited without question a state that another layer had judged valid. In this author's view, a bridge's security is set by the weaker of its own verification and the source chain's state validation, and the latter is usually outside the bridge operator's control.

What a "block validation flaw" implies

The notable detail in Meter's wording is where it locates the flaw: block validation. A smart contract bug usually confines impact to that contract's users and can often be fixed by replacing the contract. A block validation flaw means the chain's node software accepted a state transition it should have rejected. That puts every asset on the chain and every downstream system inside the same blast radius. The fact that the attacker could mint both MTR and MTRG is consistent with a flaw in the chain's base layer rather than in a single token contract. This, however, is an inference from the wording of the announcements.

Passport has been exploited before, through an ERC-20 handler vulnerability, and Meter published a post-mortem at the time. Meter has not said whether this incident involves the same vulnerability or method. When reading incident records, it matters to distinguish a bridge compromise from a flaw in the chain itself and not file both under "bridge hack." The party responsible for the fix, and the fix itself, are different.

Also on September 24, payroll and treasury protocol Payy lost funds from its Ethereum bridge through a separate method. Connection points with external chains keep serving as entry points for attacks, beyond any single case.

The asymmetry of rollback

Meter says it has preserved chain state and signals that transactions after a certain block may be treated as invalid. As with Cronos in August (the Tectonic incident), where about 10,961 blocks were discarded, a source-chain rollback appears to be on the table. But only the state on Meter's own chain can be rolled back. The wrapped MTRG minted on BNB Chain, the PancakeSwap sales and onward movements to other bridges and exchanges are final on other chains. Rewinding the source does not rewind the destination. Someone ends up absorbing the difference, whether through invalidating minted tokens, handling liquidity pools, or counterparty losses.

Pitfalls to watch

First, the scope of a bridge "pause." Meter stopped both mainnet and the bridge. But the wrapped MTRG contract itself keeps running on BNB Chain, and already-minted tokens may remain tradable on DEXs. If the issuer holds no pause or freeze authority, stopping the bridge does not stop circulation on the destination chain.

Second, the receiving side's ledger. If transactions after block 100731417 are invalidated, exchanges and services that credited Meter deposits in that window will hold deposits that no longer exist on the source chain. Whether those deposits met on-chain confirmation thresholds makes no difference.

Third, wrapped tokens used as collateral. Any lending market accepting wrapped MTRG, or any oracle referencing DEX prices, can mis-liquidate or misprice in cascade once unbacked supply is dumped and the price collapses. Reports say MTRG fell about 75% in a day. Even if you never touched Meter directly, you face the same pattern if your collateral list includes wrapped assets.

Fourth, deciding to resume before the root cause is public. Until the affected client and validation stage are disclosed, outsiders cannot verify that the flaw is gone after a restart. Receiving parties should state explicitly that a published post-mortem and an identified fixed client version are conditions for resuming deposits and withdrawals.

[Technical Insights & Actions]

1. A bridge's security is capped not by the bridge's code but by the strength of the source chain's state validation. If source nodes accept an invalid block, the more correctly implemented the bridge, the more faithfully it mints what it should not. [Integrators / Product teams] This quarter, list the wrapped assets and bridges you accept, with each source chain's client diversity, its history of halts and rollbacks, and whether the bridge enforces mint rate limits. Cap accepted amounts on any path without such limits.
2. A source-chain rollback does not propagate to the destination. If you do not decide in advance who handles deposits that a rollback erased, and how, the decision will be made on the spot. [Integrators] By your next operations review, add to the runbook a ledger-correction procedure for "the source chain has invalidated everything after block N": identify the affected deposits, freeze the balances, and notify users.
3. An emergency pause does not reach assets already minted outside your chain. If the wrapped token has no pause or mint-halt authority, circulation continues after the bridge stops. [Contract developers] For wrapped tokens you issue, implement a mint pause and per-transaction and per-period mint caps before your next audit, and document who holds that authority and how it is invoked.

[Sources]

• Meter.io (X), security incident announcement (2026-09-24): https://x.com/Meter_IO
• Blockaid (X), detection of attack on Meter Passport (2026-09-24): https://x.com/blockaid_
• The Crypto Times, "Meter Passport Exploit Reportedly Mints $2.3 Million in Unbacked MTRG" (2026-09-24): https://www.cryptotimes.io/2026/09/24/meter-passport-exploit-reportedly-mints-2-3-million-in-unbacked-mtrg/
• Protos, "DeFi hack attack: Three exploits snatch $11M in a single day" (2026-09-25): https://protos.com/defi-hack-attack-three-exploits-snatch-11m-in-a-single-day/
• Crypto Economy, "Three DeFi Exploits Swipe $11M from Payy, Duelbits, Meter in One Day" (2026-09-25): https://crypto-economy.com/three-defi-exploits-swipe-11m-from-payy-duelbits-meter-in-one-day/
• SlowMist Hacked (Meter and Bitget entries): https://hacked.slowmist.io/

Note: JPY conversions use USD 1 = JPY 157.23 (Trading Economics, 2026-09-25).

This article is a technical commentary based on publicly available information and is not investment advice.