On this page
Service and mechanismWhat to understand firstNotices and status informationSupport and risk boundariesService and mechanism
Information about getting started should focus on mechanisms, current state and risk boundaries rather than promotional promises. imtoken explains services so users can understand what happens before deciding whether a feature fits their own situation. On-chain services may involve network conditions, waiting periods, smart-contract risks and market volatility.
When working with Academy, keep verifiable public information separate from secret credentials. Details such as wallet basics, addresses, networks, gas, transaction hashes, DApps, approvals, and security routines can support troubleshooting, but a seed phrase, private key, or verification code should never become part of a support or diagnostic request.
What to understand first
Before acting on Academy, build a short verification path: confirm the network, confirm the intended account or contract, check the origin of the request, and decide which public evidence will prove the result. Reading wallet basics, addresses, networks, gas, transaction hashes, DApps, approvals, and security routines together is more reliable than trusting a single interface status.
Notices and status information
When reading getting started, focus on notices that can affect real actions, such as network incidents, security warnings, feature changes and support routes. If there is no reliable date or verifiable fact, a site should not invent publication dates, partnerships, user counts or market rankings. Urgent notices should explain both the reason and the safe action path.
When something looks wrong
Start with public information: the network name, address, transaction hash or contract address. These details are usually enough to distinguish a pending network state, failed transaction, display issue or third-party service issue without exposing secret credentials.
If a Academy result differs from what you expected, start with public on-chain evidence. Use the network name, address, transaction hash, contract address, or confirmation state to narrow the cause, then interpret wallet basics, addresses, networks, gas, transaction hashes, DApps, approvals, and security routines to distinguish waiting, parameter errors, display differences, or third-party service issues.
Support and risk boundaries
The purpose of wallet guides is to support troubleshooting without exposing secrets. Public information such as an address, network name and transaction hash is often enough to investigate a transaction or display issue. A support process should never require your seed phrase, private key, recovery phrase or verification code.
After a Academy action, review the outcome instead of treating the confirmation click as the end of the process. Recheck wallet basics, addresses, networks, gas, transaction hashes, DApps, approvals, and security routines, look for unnecessary permissions or an unexpected network state, and make periodic review part of normal wallet maintenance.
