On October 5th, 2026, an attacker exploited a flaw in the veBTC contract to move 37 veBTC positions out of 36 holders’ wallets, and bridge the proceeds off the Mezo chain. Approximately 5.52 BTC was taken. The vulnerability has been fixed, funds are at no further risk, and all impacted users will be made whole.

Summary

veBTC is Mezo's vote-escrow system: you lock BTC and receive an NFT representing the locked position and the voting power that comes with it. The contract behind it, VotingEscrow, is deployed with a set of external Solidity libraries that hold most of its logic and supports meta-transactions through a trusted forwarder, so that actions can be relayed on a user's behalf. Each of those two design choices is standard and safe on its own and the attacker exploited how they interact with each other.

The attack vector

The meta-transaction standard we use identifies the real sender of a relayed call by having the forwarder verify their off-chain signature and append the verified sender's address to the end of the calldata. The contract later reads the last 20 bytes of its own calldata to learn who the actual sender is.

The attacker exploited the fact the veBTC contract was split into libraries given the EVM maximum contract size limit, and a call to an external library executes in a new stack frame with the compiler building a fresh argument buffer from the function’s declared parameters. The sender address appended by the forwarder is not a declared parameter - the compiler has no way to know it is there - so it is not carried across to the new stack frame. A carefully crafted _data parameter of safeTransferFrom function leads to interpreting the last 20 bytes as the actual sender supplied by the trusted forwarder.

This chain allowed the attacker to take over any veBTC position, but because of veBTC locking, they specifically targeted unlocked-but-not-redeemed veBTC positions so that they could redeem and bridge out BTC held in those out of the Mezo chain.

Timeline (all times UTC)

October 5th

• 18:03: attacker pre-funds their Mezo address for gas from Ethereum.
• 18:54 - 19:06: veBTC positions are taken, 37 positions total.
• 19:09: full balance bridged from Mezo to Ethereum.
• 19:15: proceeds converted to 174.61 ETH on a decentralised exchange.
• 19:51: proceeds consolidated into a holding wallet.

October 6th

• 08:45: team notices anomalous rebase transactions with BTC withdrawals to the zero
  address, and begins investigating veBTC locks.
• 09:04: a security incident is declared.
• 09:17: bridge withdrawals are paused.
• 09:21: the vulnerability is located in the code.
• 09:27: all transactions on the Mezo chain are halted.
• 10:00: SEAL 911 is contacted and the attacker’s addresses are shared with them.
• 15:00: the vulnerability is fixed. The bridge and the chain are unpaused.

Affected positions

Actions taken

Once we detected the attack, we paused bridge withdrawals within 33 minutes. We identified the vulnerability and disabled metatransactions altogether as there is currently no production use for them. We audited every other function reachable through the same path enumerating every external library function that resolves a sender this way and triaged each. Three functions besides the exploited one had access-control exposure, though far more constrained than the one used in the exploit; the rest reverted rather than misbehaving. All are covered by the same fix. Additionally, we verified the vulnerability was only exploited on this specific occasion. We reviewed every finding submitted to our Cantina bug bounty program and every report sent to security@mezo.org, and confirmed this vulnerability was never reported through either channel. Finally, we contacted SEAL 911, centralized exchanges in the funding chain, the venues used in the laundering path, law enforcement, and others to coordinate subsequent tracing and response.

Fund recovery

All affected users will be receiving the BTC that they lost from protocol-owned sources. That process will take a few days. BTC balances will be directly transferred to the affected wallets—no additional website or interaction will be needed, so please do not follow any links promising recovery of your funds, and remember to stick with official sources of news—the Mezo X profile, and this blog.

Next steps

The attacker in this case moved very quickly, and the window for the team to act at attack time was very short. As such, the best cure here would have been prevention. To that end, we have several initiatives that were already in motion to reduce risk on the chain:

• For some time, we have been reviewing all changes with frontier AI security models.
• We have introduced several security controls that allow relatively faster reaction to situations like this one, including the ability to pause bridge transactions in the system when an attack is detected.
• We are in the process of removing or limiting lesser-used features that expand our risk surface; this includes the recent sunsetting of native BTC wallet sign-up and native BTC wallet bridge-ins.
• We will continue to calibrate bridge-out limits to balance risk and convenience.
• We are in the process of setting up an offensive review harness for existing mainnet contracts that will continuously monitor for new vulnerabilities. Though the code in this exploit was audited twice and has had a bug bounty on it for many months, the modern security landscape is such that additional continuous monitoring is becoming a key part of security strategy.

In addition to these existing initiatives, we are investigating whether there is a class of automated triggers that could have allowed both automated detection and automated blast prevention in the case of this and other vulnerabilities we have seen across the space. We will share updates on this front as we have them.

A message to the attacker

We are currently pursuing recovery and law enforcement action; however, we would rather resolve this than litigate, so we would like to extend a simple offer:

Return 4.415417121 BTC - equivalently 139.69 ETH, 80% of what you took - to address 0xbe6Fdc9DA59cadc157f959B5B28A7e3ea74BdCd4, and the remaining 1.103854280 BTC (34.92 ETH, 20%) is yours to keep as a bug bounty. You can also contact us at security@mezo.org per the process outlined at https://mezo.org/security.txt. We will treat the disclosure as a white-hat finding, and we will stop pursuing criminal action. This was a real vulnerability that two audits and our own reviews missed. Under our bug bounty program, that work has value, and we are willing to pay for it under those terms.

This offer is open until 23:59 UTC on October 14th, 2026.

This material is provided for informational purposes and reflects the understanding as of the date of publication, based on an investigation. It may be updated, supplemented, or corrected, and no representation or warranty is made as to its completeness. Statements regarding future plans, initiatives, timing, and outcomes are based on current information and are subject to change. Security audits, code reviews, bug bounty programs, and monitoring reduce but do not eliminate risk, and no representation is made that the Mezo network is or will remain free from vulnerabilities; use of the network involves risk, including risk of loss. References to third parties are descriptive only and do not imply endorsement or partnership.