The DotSwap V1, launched in 2024 under the identity of the "original exchange platform," had originally been classified by the officials as an “inactive” version of the old system. However, a security incident that occurred around October 25 has brought this name back into the spotlight. According to announcements from On Nexus and multiple media reports, the attackers did not target the current product line but rather exploited the legacy server-side signature path of V1, completing a whole operation in approximately 4 hours. A single source indicated that about 8.5 BTC was transferred from the custody multi-signature liquidity pool and related accounts of DotSwap V1, amounting to approximately $685,000 based on the valuation used in the announcement. These losses were ultimately borne by the liquidity providers who originally deposited BTC into the V1 liquidity pool. Even more glaring is the fact that, despite declaring V1 as "retired," the critical server-side signature mechanism still resides within the system as a legacy component, providing attackers with a ready-made entry point. Public materials have not disclosed the identity of the attackers or the subsequent on-chain flow of the funds, nor have they clarified whether this path has been completely closed. However, one lesson from this incident has been written in the bitcoin ecosystem's book of lessons: retirement does not equate to safety; as long as the custody multi-signature and server-side signatures remain in the system, the old protocol may still be a weak link for future attacks.
Retired Platform Becomes Breach: Legacy Signature Path Reactivated
On the surface, DotSwap V1 has been “retired” at the product line level, and the brand has completed its migration to On Nexus. However, this incident exposes the reality that a front-end marked as disabled does not mean its back-end has completely closed down. On Nexus and several media outlets have confirmed through public channels that this attack did not target the currently promoted On Nexus products, but rather directly utilized the legacy server-side signature path of DotSwap V1—this path, part of the server-side signature mechanism, remained available even after V1 was considered an old platform, effectively giving attackers an alternative operational channel to replace user signatures.
According to a single source description, the entire process from the initiation of the attack to its conclusion took about 4 hours—this pace suggests preparation rather than a spontaneous "hole-in-the-wall." To successfully complete multiple transactions and transfer about 8.5 BTC from DotSwap V1 liquidity pool and accounts within such a short timeframe, the attackers must have had a clear understanding of V1’s legacy signature mechanism, invocation methods, and authority scope. In contrast to the narrative that the product line had been moved to On Nexus and V1 was officially classified as “an inactive old platform,” this reality seems particularly ironic: as long as the server-side signature service behind the custody multi-signature continues to operate in the background, it may be "reactivated" at some point, transforming from a forgotten old version into the most vulnerable attack entry point in the entire protocol's security system.
Custody Multi-Signature Breach: Where LPs Were Exposed
For liquidity providers (LPs) who injected BTC into the DotSwap V1 pool, their positions were not traditional “self-custody.” The announcement has already indicated that the BTC in the V1 liquidity pool was managed uniformly by custody multi-signature, constituting a centralized custody structure between the pool and V1 accounts: LPs deposit their coins, which actually enter a multi-signature vault operated by the project team, rather than independent on-chain positions that they control. As long as this multi-signature remains operational, the server-side signature path is equivalent to a key to the vault; once breached, this layer of “lock” effectively becomes meaningless.
In this incident, the attackers exploited the legacy server-side signature mechanism to consecutively transfer about 8.5 BTC from the custody multi-signature managed V1 liquidity pool and V1 accounts. Formally, it appears that the multi-signature executed a legitimate transfer; in essence, the server-side signature process was replaced by the attackers’ intentions, allowing LP assets to be “represented” and signed away without their knowledge. The losses directly fell on all liquidity providers who deposited BTC into the V1 pool, yet public information neither indicated the number of affected LPs nor disclosed the distribution of losses among individual LPs, exposing a reality that has long been overlooked in a custody pool that was originally promoted as “more secure due to multi-signatures”: as long as there exists a server-side signature and centralized permissions in the multi-signature structure, LP risks encompass not only the on-chain contract logic risk but also a trust gamble on whether this server signature link can be completely closed.
DotSwap-On Nexus Security Debt Delays
Narratively, when DotSwap transformed into On Nexus, the story seemed clean: the old DotSwap V1 was labeled “inactive,” and the brand and flagship products fully migrated to the new platform, with users being informed that the current focus is on On Nexus; however, from a technical structure perspective, this migration resembles more a “facelift” than a total demolition of the old building. Announcements and media commentary point to a single weak link—the legacy server-side signature path of V1 has not been completely shut down, and this signature path, which should have retired along with V1, was ultimately discovered by attackers around October 25, becoming the critical entry point for the entire incident.
The result is that the product line that has completed its commercial narrative upgrade left behind an unresolved “security debt” from a technical perspective, and this debt is ultimately settled by the liquidity providers who deposited BTC into the V1 multi-signature pool and the users of the old accounts. More troublesome is that the current public materials do not clarify whether the remaining assets of V1 are completely secure, nor do they specifically state whether the legacy signature path has been completely closed. There is uncertainty over whether risks have been fully zeroed out or merely “muted,” making it impossible for external observers to judge. The fate of DotSwap V1 serves as a reminder to all protocols undergoing iteration and brand reshaping: if the old signature service and custody structure have not been simultaneously retired at the technical level, then a so-called “retired” platform is merely postponing the bookkeeping of security debt rather than truly erasing it from the balance sheet.
Custody and Autonomy Tension in Bitcoin Native DeFi
In the Bitcoin native DeFi space, many protocols have to strike a balance between “pure user self-custody” and “usable product experience”: on one end, users completely control their private keys, with on-chain logic being simple and transparent; on the other end, server-side signatures and custody multi-signatures are introduced, with operators helping to summarize instructions and batch-sign to reduce interaction frequency and complexity. DotSwap, being oriented toward Bitcoin native assets, inherently revolves around the signature and custody infrastructure of the Bitcoin layer; thus, V1 is described as relying on a server-side signature path and employing custody multi-signature to manage LP assets. This design reduces user barriers but shifts part of the security boundary from on-chain contracts to the signature services maintained by operators.
The incident involving DotSwap V1 illuminates the vulnerabilities of such architecture quite clearly: the attack vector primarily emerged from the server-side signature path rather than from publicly altered on-chain contract parameters, indicating that the protocol-level "code security" no longer equates to overall system security. Compared to a fully user self-custody model, this hybrid structure of custody and autonomy necessitates that participants pay extra attention to how operators retire old systems, how they close legacy signature channels, and how they continuously manage these custody multi-signatures, rather than simply reading a contract audit report once. Public materials have not provided quantitative metrics like on-chain transaction volumes, open positions, or funding rates; this incident more prominently exposes the structural risks at the signature and custody architecture level rather than some directly quantifiable market structure change signal. In the Bitcoin native DeFi ecosystem, the tension between security and experience is continuously accumulating risk costs in these details.
Focus Points for the Team and LP after 8.5 BTC Theft
About 8.5 BTC was transferred out from the custody multi-signature managed liquidity pool and V1 accounts within approximately 4 hours. The direct reminder for the team from this incident is that “retiring” a protocol does not merely equate to shutting down the front end or renaming the product line, but rather entails completely taking down all server-side signature paths, custody components, and legacy permissions. Otherwise, the old system marked as “inactive” may still serve as a high-value attack vector in the long term. For liquidity providers (LPs) who deposited BTC into the V1 pool and the broader community of Bitcoin native DeFi users, this loss also reveals a long-neglected blind spot: when participating in products driven by custody multi-signatures and server-side signatures, risks should not be simplistically equated with “on-chain contract risks,” but rather require clarifying the actual custody paths of assets, how assets will be safely returned upon exit or protocol shutdown, and who holds responsibility when problems arise—whether it’s the operator, the custodian, or the insurer. Current public materials primarily stem from On Nexus’s announcements and media reports, with no disclosure regarding the identity of the attackers, on-chain fund tracking, fund recovery, or compensation arrangements. There is also no indication of whether the legacy signature path has been fully closed or whether a third-party security audit will be introduced. What remains to be observed is whether On Nexus will provide a more complete security review and legacy asset disposition plan, and whether, in the absence of these critical pieces of information, the Bitcoin native DeFi ecosystem will reassess its tolerance towards custody structures, defining the safety boundaries of “retired protocols” more clearly and making them harder to ignore.
Join our community, let's discuss together and grow stronger!
AiCoin Exclusive Hyperliquid Benefits: https://app.hyperliquid.xyz/join/AICOIN88
AiCoin Exclusive Aster Benefits: https://www.asterdex.com/zh-CN/referral/9C50e2
On-chain Telegram Community: https://t.me/AiCoinWhaleData
On-chain Community: https://www.aicoin.com/link/chat?cid=N6OVMor5g
AiCoin On-chain Twitter: https://x.com/aicoinwhaledata
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到[email protected]，本平台相关工作人员将会进行核查。
