[GUEST ACCESS MODE: Data is scrambled or limited to provide examples. Make requests using your API key to unlock full data. Check https://lunarcrush.ai/auth for authentication information.]  ALEX 🟧 No. X Bitcoin DeFi [@ALEXLabBTC](/creator/twitter/ALEXLabBTC) on x 111.1K followers Created: 2025-06-12 03:03:11 UTC Analysis of June X Security Incident Summary: On June 6, 2025, the ALEX protocol experienced a security incident resulting in the loss of approximately $XXXX million in user funds. Detailed token amounts affected have been transparently documented here 🔗 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: X. Standard Pool Creation (create): For pre-approved tokens with whitelisted token-x requirements and standard security checks X. 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: X. 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 (Block #1508036, Nonce: 2, Status: Failed). X. Malicious Contract Deployment: The attacker then deployed a malicious contract with exactly the same name as the previous failed-to-deploy contract (Block #1508036, Nonce: 3). X. Underlying Token Deployment: The attacker deployed the underlying token 🔗 (Block #1508037, Nonce: 4). X. 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 (Block #1508061, Nonce: 5). X. 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 🔗 (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 $XXXX 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 XXX% reimbursement. Affected users can claim reimbursements via the official platform here 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: X critical, X high, X medium severity issues found • Findings: X low severity issues (all resolved/mitigated) and X enhancement recommendations (implemented) • Full Report: ALEX Self-Listing Pool Audit Report 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: X. Enhanced Smart Contract Security: Deployment of code patches and verification enhancements. X. Expanded Audit Scope: Future audits will involve multiple independent security firms targeting complex transaction scenarios and potential edge cases. X. Improved Monitoring: Strengthened real-time monitoring infrastructure to detect and respond to anomalous activities. X. 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 🔗 • Proposal by Drinknu 🔗 X. Reinforced User Protection: Ongoing transparency in reimbursements, regular community updates, and user education initiatives. X. Protocol Reopening: The ALEX protocol is scheduled to reopen as early as Monday next week, resuming key functionalities including: • Swap • Pool • Stake • Surge X 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.  XXXXX engagements  **Related Topics** [token](/topic/token) [protocol](/topic/protocol) [bitcoin](/topic/bitcoin) [coins layer 1](/topic/coins-layer-1) [coins bitcoin ecosystem](/topic/coins-bitcoin-ecosystem) [coins pow](/topic/coins-pow) [Post Link](https://x.com/ALEXLabBTC/status/1932997079237857729)
[GUEST ACCESS MODE: Data is scrambled or limited to provide examples. Make requests using your API key to unlock full data. Check https://lunarcrush.ai/auth for authentication information.]
ALEX 🟧 No. X Bitcoin DeFi @ALEXLabBTC on x 111.1K followers
Created: 2025-06-12 03:03:11 UTC
Analysis of June X Security Incident
Summary: On June 6, 2025, the ALEX protocol experienced a security incident resulting in the loss of approximately $XXXX million in user funds. Detailed token amounts affected have been transparently documented here 🔗 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: X. Standard Pool Creation (create): For pre-approved tokens with whitelisted token-x requirements and standard security checks X. 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: X. 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 (Block #1508036, Nonce: 2, Status: Failed). X. Malicious Contract Deployment: The attacker then deployed a malicious contract with exactly the same name as the previous failed-to-deploy contract (Block #1508036, Nonce: 3). X. Underlying Token Deployment: The attacker deployed the underlying token 🔗 (Block #1508037, Nonce: 4). X. 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 (Block #1508061, Nonce: 5). X. 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 🔗 (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 $XXXX 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 XXX% reimbursement. Affected users can claim reimbursements via the official platform here 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: X critical, X high, X medium severity issues found • Findings: X low severity issues (all resolved/mitigated) and X enhancement recommendations (implemented) • Full Report: ALEX Self-Listing Pool Audit Report
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: X. Enhanced Smart Contract Security: Deployment of code patches and verification enhancements. X. Expanded Audit Scope: Future audits will involve multiple independent security firms targeting complex transaction scenarios and potential edge cases. X. Improved Monitoring: Strengthened real-time monitoring infrastructure to detect and respond to anomalous activities. X. 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 🔗 • Proposal by Drinknu 🔗 X. Reinforced User Protection: Ongoing transparency in reimbursements, regular community updates, and user education initiatives. X. Protocol Reopening: The ALEX protocol is scheduled to reopen as early as Monday next week, resuming key functionalities including: • Swap • Pool • Stake • Surge X 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.
XXXXX engagements
Related Topics token protocol bitcoin coins layer 1 coins bitcoin ecosystem coins pow