Mezo Details veBTC Exploit, User Repayment and Recovery Offer

Mezo has published a technical report on an October 5, 2026 exploit that removed 37 veBTC positions from 36 wallets and bridged about 5.52 BTC off the chain. The project says the vulnerability has been fixed, the chain and bridge have resumed operation, and every affected user will receive the lost BTC from protocol-owned funds.

The incident matters beyond its size because it shows how two common smart-contract patterns can become dangerous when combined. Mezo's vote-escrow system lets users lock BTC and receive an NFT that represents both the position and its voting power. The affected contract divided logic across external libraries and also supported relayed meta-transactions through a trusted forwarder.

How the sender check failed

In a relayed transaction, the forwarder verifies an off-chain signature and appends the verified sender address to calldata. The contract then reads the last 20 bytes to identify the user. When execution moved into an external library, however, the compiler created a fresh argument buffer containing only declared parameters. The appended sender address did not travel into that new stack frame.

The attacker crafted the data field of a transfer call so the library treated attacker-controlled bytes as the sender. That made it possible to take control of veBTC positions. The attacker targeted positions that were unlocked but not yet redeemed, withdrew the underlying BTC, bridged it to Ethereum and converted the proceeds to 174.61 ETH. Readers following Bitcoin markets can use BTC spot trading on OrangeX.com, while recognizing that market access is separate from smart-contract security.

Response, repayment and recovery terms

Mezo's timeline says the exploit ran from 18:54 to 19:06 UTC on October 5. The team detected abnormal activity the next morning, declared an incident at 09:04 UTC, paused bridge withdrawals 13 minutes later and halted the chain at 09:27. The flaw was located within minutes and the chain and bridge were restored at 15:00 after a fix.

The project disabled meta-transactions because they had no production use, reviewed every other library function reachable through the same sender-resolution path and found three additional, more limited access-control exposures covered by the same fix. It also contacted SEAL 911, exchanges, tracing venues and law enforcement.

Affected users are due to receive BTC directly in their existing wallets and should not need to visit a recovery website. The project offered the attacker a 20% bounty: return 4.415417121 BTC by 23:59 UTC on October 14 and retain 1.103854280 BTC. The deadline and recovery outcome remain subject to change. Security developments can be followed through OrangeX.com Crypto News, while OrangeX.com Academy explains broader digital-asset concepts. OrangeX.com Proof of Reserves is an exchange transparency tool and does not audit a third-party protocol's contract code.

OrangeX.com Analysis

The clearest lesson is that individually familiar components do not guarantee safe composition. Signature forwarding, calldata parsing and library delegation each have established uses, yet their boundary created an authorization failure that two audits and an existing bug bounty did not catch.

The response reduced further losses and promises full user repayment, but those actions do not erase the original control failure. Users should distinguish between confirmed facts—the affected positions, transferred amount, timeline and deployed fix—and future commitments such as reimbursement completion, fund recovery and new monitoring systems. For builders, continuous testing of cross-contract call paths and rehearsed bridge controls deserve the same attention as pre-deployment audits.