Meter's Unauthorized Mint: How a Block Validation Flaw Put $2.3M in Unbacked Wrapped MTRG on BNB Chain

On September 23, 2026, at 21:14 UTC, an attacker began minting unbacked MTR and MTRG on the Meter network. In its security incident announcement, Meter attributed the attack to a "block validation flaw" and said the attacker sold the minted tokens on decentralized exchanges and bridged funds out.

Before Meter's statement, security firm Blockaid flagged the activity on BNB Chain. Blockaid reported that the attacker used Meter Passport, Meter's cross-chain bridge, to mint approximately $2.3 million in unbacked wrapped MTRG across roughly two mint transactions, then sold part of it on PancakeSwap. Blockaid's follow-up linked the exploiter addresses, an example transaction, and the affected token contract.

Meter paused its mainnet and the bridge, asked users to stop sending, trading, or bridging tokens on Meter, and said it was working with exchanges to suspend deposits and withdrawals. It also warned that "Transactions after block 100731417 may not be honored."

Meter has described the cause only as a block validation flaw on its own mainnet. It has not published a technical post-mortem explaining which check failed or how the attacker got invalid state accepted by the network.

Two views of one incident

The two primary sources describe different parts of the same attack. Meter describes the origin: a flaw on the Meter chain that let the attacker create MTR and MTRG with nothing behind them. Blockaid describes where the value went: Meter Passport issued wrapped MTRG on BNB Chain, which the attacker sold for real liquidity on PancakeSwap.

The likely connection is simple. A bridge mints wrapped tokens on the destination chain when it sees a valid deposit or lock on the source chain. If the source chain accepts invalid blocks or unbacked balances, the bridge has no way to know the tokens it is wrapping should not exist. Neither source has confirmed the exact path, but this would explain why a flaw on Meter showed up as an unbacked mint on BNB Chain. BNB Chain's own consensus was not compromised. It only processed what the bridge contract allowed.

// Sep 23, 21:14 UTC — attack begins (per Meter)
meter_mainnet  = block validation flaw exploited
minted         = unbacked MTR and MTRG

// BNB Chain (per Blockaid)
bridge         = Meter Passport
wrapped_mtrg   = ~$2.3M nominal, ~2 mint transactions
sold_on        = PancakeSwap (partial)

// Meter response
mainnet        = paused
bridge         = paused
exchanges      = asked to suspend deposits / withdrawals
warning        = "Transactions after block 100731417 may not be honored"

// Not yet established
realized_loss  = unknown
rollback       = suggested, not confirmed

A rollback was raised, not confirmed

Meter's warning about block 100731417 points to a possible reversal or invalidation of transactions after the attack began. The announcement does not say that a rollback was carried out. Even if it happens, it would only cover Meter's own chain. Wrapped MTRG already sold on BNB Chain, and funds already bridged elsewhere, would not be undone by rewriting Meter's history. Whoever bought those tokens on PancakeSwap would be left holding assets with no backing.

Not Meter Passport's first incident

In February 2022, a Meter Passport contract bug let an attacker take approximately 1,400 ETH and two wrapped BTC, worth about $4.3 million at the time. That is useful context for the bridge's history, but there is no evidence that the 2026 attack used the same vulnerability. The 2022 bug was in the bridge contract. Meter places the 2026 flaw in block validation.

• Treat block validation as the highest-risk code in the stack. Every balance, bridge deposit, and contract call depends on the network rejecting invalid blocks. Consensus and validation logic needs adversarial testing, fuzzing, and independent review at least as strict as any smart contract.
• Check supply invariants continuously. Native token supply should only change through known issuance rules. Monitoring that compares total supply to expected issuance, block by block, would flag an unbacked mint within minutes rather than after tokens hit a DEX.
• Make bridges verify more than a deposit event. A bridge that trusts any event from its source chain inherits every flaw in that chain. Waiting for finality, checking that the source-side lock matches total wrapped supply, and refusing mints that break that match limit how far a source-chain bug can spread.
• Cap bridge mints by rate and size. Blockaid saw roughly $2.3 million minted in about two transactions. Per-transaction and per-hour mint limits, with large mints held for review, give the team time to pause before unbacked tokens reach outside liquidity.
• Pause the bridge and source chain together. An automated circuit breaker that halts Passport when Meter's supply checks fail would have stopped the flow of wrapped MTRG to BNB Chain at the source, without waiting for a manual decision.
• Decide on rollback policy before an incident. Warning that transactions "may not be honored" leaves users, exchanges, and DEX traders unsure which of their transactions will stand. A published policy for when and how the chain would reorganize gives everyone a clearer basis to act.