On February 19, the Mezo security team was made aware of a drain on the Velar BTC/MUSD perpetual swap pool on Mezo by one of the primary participants, the curator of the Upshift tBTC vault. Though no one working directly on Mezo is responsible for operations of the Upshift vault or Velar DEX, this is generally an event that would trigger a crisis response on the dev team to assist in any needs from the affected external team(s); however, it took time to fully understand the nature of the issue, such that the dev team did immediately engage in crisis support procedures. The following is a postmortem of the event from the Mezo security team’s perspective. 

Overview of the Attack

Currently, all indications point to this attack being very similar to the attack used on the Stacks chain:

The exploit on Stacks leveraged the fact that the Pyth oracle pulled new prices based on activity and the contracts themselves did not have certain oracle price timestamp checks, alongside the fact that the attacker was able to control activity due to low non-attack activity. Though as of yet unconfirmed, the Redstone oracle used by Velar on Mezo works in a substantially similar way to the Pyth oracle used on Stacks in terms of its behavior, and the transaction pattern seen on Mezo (roughly: open long → close for BTC → open short with BTC → close for MUSD → repeat) as well as the small gains per transaction strongly point to the same goal and operating model.Overall, the attacker flowed ~$72M in volume through the contracts over the course of several days to slowly drain the pool for ~$401k (2.257 BTC + 250,077 MUSD). The attacker profit seems to have been around $250k. At least 236 wallets were used to execute the attack. A preliminary flow-of-funds analysis can be seen at https://mez.gg/f/2026-02-19-velar-bridge-investigation.html.

Incident Timeline

Jan 22: Exploiter started to prepare wallet infrastructure for exploit

Jan 26: Fund movement began in earnest, using a cycle of open long → close for BTC → open short with BTC → close for MUSD → repeat to extract LP reserves.

Jan 31: Most extraction was complete, bridging out continued.

Feb 4: Activity wound down throughout the day.
08:49 UTC: Velar shared exploit on Stacks on Twitter, indicates it is Stacks-specific.

Feb 19:
08:54 UTC: Gamma, the Upshift vault curator, notes possible frontend issue, inquired as to whether low balance is expected
08:56 UTC: Velar indicated they will investigate
08:57 UTC: Gamma indicated the vault had money last week
12:05 UTC: Velar confirmed with Gamma and dev team that Mezo pools were drained
14:05 UTC: Internal notice given to the Mezo security team
15:37 UTC: Mezo X account tweeted we are monitoring the situation
15:10 UTC: Gamma requested signatures for a transaction to pause deposits and withdrawals from tBTC vault on ETH (two members of the Mezo security team are on the relevant multisig)
15:13 UTC: Mezo community team removed Velar and its vault from the Mezo DeFi Hub on Notion
19:00 UTC: Transaction pausing deposits and withdrawals executed
19:17 UTC: Velar shared list of attacker wallets with Gamma and Mezo security team
19:54 UTC: Dev team removed Velar from Mezo Explore page
20:10 UTC: Mezo security team reached out to SEAL 911 to enlist their assistance
20:30 UTC: Mezo security team reached the conclusion that the attack in question started in late January and ended roughly February 4th
21:02 UTC: SEAL 911 engaged on incident
21:05 UTC: Mezo security team confirmed that wallets on the Velar attacker list bridged MUSD out via Wormhole
21:22 UTC: Seal911 noted that funds were exited through Ethereum → BSC → Tornado Cash

Observations

For the Mezo dev team, we want to maximize our ability to support the community and builders when exploits arise. To that end, we’ve pulled together some observations from this incident, and next steps that we will be undertaking on our end to assist external teams from responding to potential exploits in the future.Our investigation so far leads us to believe the following things:

• The attacker appears to have executed the Mezo attack at roughly the same time as the one on Stacks.
• Despite Velar’s contracts being exploited on Stacks, Velar does not appear to have checked other chains for similar exploits.
• Velar does not appear to have included a pause or slowdown system in their contracts. This was flagged by at least one auditor.
• Velar does not appear to have been monitoring their pools on Mezo. The issue was noticed 2 weeks after the attack occurred and the pools had been drained.
• It is not yet clear how actively Gamma was monitoring their curated funds on Mezo.
• It is not clear whether Gamma was informed by Velar of the original Stacks exploit.
• Gamma states they saw the funds available on Velar as recently as last week; they appear to have previously had issues with the Velar UI.

On our end, a few things stood out that we want to improve:

• Despite the internal alert to the security team being issued at 14:05 UTC, communication of the  nature of the problem was not immediately understood and we did not engage full crisis support for roughly 6 hours.
• The wallet enabling pauses of deposits and withdrawals for the Upshift vault whose funds were deployed to Velar had a 3-of-4 signature configuration. Two of the signers were part of the Mezo dev team. At the time that a pause was requested, one of those signers had recently had a hardware failure without the opportunity to rotate their key yet, and another was unavailable for several hours due to travel.
• Comms from Mezo were disjoint and vague delaying full engagement of the crisis management process. Regardless, the Mezo team will use this incident as impetus to  tighten our internal escalation process and further educate everyone on the Mezo team regardingour crisis management strategies.

Next Steps

Although the exploit was 2 weeks old, the Mezo team did not realize that until later in the crisis management process. As such, we’ve approached the issues above from the perspective of what would have happened if the crisis had been an active event.

• The Mezo team was already halfway through a full reassessment of signer distribution, wallet configuration, and redundancies to ensure failures like today’s cannot block a critical transaction from being executed for several hours. The goal is to ensure that enough signers are available in a scenario like this so that critical transactions can be signed with fast turnaround.
• In the future we plan on working with anyone who includes members of the team on multisig setups to ensure that pause actions require lower proportional signing thresholds than more destructive actions that might directly affect user funds.
• We are working with every member of the Mezo team to ensure escalation paths are clear, and to decrease our response times to external incidents. Our goal is to respond to crises, internal or external, as quickly as possible in whatever way is most useful for the situation, with clear internal ownership and specific, clear communication to the community.
• We will also be working to further communicate to external builders the escalation paths available to them to notify us of a potential ongoing attack.