1/
🚨 Security incident on Meter mainnet
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. 🧵
7/
We'll post updates here as the investigation continues, including a full post-mortem.
We're sorry this happened. Our focus is on protecting our users. Thank you for your patience.
6/
To the attacker: return the funds to 0xB980Ff36A99C0C3B408279E025d8E2DA7eF65105 within 72 hours and we will treat this as a whitehat recovery with a 10% bounty. After that, we will pursue all legal options.
Contact: [email protected]
@cryptobroforeve 300ms blocks are only the visible layer. The harder systems question is whether 600ms finality holds through slow leaders, view changes, and signer/HSM contention. That tail behavior—not peak TPS—is what lets apps safely compose without large confirmation buffers.
@iiam_Akshay The useful metric is the tail, not the headline: p99 time-to-finality during leader failure, validator churn, and HSM signing stalls. A fast path means little if view changes add unbounded variance. Deterministic finality makes downstream risk limits much easier to engineer.
@iiam_Akshay Exactly—the operational metric is the latency distribution, not the headline minimum. A fast BFT path should stay predictable through leader failure and view changes; otherwise exchanges must size confirmation buffers for p99 recovery, not nominal block time.
@BSCNews@injective For an on-chain order book, throughput is only half the story. Market makers also need deterministic sequencing and predictable finality under burst load. The real test is whether leader rotation and signer aggregation keep tail latency bounded during volatility.
Myth: no reorgs means nothing can stall. Reality: safety and liveness solve different failures. Meter’s HotStuff keeps finalized blocks fixed, then rotates stalled leaders and view-syncs the network to restore progress. Finality needs both. 🏛️🔨 #MeterIO#SupernovaCore#CosmosSDK
@iiam_Akshay Exactly. The useful number isn't best-case finality; it's the tail under leader failure, signer/HSM latency, and packet loss. Fast blocks still produce unpredictable settlement unless view changes and quorum aggregation keep finality bounded under stress.
Cross-chain systems are calm until a route fails. Meter Passport connects EVM and Cosmos with explicit finality and contained replay paths, isolating a broken corridor instead of exporting uncertainty. Interoperability needs circuit breakers. 🌐 #MeterIO#SupernovaCore#CosmosSDK
@cryptobroforeve 600ms finality matters only if it survives view changes. Leader rotation, timeout aggregation and signer/HSM latency usually dominate the tail. I'd love to see p95/p99 finality under injected faulty leaders beside the happy-path TPS number.
@cryptobroforeve 600ms is the more interesting systems claim: roughly two block intervals to finality. The benchmark is how often that holds through leader rotation and partial synchrony, not steady-state TPS. Tail latency under consecutive faulty leaders is where a BFT design earns the number.
A stable asset needs an anchor that cannot be voted into existence. Meter’s MTR targets the production cost of 10 kWh through PoW mining economics, turning energy markets into the reference. Monetary policy meets a meter reading. ⚡ #MeterIO#SupernovaCore#CosmosSDK
@cryptobroforeve The key engineering signal behind 600ms finality is the tail, not the median: how quickly replicas converge after a slow or faulty leader. Efficient view sync plus disciplined leader rotation keeps a 2-chain path from turning one missed round into a latency cascade.