DotSwap V1 Exploit Drains Approximately 8.5 BTC, With Losses Estimated at $685,000

On October 25, the legacy version of the DotSwap trading platform, DotSwap V1, was exploited in an attack that resulted in the theft of approximately 8.5 BTC, worth around $685,000 at the time of the incident.

The incident highlights a growing security challenge across Bitcoin-based applications: even when users interact with decentralized assets, backend authorization systems, custodial liquidity infrastructure, and automated signing services can create centralized points of failure.

According to an incident update from On Nexus, the affected platform has been taken offline while the team investigates the attack, tracks the stolen funds, and works with exchanges and blockchain intelligence partners.

What Happened to DotSwap V1?

DotSwap V1 used a server-side signing model to manage liquidity pools. Its liquidity infrastructure was operated through a custodial multisignature arrangement, meaning that deposited BTC was controlled by the platform’s signing process rather than by each liquidity provider directly.

The attacker reportedly exploited a legacy signing mechanism that remained active in the V1 backend. Over approximately four hours, automated scripts interacted with the platform’s available interfaces and gradually moved funds from V1 liquidity pools and user accounts.

The attack was not limited to a single token or endpoint. The scripts reportedly tested the platform’s interfaces and targeted assets associated with 99 Runes tokens, allowing the attacker to identify and exploit weaknesses across the broader application environment.

The total loss was estimated at roughly:

• 8.5 BTC stolen
• Approximately $685,000 in affected funds
• Liquidity provider deposits in DotSwap V1 impacted
• User-controlled wallets outside the platform not affected

DotSwap V1 has since been shut down. On Nexus has stated that it is working to restore related services and will publish a more complete post-incident analysis, along with a plan for affected users.

Why Liquidity Providers Were the Main Victims

The most important distinction in this incident is the difference between platform-managed funds and assets held in a user’s own wallet.

Liquidity providers who deposited BTC into DotSwap V1 were exposed to the platform’s custody and signing architecture. Although the system used multisignature controls, the signing process was still connected to backend services that could be queried and triggered through application interfaces.

This means that multisignature protection alone did not eliminate operational risk. If authorization logic, API permissions, signing policies, or server-side controls are improperly designed, an attacker may still find a way to produce valid transactions.

By contrast, users who kept their assets in self-custodial wallets and did not deposit them into V1 pools were not affected by the incident. Their private keys remained outside the compromised platform environment.

This distinction is central to understanding liquidity pool risk:

A protocol may use blockchain settlement while still relying on centralized infrastructure for custody, signing, pricing, routing, or access control.

Users should therefore evaluate not only whether an application is “on-chain,” but also where signing authority is located, who controls withdrawal permissions, and whether deposited funds can be frozen or redirected by a backend system.

A Possible Example of AI-Assisted Attack Automation

On Nexus characterized the incident as consistent with a recent trend involving AI-driven or highly automated attacks.

The use of automation can significantly increase the speed and scope of an exploit. Instead of manually testing one function at a time, an attacker can programmatically:

1. Discover exposed API endpoints
2. Submit large numbers of requests
3. Compare responses across different assets
4. Detect inconsistent authorization behavior
5. Identify abnormal signing or withdrawal paths
6. Execute transactions in rapid succession

In an environment supporting dozens of token contracts and trading routes, automation makes it easier to identify small implementation differences that may not be visible during routine manual testing.

The broader lesson is that security teams must now defend against attacks that combine traditional scripting with increasingly capable AI agents. API discovery, vulnerability classification, transaction construction, and monitoring can all be accelerated by automated tools.

This trend makes rate limiting, endpoint isolation, anomaly detection, signing-policy enforcement, and real-time transaction monitoring increasingly important for digital asset platforms.

What the Incident Reveals About Runes Infrastructure

The Runes ecosystem has expanded the range of fungible assets that can be issued and traded on Bitcoin. However, the infrastructure supporting these assets is still developing, and many applications depend on a combination of indexers, off-chain services, custodial pools, and specialized trading logic.

This creates several areas of risk:

• Indexer dependency: Wallet balances and token states may rely on third-party indexing services.
• Backend authorization: A platform may use centralized APIs to determine whether a transaction can be signed.
• Custodial liquidity: Users may deposit BTC into pooled wallets managed by the application.
• Contract and asset complexity: Supporting many Runes assets increases the number of routes, interfaces, and edge cases that must be tested.
• Operational concentration: A single compromised signing service may affect multiple pools at once.

Users exploring Runes trading or liquidity provision should review the project’s custody model before depositing funds. A platform’s user interface may appear decentralized while important control functions remain centralized.

For background on the Bitcoin asset ecosystem, users can refer to the Bitcoin developer documentation and the Bitcoin Optech newsletter, which regularly covers developments in Bitcoin protocols, wallets, and infrastructure.

