Statement Regarding ALEX Incident on June 6th, 2025
On Friday, June 6th, after initial reports from the Stacks community, the ALEX Labs team confirmed a security incident on their decentralized exchange, which impacted many of their asset pools, including STX, sBTC, USDC, USDT, and others. Recovery and compensation of their users is underway.
Given questions from the community following ALEX’s original communications stating that this was due to a limitation in Stacks itself, we felt it was prudent to clarify this.
On the same day as the incident, Adriano Di Luzio, CTO for Bitcoin L2 Labs, the largest core development contributor in the ecosystem stated the following: “I'm glad to see quick action by the ALEX team to resolve the situation for users, but want to be very clear: it is not a Stacks limitation or vulnerability that caused this exploit.”
We concur with this assessment and will further add that it is known in the current design of Clarity and many other smart contract languages that an application needs to verify the content of a contract and implement other security measures to protect the application in depth. ALEX’s contract relies on the was-tx-mined-compact function, which indicates whether a transaction was mined in a block while making no claims about the execution of that transaction. You can also learn more about how the exploit was potentially implemented by reading this community member’s assessment, though an official post-mortem has not yet been provided. We will update this post with a link to a formal post-mortem when ALEX provides one.
Fundamentally, this was an issue with ALEX’s smart contract implementation, and it is unreasonable to attribute responsibility to the protocol. If this were a protocol problem, all applications like ALEX would be vulnerable to it, and they are not. You will see the same design choice in other ecosystems related to failed transactions as well, with applications consistently taking this (and many other aspects of the protocol’s design) into account when implementing their smart contracts. Other decentralized exchanges on Stacks have successfully implemented their contracts without this type of vulnerability.
The Stacks ecosystem has a number of security and auditing firms actively engaged with the protocol and many more that are readily available to builders.
Thank you to the community members who helped identify this early on, the many who have supported ALEX during this time to mitigate impact, and the ALEX team for their swift action and ongoing efforts to make users whole. Given this is an app-level issue and firmly not a protocol-wide vulnerability, we will continue to defer to ALEX to provide further updates.
Given questions from the community following ALEX’s original communications stating that this was due to a limitation in Stacks itself, we felt it was prudent to clarify this.
On the same day as the incident, Adriano Di Luzio, CTO for Bitcoin L2 Labs, the largest core development contributor in the ecosystem stated the following: “I'm glad to see quick action by the ALEX team to resolve the situation for users, but want to be very clear: it is not a Stacks limitation or vulnerability that caused this exploit.”
We concur with this assessment and will further add that it is known in the current design of Clarity and many other smart contract languages that an application needs to verify the content of a contract and implement other security measures to protect the application in depth. ALEX’s contract relies on the was-tx-mined-compact function, which indicates whether a transaction was mined in a block while making no claims about the execution of that transaction. You can also learn more about how the exploit was potentially implemented by reading this community member’s assessment, though an official post-mortem has not yet been provided. We will update this post with a link to a formal post-mortem when ALEX provides one.
Fundamentally, this was an issue with ALEX’s smart contract implementation, and it is unreasonable to attribute responsibility to the protocol. If this were a protocol problem, all applications like ALEX would be vulnerable to it, and they are not. You will see the same design choice in other ecosystems related to failed transactions as well, with applications consistently taking this (and many other aspects of the protocol’s design) into account when implementing their smart contracts. Other decentralized exchanges on Stacks have successfully implemented their contracts without this type of vulnerability.
The Stacks ecosystem has a number of security and auditing firms actively engaged with the protocol and many more that are readily available to builders.
Thank you to the community members who helped identify this early on, the many who have supported ALEX during this time to mitigate impact, and the ALEX team for their swift action and ongoing efforts to make users whole. Given this is an app-level issue and firmly not a protocol-wide vulnerability, we will continue to defer to ALEX to provide further updates.