imtoken will never ask for your seed phrase, private key or verification code. Always review the address, network and request details before transferring, signing or approving.
imtoken
中文Download

imtoken Practical Guide

DApp Connections

A DApp connection flow starts with verifying the domain, not with pressing Connect. Account access, message signatures, transaction signatures, and approvals should be understood separately, followed by a decision about whether the session or permission should remain.

01

Prepare before you begin

Focus: DApp domains, connection requests, and account permissions

A DApp connection flow starts with verifying the domain, not with pressing Connect. Account access, message signatures, transaction signatures, and approvals should be understood separately, followed by a decision about whether the session or permission should remain.

When checking an on-chain result, prepare information you can verify independently and confirm the intended account and network. When DApp domains, connection requests, or account permissions is involved, keep recovery material, public addresses, and interface credentials conceptually separate.

Read the whole procedure before beginning, especially where a step changes from local viewing to signing, approval, or an on-chain transaction. Actions that can be irreversible or consume network fees deserve an additional review point.

02

Follow the operation in order

Focus: account permissions, network matching, and signature content

Before moving to the next step, execute the workflow in small steps. Start with DApp domains, then check connection requests and account permissions; before moving on, confirm that the displayed account, network, and target have not unexpectedly changed.

Whenever information must be entered, copied, or shown, decide first whether it is supposed to be public. A wallet address can normally be shared for receiving, while a seed phrase, private key, or verification code should never be handed to a site or support contact.

From a beginner's perspective, if the flow includes signing or a transaction, expand the request instead of relying on a short confirmation label. Review the object, network, amount, gas, contract, or permission scope and continue only after the effect is understood.

03

Verify the account or transaction result

Focus: signature content, transaction previews, and disconnecting

After the primary step, use details related to network matching, signature content, or transaction previews to verify the outcome. For on-chain work, prioritize the transaction hash and network record; for local account tasks, verify that the local state matches the intended result.

Over long-term use, do not repeat an action merely because the interface has not refreshed. Determine whether the original request was submitted, is still pending, or failed before deciding what to do next.

Verification should rely on public or locally controlled information. Troubleshooting never requires sending a seed phrase or private key to another party.

04

Recognize common mistakes and troubleshoot them

Focus: disconnecting, previous approvals, and DApp domains

When an interface message differs from expectations, common errors often come from the wrong network, the wrong object, a request that was not fully read, or confusing disconnecting with previous approvals. When something looks wrong, stop creating new requests and reconstruct what already happened in chronological order.

For a third-party DApp, re-check the domain and contract. For a transfer, re-check the address, network, and transaction hash. For recovery material, stop all sharing and protect the current device.

A useful tutorial is not designed to make confirmation faster. It makes every step explainable and reviewable, and it treats exiting an unclear request as a normal option.

05

Finish with a security check

Focus: DApp domains, connection requests, and account permissions

When a third-party service is involved, finish with an independent security check: secret material stayed private, the address and network match, the request came from the intended source, and the result has been verified with a reliable record.

For sessions or approvals that can remain active, decide whether they still need to exist after the task. Disconnect unused sessions and consider revoking permissions that are no longer necessary.

On-chain transactions generally cannot be reversed by a wallet provider alone. imtoken will never ask for a seed phrase, private key, or verification code, and a guide or support request asking for those secrets should not be followed.

Operation and security checklist

  • Confirm the context for DApp domains
  • Cross-check connection requests and account permissions
  • Understand the request involving network matching
  • Keep a verifiable record related to transaction previews
  • Review third-party DApp requests individually
  • Never send a seed phrase, private key, or verification code to anyone

Continue learning

Wallet GuidesTransaction ChecksSecurityFAQ