QiDao–Superfluid Exploit: What Should You Check?

The roughly $13 million figure refers to an exploit associated with a QiDao contract using Superfluid. Treat it as a headline estimate, not a verified account of the exact net loss, affected assets, or recovery. The incident is a reason to check the specific contracts you interacted with—not proof that every QiDao vault, Superfluid stream, or wallet was compromised.

If you used a related stream or contract, start by identifying the network and contract address from your own transaction history. Then check whether you still have an active stream or token permission connected to it. Do not sign a transaction or share a recovery phrase because someone claims they can return funds.

In 2026, the practical question is whether your own position still depends on an affected contract or permission. If you cannot verify the contract or the status of your funds, pause before interacting and seek confirmation through a project channel you independently know is official.

QiDao is a decentralized finance project associated with collateralized borrowing, while Superfluid provides onchain token-streaming functionality. A project can use a separate protocol’s contracts for a specific feature without every part of its own system sharing the same code or risk. That distinction matters: an exploit involving an integration should not automatically be described as a compromise of every QiDao vault.

A smart contract can hold tokens or receive permissions to move them under specified conditions. If a flaw lets an attacker bypass those conditions, funds associated with that contract or permission may be exposed. This is different from stealing a user’s seed phrase, and different again from a market move that triggers liquidation on a borrowing position.

The incident name alone does not establish which contract version, network, or user actions were affected. Before deciding that a wallet is safe—or compromised—match your own transaction records to the specific contract involved. Avoid making broad assumptions from the project names or from a single dollar figure.

A streaming contract can automate recurring token transfers over time. That convenience depends on contract logic, token permissions, and the conditions that govern starting, updating, and stopping a stream. A bug in a contract or an unsafe interaction can put assets within its reach at risk, even if a user did not intend to make a one-off transfer of the entire balance.

An exploit does not necessarily mean a user clicked a malicious link. Some attacks target contract behavior directly. But wallet approvals and signatures still matter: an approval can authorize a contract to move a token, and a signature can authorize an action that is difficult or impossible to reverse once submitted.

For any stream or DeFi integration, check the spender or contract address, the token, the network, and the permission’s scope before signing. If a wallet shows an unfamiliar approval or transaction request, reject it until you understand what it does. A familiar project name in the wallet interface is not enough to prove that an address is legitimate.

Use the following checks if you previously interacted with QiDao or Superfluid. Work from your own wallet history and the relevant network; do not rely on a message from an account that contacts you unexpectedly.

1. Identify the interaction. Find the transaction, chain, token, and contract address associated with the stream or integration.
2. Check for an active stream. Confirm whether transfers are still scheduled and which contract controls them.
3. Review token permissions. Look for approvals to the relevant spender and note whether the allowance is limited or unlimited.
4. Verify before changing anything. Confirm the exact address and network using a project channel you already trust. Revoke only a permission you can identify; revocation may require a network transaction fee.
5. Keep records. Save transaction hashes and screenshots of balances before contacting support.

If the contract or status is unclear, do not guess. A mistaken transaction can create new losses, and network fees are generally paid even when a transaction fails.

A headline amount is not necessarily the final loss borne by users. The gross value moved during an exploit can differ from the amount ultimately unrecoverable because token prices change, some assets may be returned or frozen, and the affected contract may contain more than one asset. Do not use the roughly $13 million figure as a personal loss estimate without matching it to the relevant chain and transactions.

The precise breakdown, net loss, and recovery status should be treated as unconfirmed unless you can verify them through reliable incident updates and onchain records. A transaction history can show what moved; it cannot always establish whether an affected user later received compensation or whether a claim remains open.

If you believe your funds were affected, document your wallet address, chain, token, and transaction hashes. Contact the project only through a channel you independently verify. Never pay an “unlock,” “recovery,” or “verification” fee to a stranger, and never provide your seed phrase or private key. No legitimate support process needs those credentials.

An old exploit is useful evidence of historical contract risk, but it is not a complete security assessment of the project in 2026. Before using QiDao or a Superfluid feature now, confirm that you are interacting with the intended contract on the intended network. Check whether the particular feature is still active, what permissions it requests, and whether you can exit or stop it without relying on an unfamiliar third party.

Also account for costs. Creating or changing an onchain stream and revoking an approval can require network gas; the amount varies by chain and network conditions. A failed transaction can still consume gas. A borrowing position may have separate collateral, liquidation, and transaction costs, so do not confuse those with the risk of a token-stream contract.

A security audit can help identify issues in the code it covers, but it is not a guarantee against every exploit, upgrade, dependency, or user error. If you cannot verify the address, permission, or exit process, the safer choice is to wait rather than approve a transaction under pressure.

Avoid these common reactions to an exploit headline:

• Assuming every product is affected. Verify the specific contract and network rather than treating all QiDao and Superfluid activity as one system.
• Treating a gross figure as a confirmed personal loss. Match records and updates to your own wallet before estimating exposure.
• Signing a “recovery” transaction. Attackers often use incident confusion to solicit approvals or seed phrases. Do not sign requests you cannot explain.
• Revoking permissions blindly. First confirm the spender, token, network, and permission. A wrong transaction can waste gas or affect an unrelated position.
• Relying on a saved address without checking it. Confirm contract addresses through a trusted channel; a lookalike name or unsolicited direct message is not proof.
• Assuming a past audit or fix removes all risk. Check the exact version and feature you plan to use, and remember that smart-contract and integration risks remain.

Take time to verify before moving funds. There is no need to act on an urgent message from an unknown account.