Security
31 Hours After the Mint, Meter Pushed a Branch Named 'Unconditional Consensus Validation'
Meter says a block validation flaw let an attacker create MTR and MTRG from nothing. A branch in its public node code switches on three checks that synced blocks skip. The code Meter says it deploys still skips all three, and the team has not said whether the two are connected.
On September 24 the security firm Blockaid posted that an attacker was using Meter Passport, the bridge for the Meter network, to mint wrapped MTRG on BNB Chain and sell it on PancakeSwap. It counted about $2.3 million in unbacked tokens across roughly two mint transactions and said the attack was "still ongoing." The Crypto Times, relaying the alert, noted that the figure is the value of what was minted, not a confirmed loss or the attacker's profit.
Meter's own account moved the problem off the bridge. "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," the team said, as quoted by Protos. Mainnet and the bridge were paused. Meter says it has "preserved the chain state" and that "the recovery method is still to be decided." Per Coin Gabbar, it also told users not to send, trade or bridge any token on Meter and warned that transactions after block 100731417 may not be honored.
That is the whole of what Meter has said about the cause: a block validation flaw. It has not said which one. Meter's code is public, though, and it shows more than the statements do.
A branch at 04:31
At 04:31 UTC on September 25, about 31 hours after the time Meter gives for the start of the attack, a new branch named fix/unconditional-consensus-validation appeared in meter-pov, the Go node software that runs the chain. It holds one commit, 0c57c64, titled "Validate synced blocks unconditionally." It changes three files, and it makes three changes to how a node handles blocks it receives while syncing from peers.
The quorum certificate. In Meter's consensus a block carries a quorum certificate, a bundle of committee signatures showing that the validators agreed on it. On the deployed branch, processBlock checks that certificate only when the block's timestamp plus one block interval is later than the current time. In plain terms, only fresh blocks get their certificate checked. A block older than one interval skips the check. The fix removes that condition, so every block's certificate is checked.
The body checks. Synced blocks go through ProcessSyncedBlock, which calls the validator with a forceValidate flag set to false. That flag gates the transaction-level checks: whether each transaction and clause matches what the node expected from the last key block, and whether embedded script data matches its expected pattern. The fix sets it to true and removes the gates.
The proposer. A function called validateProposer recovers the address that signed a block header, then returns success. It never compares that address to anything. The fix adds a check that the signer is a member of the current committee, plus a unit test for it.
Three checks, and when each one stopped running
| Check on synced blocks | Deployed branch | Fix branch | In place since |
|---|---|---|---|
| Quorum certificate | Only if block is newer than one interval | Always | Sep 22, 2023 |
| Transaction and clause checks | Skipped (forceValidate=false) | Always | Sep 12, 2023 |
| Proposer in committee | Never checked | Required | Dec 2018 |
How long the gaps have been there
Git blame dates the freshness condition on the certificate check to a commit of September 22, 2023, titled "better logging for block sync, skip logdb access if no txs in block." The false flag on synced blocks arrived ten days earlier, in a commit titled "fix several minor nil pointer issues." Neither commit message mentions validation. Both read like sync-speed and stability work.
The proposer function is older. The version in the tree just before December 2019 reads the signer, prints it to the console with fmt.Println("signer", signer) and returns nil. A December 20, 2019 commit titled "unused var" commented out the print and discarded the address. As far as the history shows, the function has never checked it.
To be fair to the design, the quorum certificate is the real guarantee in a BFT chain. If every certificate is verified, a block from a stranger cannot collect the committee's signatures, and a proposer check is only a second line of defense. The problem is that the certificate check is the one that stops running on older blocks. Each skipped check looks reasonable if you assume the others are working.
What the Desk cannot establish
Three things are unclear, and each one matters.
First, Meter has not said that this branch fixes the flaw that was exploited. The branch name, the timing and the "block validation flaw" wording point the same way, but a team investigating an incident might harden several paths at once. The Desk is reporting what the change does, not claiming it describes the attack.
Second, the branch is not on mainnet. It was cut from the September 2023 commit that introduced the certificate condition, and it sits 208 commits behind the mainnet branch. In June, Meter's own pull request #51 described that branch as "the deployed mainnet commit." As of this writing, all three gaps are still there. With the chain paused, that exposure is on hold, not closed. It will matter when the chain restarts.
Third, the Desk has not reconstructed the attack on-chain. The Crypto Times lists the wrapped MTRG contract on BNB Chain as 0xbd29…8a9f and two associated addresses, and Meter has published attacker addresses of its own. Tracing how the minted MTR and MTRG reached the bridge is work for Meter's post-mortem.
Meter has had a hardening year
The node repository shows Meter was already finding problems. In June it shipped TeslaFork14, a hard fork whose commit message describes two bugs in deployed code. A 2025 correction flag had never been set on mainnet because of a copy-paste error. And the EVM's single call-value field could not tell MTR from MTRG, so the fork added a guard against MTRG value landing in contract code. Both fixes concern execution. Neither touches the sync path.
This is also Passport's second incident. In February 2022 the bridge lost about $4.3 million when a flaw in its handling of wrapped native tokens let an attacker fake deposits; Meter's post-mortem blamed an extension to the deposit function, and the team compensated users in MTRG. That was a contract bug. This one, by Meter's own account, is in the chain.
The Take
Skipping checks on old blocks during sync is a common optimization, and at some point it was probably a reasonable one here: the blocks were once fresh, somebody once validated them. The trouble is that "somebody already checked this" was the assumption behind all three gaps at once, and there was no fixed point where a synced block got a full check. Meter handled the first hours well. It paused quickly, named a block cutoff and warned users off. The public commit it pushed afterward is more candid than its statements. What Meter owes now is simple: say whether this branch is the fix, merge it into the code validators actually run before the chain restarts, and explain how a block old enough to skip its certificate check ended up minting money.