Practical Security Lessons for Crypto Users

1. Confirm whether funds remain under your control

Before supplying liquidity or depositing assets, determine whether the platform can move funds without a transaction signed directly by your wallet.

Questions worth asking include:

• Are deposits sent to an address controlled by the user or by the platform?
• Who holds the private keys?
• Is signing performed locally, through a hardware device, or on a server?
• Can administrators pause withdrawals or change signing rules?
• Are withdrawal limits and monitoring controls publicly documented?

The answers can materially change the risk profile of the service.

2. Treat legacy products as potential attack surfaces

The DotSwap V1 incident shows why old versions of a platform should not remain connected to active services. Even if a new version has stronger controls, outdated APIs, signing routes, and account permissions may still be exploitable.

Projects should fully decommission retired products by:

• Revoking API credentials
• Removing old signing permissions
• Disabling unused endpoints
• Rotating service keys
• Separating legacy databases from production systems
• Monitoring historical infrastructure for unexpected activity

3. Avoid concentrating assets in a single application

Liquidity providers should consider diversification across wallets, protocols, and custody models. Concentrating a large amount of BTC in one application can increase the impact of a single exploit or operational failure.

This does not remove protocol risk, but it can reduce the possibility that one incident affects an entire portfolio.

4. Monitor wallet activity and approvals

Users should regularly review wallet balances, connected applications, account sessions, and transaction history. Unexpected signing requests, unfamiliar withdrawal addresses, or new device logins should be treated as potential warning signs.

For high-value transactions, users should independently verify:

• The destination address
• The asset and amount
• The network
• The transaction fee
• The application domain
• The final transaction details shown by the wallet

5. Understand that multisignature does not equal full decentralization

Multisignature arrangements can improve resilience, but their effectiveness depends on how signers are distributed and how authorization is enforced.

If all signers are controlled by the same organization, connected to the same backend, or subject to the same flawed policy engine, the system may still have a meaningful centralized failure point.

Security depends on the complete signing architecture, not merely on the presence of multiple signatures.

What Affected Users Should Watch For

Users connected to DotSwap V1 should be cautious of phishing messages claiming to offer refunds, compensation, or emergency withdrawal tools. Attackers often exploit public incidents by impersonating project teams and directing victims to fake websites.

Affected users should:

• Follow only verified project communication channels
• Avoid entering seed phrases or private keys into websites
• Treat unsolicited refund forms as suspicious
• Save transaction IDs and deposit records
• Check the blockchain independently
• Monitor related wallet addresses for movement
• Wait for an official recovery or claims process before signing anything

A legitimate support team should never require a wallet’s recovery phrase to verify ownership or process a reimbursement.

For general guidance on protecting digital assets, the CISA cybersecurity guidance provides useful information on phishing, account security, and malicious activity.

The Broader Implications for DeFi and Bitcoin Applications

The DotSwap V1 exploit is not simply a story about one vulnerable platform. It reflects a broader tension in the crypto industry: applications may present users with a decentralized interface while relying on centralized components behind the scenes.

As Bitcoin-based financial applications mature, security reviews will need to cover more than smart contract code. Audits should also examine:

• API authentication and authorization
• Server-side signing services
• Key management and signer isolation
• Database permissions
• Asset indexing systems
• Upgrade and shutdown procedures
• Monitoring and incident response
• Emergency withdrawal mechanisms

In 2025, the increasing use of automated agents and AI-assisted development makes this review process even more important. Faster software development and automated interaction can expand the attack surface if security controls do not evolve at the same pace.

For users, the most reliable protection remains a clear understanding of custody. Assets held directly in a self-custodial wallet are exposed to a different set of risks than assets deposited into a platform-controlled pool. Neither model is risk-free, but the source of risk is substantially different.

How Hardware Wallets Fit Into a Safer Self-Custody Strategy

A hardware wallet can help reduce exposure to server-side compromises by keeping private keys isolated from internet-connected applications. When users interact with decentralized applications, transaction details can be reviewed and approved from a dedicated signing device rather than relying solely on a browser interface.

OneKey hardware wallets are designed for self-custody workflows, including offline key protection and on-device transaction confirmation. They do not eliminate smart contract risk, phishing, malicious interfaces, or market volatility, but they can help users maintain control of assets that are not intentionally deposited into custodial platforms or liquidity pools.

The key principle is straightforward: before providing liquidity or authorizing a transaction, users should understand who controls the funds, what they are signing, and whether the platform can move assets without their direct approval.

DotSwap V1’s loss of approximately 8.5 BTC reinforces why custody architecture, signing permissions, and operational security deserve as much attention as token utility or trading volume. In an increasingly automated crypto environment, informed self-custody and careful transaction verification remain essential defenses.