Mezo's October 7 report says an October 5, 2026 attack took 37 veBTC positions from 36 holders, involving approximately 5.52 BTC. A holder's next question is whether their particular position appears in the report and whether any promised repayment actually arrived. A reimbursement announcement alone cannot answer the second question.
Identify the position before interpreting the balance
The veBTC overview describes an NFT representing BTC locked on Mezo, with voting and protocol-fee rights. It is not simply another label for an ordinary Bitcoin wallet balance. Start with the account and position you used, rather than assuming every asset with BTC in its name belongs to the same product.
The incident report includes a holder/NFT-ID table. If you used several accounts, compare the relevant account and position identifier, not only the address currently selected in your wallet. A position missing from a front-end list deserves investigation; by itself it does not establish theft, repayment or an ordinary user withdrawal.
For a hypothetical holder with two positions, one listed in an incident report and one absent from it, the evidence must remain position-specific. Do not apply the listed loss to both. Also keep the recorded loss amount separate from the wallet's total balance, which may include unrelated transfers. This example is a reconciliation method, not a finding about an actual holder.
Keep the fix, the promise and receipt in separate columns
Mezo reports fixing the flaw and promises to repay affected holders from protocol-owned funds through direct transfers, without a recovery website or extra interaction. Those statements describe the project's response. This review has not independently verified completion for individual wallets, and it does not infer nonpayment from the absence of a later notice.
| Question | Evidence to retain | What would still be missing |
|---|---|---|
| Was this position included? | Holder address, position ID and the relevant report row | Evidence for any other position you owned |
| What amount is being reconciled? | Reported loss in its original asset and unit | An explanation for a different claimed amount |
| Was a payment sent? | Public transaction reference supplied through an official channel | Confirmation that it targets your account |
| Did I receive the intended asset? | Network, recipient and incoming asset details | Resolution of a mismatch with the stated repayment |
The table is an editorial worksheet. It is not a downloaded payment ledger. Do not mark the final row complete merely because a project says funds have been allocated or because an unfamiliar token appears in your wallet. Ask which transaction is the reimbursement and why it matches the obligation you are checking.
A read-only review comes before a recovery transaction
The project's glossary links its mainnet block explorer, where public addresses and transactions can be inspected. Prefer a link reached through the official documentation. A read-only comparison of public history does not require giving a support agent your seed phrase or private key.
- Locate the official incident report and save the row corresponding to the account and NFT position you actually used.
- Note the reported asset amount without converting it into a new claim based on today's market price.
- Review that account's incoming history on the relevant network, keeping transaction references for plausible repayments.
- Compare the recipient and asset with the repayment information supplied through official channels; leave unmatched transfers unresolved.
- If evidence is missing or inconsistent, ask for the transaction reference and asset/network explanation. Do not use a claim form received in an unsolicited message.
A wallet may display assets from several networks together. A tick next to an unrelated incoming transfer is not a useful reconciliation. Conversely, if the relevant payment is visible on-chain but your application does not display it, that is a different support question from asking whether a payment was ever sent. Include the public reference when describing the discrepancy.
Do not merge unrelated Mezo products into one recovery case
A news search can mix this event with lending, other vaults and bridge notices. Read the product and asset identifiers in each notice. A withdrawal instruction for a different vault is not evidence that your veBTC reimbursement requires the same action, nor is a lending collateral balance proof of exposure to this position contract.
Likewise, reviewing a later change to bridge availability does not establish that it caused the earlier contract incident. Follow the official blog for dated statements, and keep causal claims narrower than the evidence. This article does not reproduce the attack procedure, ask users to test the flaw or direct a bridge transaction.
An eventual exchange is a separate order
After a balance has been reconciled, any ordinary exchange requires its own supported asset and network check. Consult the supported-coins page and exchange process; this article does not establish KOT.CASH support for Mezo positions or their receipt assets. Exchanging an unrelated balance will not settle a missing-payment claim.
FAQ
Does the Mezo Bitcoin incident mean every BTC balance was affected?
Begin with the product and position identified by the incident report. A BTC label alone does not show that an ordinary wallet balance, another vault or a lending position belongs to that case.
Is a Mezo Bitcoin lending position the same evidence as veBTC exposure?
Identify the contract and position involved before assigning exposure. Keep a lending account's records separate from a veBTC position unless the evidence connects them.
Should I use a Mezo bridge recovery link to prove receipt?
A public-history review and a request for an official transaction reference come first. Do not connect or sign through an unsolicited recovery page to resolve a missing receipt.