Security

Seed phrases and private keys remain under the user’s control. Legitimate support should not ask for them through chat, email or web forms. Any such request is a high-risk signal.

A repeatable order of checks is more reliable than memory. Review source, network, account, target and expected outcome each time so the same safety logic carries across wallets and DApps.

Fake support, airdrops, lookalike domains and remote-control requests often create urgency to bypass verification. Pressure, threats or “verify your wallet now” language is a reason to stop and re-check the source.

When a task involves a third-party contract, bridge, validator or web service, separate that external risk from the wallet itself. A wallet can display and sign a request, but it cannot guarantee the safety of outside code or services.

Connecting to a DApp does not make later requests trustworthy. Review every signature, spender and allowance, and consider revoking permissions that are no longer needed.

Put this concept back into the current network, account and request type before acting. Identify what the interface is asking for, then decide whether a signature, gas payment or ongoing permission is actually required.

Blockchain transactions generally cannot be unilaterally reversed by a wallet. Verify address, network and amount before sending, and be especially cautious on public devices, public networks or remote-control sessions.

Do not rely on a button label or a familiar-looking page as the reason to continue. Compare the request with the on-chain target, network state and expected result, and stop when those pieces do not line up.