15 hijacked domains restored: what DeFi wallet users still need to check

What the recovery report actually says

Odaily attributes the count of 15 hijacked customer domains and their restoration to Name.com. The report says an earlier count was 12. It separately attributes the link between 10 affected domains and Vercel's platform to Vercel. These are reported statements about the affected web addresses and platform association. The article does not provide an account-by-account wallet assessment.

The report names Flap, Kintsu, Pickle Finance and Origami Finance among DeFi websites involved in the preceding attack. It says attackers used the compromised websites to drain visitors' cryptocurrency wallets. It also says the previously identified 12 domains were registered through Name.com and that 10 had been suspended at registrar level on Saturday morning. That earlier suspension count belongs to an earlier stage of the response; it should not replace the later restoration count. The incident details reported by Odaily.

The numbers refer to different sets. Fifteen is the reported customer-domain count. Ten is the reported number associated with Vercel. Twelve describes the earlier identified group, while the other reference to 10 describes registrar-level suspensions. Combining the figures into a single list of protocols would change what the source says. A domain, a website and a wallet are also different units, so the domain count cannot tell us how many people lost funds.

The report is a useful recovery update, but the opened material does not establish a complete technical explanation of how the hijacking happened. Vercel association alone does not identify the entry point. We therefore do not assign the attack to a Vercel infrastructure flaw, a particular registrar control failure or a compromised individual account. Those explanations need evidence beyond the association reported here.

Why the US$138,000 figure needs its boundaries

Odaily reports that about US$138,000 in stolen funds had been traced to three wallets on EVM chains. It explicitly says this amount excludes losses on Solana or Aptos. The figure is a reported tracing result with a stated scope. It cannot be used as the complete loss across every network mentioned in the incident. Odaily's reported fund tracing.

Nor does tracing an amount to wallets show that victims received it back. The report's restoration statement concerns domains. Its fund-tracing statement concerns assets. The opened report does not announce that the approximately US$138,000 has been recovered, frozen or returned. An account holder should keep any claim of website recovery separate from any claim about reimbursement.

There is also no basis here for calculating a loss per domain or per user. Dividing the tracked amount by 15 would combine a partial asset tally with a domain count that describes the attack's web footprint. It would produce an average that says nothing reliable about an individual wallet. For a reader checking exposure, the useful evidence is their own transaction history and approvals, not that division.

Website access and token permission have different checks

MetaMask explains that connecting a wallet gives a dapp certain permissions relating to the public address, balances and interaction with the wallet. Token approvals are separate permissions that let smart contracts access and move approved tokens. Its guidance says revocation must happen on-chain and requires gas. MetaMask on approvals, disconnection and revocation.

That distinction changes the order of a sensible review. A restored domain can be relevant to whether the project is regaining control of its website. It does not tell a reader which token allowances their address currently has. Closing a browser tab or disconnecting a dapp should not be recorded as an approval revocation. The wallet-side record needs its own evidence.

Our suggested first step is to write down which affected website you visited, the wallet address used and the network selected. Then review the actions you actually took. Reading a page, connecting a wallet, signing an approval and sending a transaction should be recorded separately. The opened incident report does not say that every visitor completed all of these actions, so it would be wrong to describe every visitor as a confirmed victim.

For someone who signed an approval, the next question is which contract received permission and for which token. MetaMask's guide points to approval checkers on network explorers and to its own allowance-management feature. Use the appropriate network when checking. A result for one network does not document the permissions on another network where you also used the wallet.

How to review an approval without making another blind signature

Start with the wallet address and the transaction record you want to investigate. Compare the token, the contract receiving permission and the allowance shown by a trusted approval-management interface. Preserve the transaction hash and the time as part of your record. These are suggested review steps based on MetaMask's description of token approvals, rather than findings about any particular reader's account.

If you decide to revoke an unwanted approval, inspect the transaction in the wallet before signing. MetaMask says the revocation is an on-chain transaction and gas is payable. An instruction that describes simply disconnecting a website as a completed revocation conflicts with that guidance. Check the actual action being requested, rather than relying on the label on a recovery page. Official instructions for revoking token allowances.

After submitting a revocation, check its outcome and the remaining allowance. A submitted request is still a request until the relevant record shows the change. Keep a separate note for each token and contract you review. This avoids treating an action on one approval as evidence that every permission associated with the address has been removed.

Revoking a permission addresses that permission. It does not establish that an earlier token transfer has been reversed. The opened MetaMask guide describes how allowances work; the Odaily report supplies no victim repayment procedure. Neither source establishes that revocation retrieves funds already taken or that website restoration restores a wallet balance.

For users who only connected a wallet, MetaMask's distinction still helps: inspect what permissions and transactions actually exist before deciding which response fits. Avoid assuming an approval was granted merely because a connection occurred. Equally, a disconnected site should not persuade someone who did approve spending to skip the allowance review. The transaction record should decide which branch applies.

What an exchange transfer adds to the review

If you moved tokens between an exchange account and the wallet used on an affected site, keep that transfer separate from the website interaction. Our suggested record includes the asset, network, sending address, destination and transaction hash. Compare those details with the wallet activity being examined. An exchange withdrawal receipt is evidence of that transfer; by itself it does not identify a subsequent approval made through a DeFi website.

Before starting another transfer, inspect the receiving account's deposit instructions and compare them with the sending network. Identify existing exposure and document the actions already taken before deciding whether to send another transaction.

A support request can be more precise when it names the relevant domain, address and transaction instead of saying only that the website was hacked. Ask the project to distinguish restoration of its web address from any assessment of user transactions. If you report a suspected malicious approval, identify that approval separately from a transfer you believe used it. These are suggested questions, not a claim that any project has published a particular support or compensation process.

What remains unconfirmed

The opened event report is Odaily's account of statements attributed to Name.com and Vercel. We did not obtain the companies' original incident statements or a transaction-level victim ledger in the material opened for this article. The official MetaMask document supports the explanation of wallet permissions; it independently confirms neither the count of hijacked domains nor the loss figure.

The source does not provide a complete affected-domain list, a final all-network loss tally, a compensation commitment or a full technical account of the intrusion. Those gaps matter to a user trying to match an address or a specific website with this event. They also prevent us from stating that every application in the report has completed every aspect of its recovery.

Watch for a project-specific recovery notice that identifies the domain and a technical explanation of the incident. For your own account, preserve the approval and transfer records you checked, including the network and observation time. The 15-domain restoration update is the new reported fact; the result of an individual wallet review has to come from that wallet's records.