![ALEXLabBTC's tweet photo. Analysis of June 6 Security Incident
Summary:
On June 6, 2025, the ALEX protocol experienced a security incident resulting in the loss of approximately $8.37 million in user funds. Detailed token amounts affected have been transparently documented here 🔗 https://t.co/EykdkjujSc. The exploit was promptly contained, and immediate action was taken to ensure all affected users are fully reimbursed.
----------------------------------
Timeline of Events:
• Around 9:30am UTC on June 6: Suspicious transaction activity detected.
• [Immediate Response]: ALEX development team began immediate investigation.
• [Shortly After]: Vulnerability confirmed; emergency measures activated, including pausing affected smart contracts.
• [Same Day]: Public announcement issued through official channels.
• [Following Day]: Treasury Grant Program activated to fully reimburse all affected users.
• [Ongoing]: Comprehensive investigation and detailed post-mortem analysis initiated.
----------------------------------
Root Cause:
The exploit originated from a vulnerability within the verification logic of the self-listing feature. This feature was introduced at the community's request, reflecting ALEX's commitment to decentralization by enabling open, permissionless token listings. However, the self-listing mechanism contained a subtle yet critical flaw.
----------------------------------
Technical Details of the Exploit:
Contract Overview - The exploit targeted ALEX's Self-Listing Helper contract, a smart contract that enables both permissioned and permissionless creation of AMM (Automated Market Maker) pools on the Stacks blockchain. This contract features two main pool creation functions:
1. Standard Pool Creation (create): For pre-approved tokens with whitelisted token-x requirements and standard security checks
2. Permissionless Pool Creation (create2): Allows creation of pools with new, unregistered tokens through a comprehensive verification system that:
• Verifies the token contract deployment on Stacks blockchain
• Checks contract code matches an approved template
• Validates deployment proof using Stacks block headers
• Takes deployment transaction proof from Stacks blockchain
• Verifies the contract code matches a whitelisted template
• Confirms the deployment transaction was properly mined
The Attack Vector: The attacker exploited a critical flaw in the create2 function's verification logic by referencing a failed transaction, allowing a malicious token to bypass checks and transfer funds from liquidity pools. The core issue stems from a current on-chain limitation, specifically the inability to reliably detect failed transactions in Clarity, the smart contract language used on Stacks.
Step-by-Step Attack Sequence:
1. Failed Contract Deployment: The attacker deployed a non-malicious, approved template-conforming contract, but before deploying the underlying unregistered token. This contract deployment failed due to the non-existent underlying token, but critically, the transaction itself was mined 🔗https://t.co/dvqNowccib (Block #1508036, Nonce: 2, Status: Failed).
2. Malicious Contract Deployment: The attacker then deployed a malicious contract with exactly the same name as the previous failed-to-deploy contract 🔗https://t.co/sPWruUACHR (Block #1508036, Nonce: 3).
3. Underlying Token Deployment: The attacker deployed the underlying token 🔗 https://t.co/iWIWLtU5UP (Block #1508037, Nonce: 4).
4. Verification Bypass: The attacker called create2 with the information from the first, failed deployment in the verify-params. The contract's verify-deploy mechanism verified that the transaction was mined using the clarity-stacks library, but crucially could not determine if the mined transaction was successful or failed, nor if there were other deployments of the same name. With the deployment verified as "successfully mined" (though actually failed), it was approved for use on ALEX AMM 🔗https://t.co/zebhPgzzks (Block #1508061, Nonce: 5).
5. Unauthorized Withdrawals: With the malicious contract now approved for use on ALEX AMM, the attacker initiated the final attack by triggering unauthorized withdrawals from multiple liquidity pools 🔗 https://t.co/agGZbKTCek (Block #1508068, Nonce: 7).
Technical Root Cause: The vulnerability stems from how the Stacks blockchain and Clarity VM handle transaction states. Failed transactions, while not successfully executed, still appear as mined transactions. The contract's verification system could confirm that a deployment transaction was mined but could not distinguish between a successful deployment and a failed one, allowing the attacker to reference the failed transaction as "proof" of legitimate contract deployment while actually using a different malicious contract with the same name.
This vulnerability highlights a fundamental architectural challenge: while Bitcoin provides unparalleled security at the base layer, implementing complex verification systems on Stacks requires careful consideration of how the Clarity VM handles transaction states. The inability to reliably distinguish between failed and successful transactions in certain contexts creates edge cases that sophisticated attackers can exploit.
----------------------------------
Impact:
• Total Exploited Funds: Approximately $8.37 million
• Affected Assets: Multiple user-held tokens across various liquidity pools
• Containment: Prompt action prevented further loss
• Full User Reimbursement: Immediately activated • Treasury Grant Program ensures complete financial recovery for all affected users
----------------------------------
Immediate Response and User Reimbursement:
ALEX accepted responsibility for this incident and enacted the Treasury Grant Program. All impacted users will receive 100% reimbursement. Affected users can claim reimbursements via the official platform here 🔗https://t.co/woSZ9hv4ow. The protocol's priority is the security of user assets and the integrity of user trust.
----------------------------------
External Audits and Security Practices:
ALEX engaged with CoinFabrik for security reviews. CoinFabrik conducted audits across all major protocol features, including the self-listing functionality.
CoinFabrik Audit Summary (February 2025):
• Scope: Self-listing pool functionality, transaction verification logic, and core smart contracts
• Results: 0 critical, 0 high, 0 medium severity issues found
• Findings: 4 low severity issues (all resolved/mitigated) and 2 enhancement recommendations (implemented)
• Full Report: ALEX Self-Listing Pool Audit Report 🔗https://t.co/VBJoRribHG
All recommendations were implemented prior to deployment. However, this exploit highlights that while audits significantly reduce risk and validate secure coding practices, they cannot eliminate risks stemming from blockchain infrastructure limitations. The failed transaction detection vulnerability represents an edge case within how the Stacks blockchain and Clarity VM handle transaction states that was not previously documented or anticipated in standard security audit frameworks.
----------------------------------
Lessons Learned:
• Explicitly define and rigorously test all assumptions about blockchain virtual machine (VM) behaviors.
• Ensure security audits explicitly cover and challenge edge-case scenarios.
• Exercise heightened caution when implementing decentralization-driven features, given inherent complexity and unknown interactions.
• Foster close collaboration with core platform developers and security experts to proactively identify and resolve unforeseen vulnerabilities.
----------------------------------
Steps Forward:
ALEX Protocol is taking steps to strengthen security:
1. Enhanced Smart Contract Security: Deployment of code patches and verification enhancements.
2. Expanded Audit Scope: Future audits will involve multiple independent security firms targeting complex transaction scenarios and potential edge cases.
3. Improved Monitoring: Strengthened real-time monitoring infrastructure to detect and respond to anomalous activities.
4. Platform-Level Advocacy and Collaboration: Collaborating with Stacks blockchain developers to address and resolve VM limitations. Notable proposals currently under review:
• Proposal by Marvin Janssen 🔗 https://t.co/Bpo0gQcQJE
• Proposal by Drinknu 🔗 https://t.co/ybISHaOTJz
5. Reinforced User Protection: Ongoing transparency in reimbursements, regular community updates, and user education initiatives.
6. Protocol Reopening: The ALEX protocol is scheduled to reopen as early as Monday next week, resuming key functionalities including:
• Swap
• Pool
• Stake
• Surge 4 Claim Voting Rewards
• Vote
• Treasury Grant Program
----------------------------------
Acknowledgements:
We extend our deepest gratitude to community members for their patience, support, and trust during this challenging moment. We also thank CoinFabrik for their auditing efforts, the Stacks core development team for their ongoing collaboration and support, and the security researchers who contributed insights and analysis.
Stacks remains a young, evolving blockchain ecosystem, and ALEX is deeply committed to its growth. We take seriously our responsibility as one of the first and largest DeFi protocols on Stacks, and we remain committed to our mission: to cultivate a secure, robust, and thriving decentralized finance ecosystem.](https://pbs.twimg.com/media/GtNiIaUXEAAJjaW.jpg)
![ALEXLabBTC's tweet photo. Analysis of June 6 Security Incident
Summary:
On June 6, 2025, the ALEX protocol experienced a security incident resulting in the loss of approximately $8.37 million in user funds. Detailed token amounts affected have been transparently documented here 🔗 https://t.co/EykdkjujSc. The exploit was promptly contained, and immediate action was taken to ensure all affected users are fully reimbursed.
----------------------------------
Timeline of Events:
• Around 9:30am UTC on June 6: Suspicious transaction activity detected.
• [Immediate Response]: ALEX development team began immediate investigation.
• [Shortly After]: Vulnerability confirmed; emergency measures activated, including pausing affected smart contracts.
• [Same Day]: Public announcement issued through official channels.
• [Following Day]: Treasury Grant Program activated to fully reimburse all affected users.
• [Ongoing]: Comprehensive investigation and detailed post-mortem analysis initiated.
----------------------------------
Root Cause:
The exploit originated from a vulnerability within the verification logic of the self-listing feature. This feature was introduced at the community's request, reflecting ALEX's commitment to decentralization by enabling open, permissionless token listings. However, the self-listing mechanism contained a subtle yet critical flaw.
----------------------------------
Technical Details of the Exploit:
Contract Overview - The exploit targeted ALEX's Self-Listing Helper contract, a smart contract that enables both permissioned and permissionless creation of AMM (Automated Market Maker) pools on the Stacks blockchain. This contract features two main pool creation functions:
1. Standard Pool Creation (create): For pre-approved tokens with whitelisted token-x requirements and standard security checks
2. Permissionless Pool Creation (create2): Allows creation of pools with new, unregistered tokens through a comprehensive verification system that:
• Verifies the token contract deployment on Stacks blockchain
• Checks contract code matches an approved template
• Validates deployment proof using Stacks block headers
• Takes deployment transaction proof from Stacks blockchain
• Verifies the contract code matches a whitelisted template
• Confirms the deployment transaction was properly mined
The Attack Vector: The attacker exploited a critical flaw in the create2 function's verification logic by referencing a failed transaction, allowing a malicious token to bypass checks and transfer funds from liquidity pools. The core issue stems from a current on-chain limitation, specifically the inability to reliably detect failed transactions in Clarity, the smart contract language used on Stacks.
Step-by-Step Attack Sequence:
1. Failed Contract Deployment: The attacker deployed a non-malicious, approved template-conforming contract, but before deploying the underlying unregistered token. This contract deployment failed due to the non-existent underlying token, but critically, the transaction itself was mined 🔗https://t.co/dvqNowccib (Block #1508036, Nonce: 2, Status: Failed).
2. Malicious Contract Deployment: The attacker then deployed a malicious contract with exactly the same name as the previous failed-to-deploy contract 🔗https://t.co/sPWruUACHR (Block #1508036, Nonce: 3).
3. Underlying Token Deployment: The attacker deployed the underlying token 🔗 https://t.co/iWIWLtU5UP (Block #1508037, Nonce: 4).
4. Verification Bypass: The attacker called create2 with the information from the first, failed deployment in the verify-params. The contract's verify-deploy mechanism verified that the transaction was mined using the clarity-stacks library, but crucially could not determine if the mined transaction was successful or failed, nor if there were other deployments of the same name. With the deployment verified as "successfully mined" (though actually failed), it was approved for use on ALEX AMM 🔗https://t.co/zebhPgzzks (Block #1508061, Nonce: 5).
5. Unauthorized Withdrawals: With the malicious contract now approved for use on ALEX AMM, the attacker initiated the final attack by triggering unauthorized withdrawals from multiple liquidity pools 🔗 https://t.co/agGZbKTCek (Block #1508068, Nonce: 7).
Technical Root Cause: The vulnerability stems from how the Stacks blockchain and Clarity VM handle transaction states. Failed transactions, while not successfully executed, still appear as mined transactions. The contract's verification system could confirm that a deployment transaction was mined but could not distinguish between a successful deployment and a failed one, allowing the attacker to reference the failed transaction as "proof" of legitimate contract deployment while actually using a different malicious contract with the same name.
This vulnerability highlights a fundamental architectural challenge: while Bitcoin provides unparalleled security at the base layer, implementing complex verification systems on Stacks requires careful consideration of how the Clarity VM handles transaction states. The inability to reliably distinguish between failed and successful transactions in certain contexts creates edge cases that sophisticated attackers can exploit.
----------------------------------
Impact:
• Total Exploited Funds: Approximately $8.37 million
• Affected Assets: Multiple user-held tokens across various liquidity pools
• Containment: Prompt action prevented further loss
• Full User Reimbursement: Immediately activated • Treasury Grant Program ensures complete financial recovery for all affected users
----------------------------------
Immediate Response and User Reimbursement:
ALEX accepted responsibility for this incident and enacted the Treasury Grant Program. All impacted users will receive 100% reimbursement. Affected users can claim reimbursements via the official platform here 🔗https://t.co/woSZ9hv4ow. The protocol's priority is the security of user assets and the integrity of user trust.
----------------------------------
External Audits and Security Practices:
ALEX engaged with CoinFabrik for security reviews. CoinFabrik conducted audits across all major protocol features, including the self-listing functionality.
CoinFabrik Audit Summary (February 2025):
• Scope: Self-listing pool functionality, transaction verification logic, and core smart contracts
• Results: 0 critical, 0 high, 0 medium severity issues found
• Findings: 4 low severity issues (all resolved/mitigated) and 2 enhancement recommendations (implemented)
• Full Report: ALEX Self-Listing Pool Audit Report 🔗https://t.co/VBJoRribHG
All recommendations were implemented prior to deployment. However, this exploit highlights that while audits significantly reduce risk and validate secure coding practices, they cannot eliminate risks stemming from blockchain infrastructure limitations. The failed transaction detection vulnerability represents an edge case within how the Stacks blockchain and Clarity VM handle transaction states that was not previously documented or anticipated in standard security audit frameworks.
----------------------------------
Lessons Learned:
• Explicitly define and rigorously test all assumptions about blockchain virtual machine (VM) behaviors.
• Ensure security audits explicitly cover and challenge edge-case scenarios.
• Exercise heightened caution when implementing decentralization-driven features, given inherent complexity and unknown interactions.
• Foster close collaboration with core platform developers and security experts to proactively identify and resolve unforeseen vulnerabilities.
----------------------------------
Steps Forward:
ALEX Protocol is taking steps to strengthen security:
1. Enhanced Smart Contract Security: Deployment of code patches and verification enhancements.
2. Expanded Audit Scope: Future audits will involve multiple independent security firms targeting complex transaction scenarios and potential edge cases.
3. Improved Monitoring: Strengthened real-time monitoring infrastructure to detect and respond to anomalous activities.
4. Platform-Level Advocacy and Collaboration: Collaborating with Stacks blockchain developers to address and resolve VM limitations. Notable proposals currently under review:
• Proposal by Marvin Janssen 🔗 https://t.co/Bpo0gQcQJE
• Proposal by Drinknu 🔗 https://t.co/ybISHaOTJz
5. Reinforced User Protection: Ongoing transparency in reimbursements, regular community updates, and user education initiatives.
6. Protocol Reopening: The ALEX protocol is scheduled to reopen as early as Monday next week, resuming key functionalities including:
• Swap
• Pool
• Stake
• Surge 4 Claim Voting Rewards
• Vote
• Treasury Grant Program
----------------------------------
Acknowledgements:
We extend our deepest gratitude to community members for their patience, support, and trust during this challenging moment. We also thank CoinFabrik for their auditing efforts, the Stacks core development team for their ongoing collaboration and support, and the security researchers who contributed insights and analysis.
Stacks remains a young, evolving blockchain ecosystem, and ALEX is deeply committed to its growth. We take seriously our responsibility as one of the first and largest DeFi protocols on Stacks, and we remain committed to our mission: to cultivate a secure, robust, and thriving decentralized finance ecosystem.](https://pbs.twimg.com/media/GtNiGodWUAANrmo.png)
Olivia
Online
Cryptonia
@Crypton75275186
I'm a professional Cryptographer and I come in peace from the planet Crypton.
Duh! Crypton
Joined February 2022
138 Following
86 Followers
632 Posts
@Davincij15 A juicy wagyu steak
STX-ALEX Pool Open
The STX-ALEX pool is now live as we continue a progressive re-opening of ALEX AMM.
Additional pools will follow as community members reach out to supply liquidity.
We’re grateful for your continued support as we restore operations.
ALEX Protocol Treasury Grant Program: Support for Affected Users
Following the security exploit on June 6, 2025, ALEX Lab has launched a comprehensive Treasury Grant Program to provide financial support to users who lost funds in the incident. ALEX remains committed to supporting its community and helping users recover during this challenging time.
Understanding the Exploit:
On June 6, 2025, at approximately 10:00 UTC, ALEX Protocol experienced a security exploit that resulted in the unauthorized removal of digital assets from several liquidity pools. The total affected assets include:
• 8,403,867.57 STX
• 21.85 sBTC
• 149,850.00 aUSD
• 2.80 aBTC
These assets, referred to as "Lost Affected Assets," were taken by exploiters and remain unrecovered as of the program launch.
Grant Structure:
The Treasury Grant Program offers a mixed support approach, providing both original tokens and USDC equivalent based on the asset type:
STX Holdings
• 100% coverage in USDC
• Exchange rate: 0.68 USDC per STX
sBTC Holdings
• 100% coverage in aBTC
• Exchange rate: 1 aBTC per sBTC
aBTC Holdings
• 75% returned as aBTC (original token)
• 25% converted to USDC at 102,734 USDC per aBTC
aUSD Holdings
• 91% returned as aUSD (original token)
• 9% converted to USDC at 1.00 USDC per aUSD
Program Timeline:
• Grant Distribution: Support payments will be distributed to eligible users' Ethereum addresses no later than June 17, 2025, 23:59 UTC
• Acceptance Deadline: Users must accept their grants by a date to be announced through official channels
How to Participate:
1. Visit the Interface: Access the program through the official ALEX Lab website
2. Connect Your Wallet: Link the affected wallet address to the Grant Smart Contracts
3. Review Grant Offer: Examine the support calculation for your specific losses
4. Accept Terms: Sign the confirmation message to accept the grant and terms
Terms and Conditions:
Participation in the Treasury Grant Program is subject to acceptance of the program's Terms and Conditions, which include important legal provisions, participant obligations, and program requirements.
Please review the complete Terms and Conditions at: https://t.co/LuGjI0XPRH
By participating in this program, users agree to be bound by these terms.
Official Communication Channels:
Keep updated on program developments through ALEX's official channels:
• Website: https://t.co/kTvQFu0EqC
• Twitter/X: @ALEXLabBTC
• Discord: https://t.co/vXFx4PCYdo
• Telegram: https://t.co/pCtgI5svmN
Support and Questions:
For program-related inquiries, users can contact ALEX Lab at [email protected]. All communications regarding the Treasury Grant Program will be conducted through official channels only.
The Treasury Grant Program affirms ALEX Lab’s responsibility to its users and its ongoing efforts to ensure protocol recovery and resilience. Users are encouraged to carefully review all terms and consider seeking independent legal or financial advice before participating.
Important Notice: This program has specific deadlines and legal implications. Ensure you understand all terms before accepting any grants.
@ALEXLabBTC All hearts 💕
Analysis of June 6 Security Incident
Summary:
On June 6, 2025, the ALEX protocol experienced a security incident resulting in the loss of approximately $8.37 million in user funds. Detailed token amounts affected have been transparently documented here 🔗 https://t.co/EykdkjujSc. The exploit was promptly contained, and immediate action was taken to ensure all affected users are fully reimbursed.
----------------------------------
Timeline of Events:
• Around 9:30am UTC on June 6: Suspicious transaction activity detected.
• [Immediate Response]: ALEX development team began immediate investigation.
• [Shortly After]: Vulnerability confirmed; emergency measures activated, including pausing affected smart contracts.
• [Same Day]: Public announcement issued through official channels.
• [Following Day]: Treasury Grant Program activated to fully reimburse all affected users.
• [Ongoing]: Comprehensive investigation and detailed post-mortem analysis initiated.
----------------------------------
Root Cause:
The exploit originated from a vulnerability within the verification logic of the self-listing feature. This feature was introduced at the community's request, reflecting ALEX's commitment to decentralization by enabling open, permissionless token listings. However, the self-listing mechanism contained a subtle yet critical flaw.
----------------------------------
Technical Details of the Exploit:
Contract Overview - The exploit targeted ALEX's Self-Listing Helper contract, a smart contract that enables both permissioned and permissionless creation of AMM (Automated Market Maker) pools on the Stacks blockchain. This contract features two main pool creation functions:
1. Standard Pool Creation (create): For pre-approved tokens with whitelisted token-x requirements and standard security checks
2. Permissionless Pool Creation (create2): Allows creation of pools with new, unregistered tokens through a comprehensive verification system that:
• Verifies the token contract deployment on Stacks blockchain
• Checks contract code matches an approved template
• Validates deployment proof using Stacks block headers
• Takes deployment transaction proof from Stacks blockchain
• Verifies the contract code matches a whitelisted template
• Confirms the deployment transaction was properly mined
The Attack Vector: The attacker exploited a critical flaw in the create2 function's verification logic by referencing a failed transaction, allowing a malicious token to bypass checks and transfer funds from liquidity pools. The core issue stems from a current on-chain limitation, specifically the inability to reliably detect failed transactions in Clarity, the smart contract language used on Stacks.
Step-by-Step Attack Sequence:
1. Failed Contract Deployment: The attacker deployed a non-malicious, approved template-conforming contract, but before deploying the underlying unregistered token. This contract deployment failed due to the non-existent underlying token, but critically, the transaction itself was mined 🔗https://t.co/dvqNowccib (Block #1508036, Nonce: 2, Status: Failed).
2. Malicious Contract Deployment: The attacker then deployed a malicious contract with exactly the same name as the previous failed-to-deploy contract 🔗https://t.co/sPWruUACHR (Block #1508036, Nonce: 3).
3. Underlying Token Deployment: The attacker deployed the underlying token 🔗 https://t.co/iWIWLtU5UP (Block #1508037, Nonce: 4).
4. Verification Bypass: The attacker called create2 with the information from the first, failed deployment in the verify-params. The contract's verify-deploy mechanism verified that the transaction was mined using the clarity-stacks library, but crucially could not determine if the mined transaction was successful or failed, nor if there were other deployments of the same name. With the deployment verified as "successfully mined" (though actually failed), it was approved for use on ALEX AMM 🔗https://t.co/zebhPgzzks (Block #1508061, Nonce: 5).
5. Unauthorized Withdrawals: With the malicious contract now approved for use on ALEX AMM, the attacker initiated the final attack by triggering unauthorized withdrawals from multiple liquidity pools 🔗 https://t.co/agGZbKTCek (Block #1508068, Nonce: 7).
Technical Root Cause: The vulnerability stems from how the Stacks blockchain and Clarity VM handle transaction states. Failed transactions, while not successfully executed, still appear as mined transactions. The contract's verification system could confirm that a deployment transaction was mined but could not distinguish between a successful deployment and a failed one, allowing the attacker to reference the failed transaction as "proof" of legitimate contract deployment while actually using a different malicious contract with the same name.
This vulnerability highlights a fundamental architectural challenge: while Bitcoin provides unparalleled security at the base layer, implementing complex verification systems on Stacks requires careful consideration of how the Clarity VM handles transaction states. The inability to reliably distinguish between failed and successful transactions in certain contexts creates edge cases that sophisticated attackers can exploit.
----------------------------------
Impact:
• Total Exploited Funds: Approximately $8.37 million
• Affected Assets: Multiple user-held tokens across various liquidity pools
• Containment: Prompt action prevented further loss
• Full User Reimbursement: Immediately activated • Treasury Grant Program ensures complete financial recovery for all affected users
----------------------------------
Immediate Response and User Reimbursement:
ALEX accepted responsibility for this incident and enacted the Treasury Grant Program. All impacted users will receive 100% reimbursement. Affected users can claim reimbursements via the official platform here 🔗https://t.co/woSZ9hv4ow. The protocol's priority is the security of user assets and the integrity of user trust.
----------------------------------
External Audits and Security Practices:
ALEX engaged with CoinFabrik for security reviews. CoinFabrik conducted audits across all major protocol features, including the self-listing functionality.
CoinFabrik Audit Summary (February 2025):
• Scope: Self-listing pool functionality, transaction verification logic, and core smart contracts
• Results: 0 critical, 0 high, 0 medium severity issues found
• Findings: 4 low severity issues (all resolved/mitigated) and 2 enhancement recommendations (implemented)
• Full Report: ALEX Self-Listing Pool Audit Report 🔗https://t.co/VBJoRribHG
All recommendations were implemented prior to deployment. However, this exploit highlights that while audits significantly reduce risk and validate secure coding practices, they cannot eliminate risks stemming from blockchain infrastructure limitations. The failed transaction detection vulnerability represents an edge case within how the Stacks blockchain and Clarity VM handle transaction states that was not previously documented or anticipated in standard security audit frameworks.
----------------------------------
Lessons Learned:
• Explicitly define and rigorously test all assumptions about blockchain virtual machine (VM) behaviors.
• Ensure security audits explicitly cover and challenge edge-case scenarios.
• Exercise heightened caution when implementing decentralization-driven features, given inherent complexity and unknown interactions.
• Foster close collaboration with core platform developers and security experts to proactively identify and resolve unforeseen vulnerabilities.
----------------------------------
Steps Forward:
ALEX Protocol is taking steps to strengthen security:
1. Enhanced Smart Contract Security: Deployment of code patches and verification enhancements.
2. Expanded Audit Scope: Future audits will involve multiple independent security firms targeting complex transaction scenarios and potential edge cases.
3. Improved Monitoring: Strengthened real-time monitoring infrastructure to detect and respond to anomalous activities.
4. Platform-Level Advocacy and Collaboration: Collaborating with Stacks blockchain developers to address and resolve VM limitations. Notable proposals currently under review:
• Proposal by Marvin Janssen 🔗 https://t.co/Bpo0gQcQJE
• Proposal by Drinknu 🔗 https://t.co/ybISHaOTJz
5. Reinforced User Protection: Ongoing transparency in reimbursements, regular community updates, and user education initiatives.
6. Protocol Reopening: The ALEX protocol is scheduled to reopen as early as Monday next week, resuming key functionalities including:
• Swap
• Pool
• Stake
• Surge 4 Claim Voting Rewards
• Vote
• Treasury Grant Program
----------------------------------
Acknowledgements:
We extend our deepest gratitude to community members for their patience, support, and trust during this challenging moment. We also thank CoinFabrik for their auditing efforts, the Stacks core development team for their ongoing collaboration and support, and the security researchers who contributed insights and analysis.
Stacks remains a young, evolving blockchain ecosystem, and ALEX is deeply committed to its growth. We take seriously our responsibility as one of the first and largest DeFi protocols on Stacks, and we remain committed to our mission: to cultivate a secure, robust, and thriving decentralized finance ecosystem.
![ALEXLabBTC's tweet photo. Analysis of June 6 Security Incident
Summary:
On June 6, 2025, the ALEX protocol experienced a security incident resulting in the loss of approximately $8.37 million in user funds. Detailed token amounts affected have been transparently documented here 🔗 https://t.co/EykdkjujSc. The exploit was promptly contained, and immediate action was taken to ensure all affected users are fully reimbursed.
----------------------------------
Timeline of Events:
• Around 9:30am UTC on June 6: Suspicious transaction activity detected.
• [Immediate Response]: ALEX development team began immediate investigation.
• [Shortly After]: Vulnerability confirmed; emergency measures activated, including pausing affected smart contracts.
• [Same Day]: Public announcement issued through official channels.
• [Following Day]: Treasury Grant Program activated to fully reimburse all affected users.
• [Ongoing]: Comprehensive investigation and detailed post-mortem analysis initiated.
----------------------------------
Root Cause:
The exploit originated from a vulnerability within the verification logic of the self-listing feature. This feature was introduced at the community's request, reflecting ALEX's commitment to decentralization by enabling open, permissionless token listings. However, the self-listing mechanism contained a subtle yet critical flaw.
----------------------------------
Technical Details of the Exploit:
Contract Overview - The exploit targeted ALEX's Self-Listing Helper contract, a smart contract that enables both permissioned and permissionless creation of AMM (Automated Market Maker) pools on the Stacks blockchain. This contract features two main pool creation functions:
1. Standard Pool Creation (create): For pre-approved tokens with whitelisted token-x requirements and standard security checks
2. Permissionless Pool Creation (create2): Allows creation of pools with new, unregistered tokens through a comprehensive verification system that:
• Verifies the token contract deployment on Stacks blockchain
• Checks contract code matches an approved template
• Validates deployment proof using Stacks block headers
• Takes deployment transaction proof from Stacks blockchain
• Verifies the contract code matches a whitelisted template
• Confirms the deployment transaction was properly mined
The Attack Vector: The attacker exploited a critical flaw in the create2 function's verification logic by referencing a failed transaction, allowing a malicious token to bypass checks and transfer funds from liquidity pools. The core issue stems from a current on-chain limitation, specifically the inability to reliably detect failed transactions in Clarity, the smart contract language used on Stacks.
Step-by-Step Attack Sequence:
1. Failed Contract Deployment: The attacker deployed a non-malicious, approved template-conforming contract, but before deploying the underlying unregistered token. This contract deployment failed due to the non-existent underlying token, but critically, the transaction itself was mined 🔗https://t.co/dvqNowccib (Block #1508036, Nonce: 2, Status: Failed).
2. Malicious Contract Deployment: The attacker then deployed a malicious contract with exactly the same name as the previous failed-to-deploy contract 🔗https://t.co/sPWruUACHR (Block #1508036, Nonce: 3).
3. Underlying Token Deployment: The attacker deployed the underlying token 🔗 https://t.co/iWIWLtU5UP (Block #1508037, Nonce: 4).
4. Verification Bypass: The attacker called create2 with the information from the first, failed deployment in the verify-params. The contract's verify-deploy mechanism verified that the transaction was mined using the clarity-stacks library, but crucially could not determine if the mined transaction was successful or failed, nor if there were other deployments of the same name. With the deployment verified as "successfully mined" (though actually failed), it was approved for use on ALEX AMM 🔗https://t.co/zebhPgzzks (Block #1508061, Nonce: 5).
5. Unauthorized Withdrawals: With the malicious contract now approved for use on ALEX AMM, the attacker initiated the final attack by triggering unauthorized withdrawals from multiple liquidity pools 🔗 https://t.co/agGZbKTCek (Block #1508068, Nonce: 7).
Technical Root Cause: The vulnerability stems from how the Stacks blockchain and Clarity VM handle transaction states. Failed transactions, while not successfully executed, still appear as mined transactions. The contract's verification system could confirm that a deployment transaction was mined but could not distinguish between a successful deployment and a failed one, allowing the attacker to reference the failed transaction as "proof" of legitimate contract deployment while actually using a different malicious contract with the same name.
This vulnerability highlights a fundamental architectural challenge: while Bitcoin provides unparalleled security at the base layer, implementing complex verification systems on Stacks requires careful consideration of how the Clarity VM handles transaction states. The inability to reliably distinguish between failed and successful transactions in certain contexts creates edge cases that sophisticated attackers can exploit.
----------------------------------
Impact:
• Total Exploited Funds: Approximately $8.37 million
• Affected Assets: Multiple user-held tokens across various liquidity pools
• Containment: Prompt action prevented further loss
• Full User Reimbursement: Immediately activated • Treasury Grant Program ensures complete financial recovery for all affected users
----------------------------------
Immediate Response and User Reimbursement:
ALEX accepted responsibility for this incident and enacted the Treasury Grant Program. All impacted users will receive 100% reimbursement. Affected users can claim reimbursements via the official platform here 🔗https://t.co/woSZ9hv4ow. The protocol's priority is the security of user assets and the integrity of user trust.
----------------------------------
External Audits and Security Practices:
ALEX engaged with CoinFabrik for security reviews. CoinFabrik conducted audits across all major protocol features, including the self-listing functionality.
CoinFabrik Audit Summary (February 2025):
• Scope: Self-listing pool functionality, transaction verification logic, and core smart contracts
• Results: 0 critical, 0 high, 0 medium severity issues found
• Findings: 4 low severity issues (all resolved/mitigated) and 2 enhancement recommendations (implemented)
• Full Report: ALEX Self-Listing Pool Audit Report 🔗https://t.co/VBJoRribHG
All recommendations were implemented prior to deployment. However, this exploit highlights that while audits significantly reduce risk and validate secure coding practices, they cannot eliminate risks stemming from blockchain infrastructure limitations. The failed transaction detection vulnerability represents an edge case within how the Stacks blockchain and Clarity VM handle transaction states that was not previously documented or anticipated in standard security audit frameworks.
----------------------------------
Lessons Learned:
• Explicitly define and rigorously test all assumptions about blockchain virtual machine (VM) behaviors.
• Ensure security audits explicitly cover and challenge edge-case scenarios.
• Exercise heightened caution when implementing decentralization-driven features, given inherent complexity and unknown interactions.
• Foster close collaboration with core platform developers and security experts to proactively identify and resolve unforeseen vulnerabilities.
----------------------------------
Steps Forward:
ALEX Protocol is taking steps to strengthen security:
1. Enhanced Smart Contract Security: Deployment of code patches and verification enhancements.
2. Expanded Audit Scope: Future audits will involve multiple independent security firms targeting complex transaction scenarios and potential edge cases.
3. Improved Monitoring: Strengthened real-time monitoring infrastructure to detect and respond to anomalous activities.
4. Platform-Level Advocacy and Collaboration: Collaborating with Stacks blockchain developers to address and resolve VM limitations. Notable proposals currently under review:
• Proposal by Marvin Janssen 🔗 https://t.co/Bpo0gQcQJE
• Proposal by Drinknu 🔗 https://t.co/ybISHaOTJz
5. Reinforced User Protection: Ongoing transparency in reimbursements, regular community updates, and user education initiatives.
6. Protocol Reopening: The ALEX protocol is scheduled to reopen as early as Monday next week, resuming key functionalities including:
• Swap
• Pool
• Stake
• Surge 4 Claim Voting Rewards
• Vote
• Treasury Grant Program
----------------------------------
Acknowledgements:
We extend our deepest gratitude to community members for their patience, support, and trust during this challenging moment. We also thank CoinFabrik for their auditing efforts, the Stacks core development team for their ongoing collaboration and support, and the security researchers who contributed insights and analysis.
Stacks remains a young, evolving blockchain ecosystem, and ALEX is deeply committed to its growth. We take seriously our responsibility as one of the first and largest DeFi protocols on Stacks, and we remain committed to our mission: to cultivate a secure, robust, and thriving decentralized finance ecosystem.](https://pbs.twimg.com/media/GtNiJ-fWEAAKueI.jpg)
@ALEXLabBTC Great initiative, must give praise where it's due.
Learn from mistakes (even if many), pick up the pieces move forward.
Easy to say ditch the coin but @ALEXLabBTC represents in small scale the innovation which is essential for long term sustainable growth of crypto industry
@elonmusk Considering the vastness of space & beyond, should also pursue small scale out of the box mad science projects based on entangled particles and thereby the elimination of distance between a pair across 'space and time'. Think beyond 4 Dimensions, jet propulsion is not the future.
@elonmusk We've all been there.. broken phone screen.
@elonmusk Really.. the fight's still on? It serves no purpose.. he exploits and will get max utility out of it whereas for you it doesn't make the world a better place and serves no purpose.
There are hundreds of high-profile cases of men suffering from false accusations.
There are thousands of untold stories of normal men having their lives destroyed.
I am launching a charity to protect men from this predatory evil.
Sign up: https://t.co/LRweBNqxcg
Watch the full Tales of Wudan video exclusively on Rumble:
https://t.co/xgvvXvFZbH
@Davincij15 Same as what I'm doing with the rest of my BTC. Absolutely nothing.
@Davincij15 You know it @Davincij15 being rich means nothing, only thing better is to by 'Richer' today than you were yesterday.
@TateTheTalisman @Cobratate You were always free in my opinion.. but now the matrix is (mentally) imprisoned due to their failed attack.
I shall celebrate with a cigar and increased plates at the gym 💪
@elonmusk Thnx for doing wht nobody else dared 2 do, that's wat v expect from @elonmusk. U'll face sever backlash frm celebs & social media giants as u start eliminating fake accounts & fake followers. Phoenix may burn 2 ashes but it'll rise with a stronger community & a transparent system
@carlmoon No I bought at 50K 🤓
@carlmoon If you're bored but rich but prefer to experience excitingly turbulent but broke try investing in LUNC 🤣 that's where hope goes to die.
Last Seen Users on Sotwe
Trends for you
Most Popular Users
Elon Musk 
@elonmusk
241.1M followers
Barack Obama
@barackobama
119.1M followers
Cristiano Ronaldo
@cristiano
112.5M followers
Donald J. Trump
@realdonaldtrump
111.8M followers
Narendra Modi
@narendramodi
107.1M followers
Rihanna
@rihanna
98.2M followers
NASA
@nasa
92.2M followers
Justin Bieber
@justinbieber
91.4M followers
KATY PERRY
@katyperry
88.7M followers
Taylor Swift
@taylorswift13
82.6M followers
Lady Gaga
@ladygaga
74.1M followers
Virat Kohli
@imvkohli
71.6M followers
Kim Kardashian
@kimkardashian
70.3M followers
YouTube
@youtube
68.7M followers
Bill Gates
@billgates
64.5M followers
Neymar Jr
@neymarjr
64.5M followers
The Ellen Show
@theellenshow
62.4M followers
CNN
@cnn
61.8M followers
Selena Gomez
@selenagomez
61.8M followers
X
@x
60.8M followers