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.

Knowledge Guide

Blockchain Glossary

A clear guide to addresses, blocks, gas, hashes, EVM, Layer 2, DApps, approvals and validators.

01Addresses & keys
02Blocks & hashes
03Gas
04EVM & Layer 2
05DApps & validators

01

Understand the role of Addresses & keys

In “Blockchain Glossary,” Addresses & keys is not an isolated idea. It works with Blocks & hashes and DApps & validators to determine what the user sees and where an action actually takes place. Once those boundaries are clear, interface prompts become easier to evaluate.

On-chain terms connect to each other: addresses identify accounts, hashes identify transactions or blocks, gas represents execution cost, EVM describes an execution environment, while DApps and validators serve application and network roles. This section therefore focuses on reasoning through the relationship between Addresses & keys, Blocks & hashes and the resulting on-chain state rather than memorizing interface locations.

A practical review habit

  • Identify the active network and the object represented by Addresses & keys, not only its display name.
  • When Blocks & hashes is involved, confirm that both concepts share the intended network and permission context.
  • Keep public verification details such as a transaction hash when troubleshooting, but never expose recovery secrets.

02

How Blocks & hashes works with Gas

Start with the goal of the action, then identify the network, address, contract or permission context represented by Blocks & hashes. Similar names, icons or page layouts do not prove that two environments are equivalent; network and on-chain identifiers provide stronger context.

On-chain terms connect to each other: addresses identify accounts, hashes identify transactions or blocks, gas represents execution cost, EVM describes an execution environment, while DApps and validators serve application and network roles. This section therefore focuses on reasoning through the relationship between Blocks & hashes, Gas and the resulting on-chain state rather than memorizing interface locations.

A practical review habit

  • Identify the active network and the object represented by Blocks & hashes, not only its display name.
  • When Gas is involved, confirm that both concepts share the intended network and permission context.
  • Keep public verification details such as a transaction hash when troubleshooting, but never expose recovery secrets.

03

Reviewing Gas during an action

A repeatable review of Gas can begin with the source and network, continue with the target and parameters, and end with the asset or permission change the action may create. Consistency is more useful than trying to confirm quickly.

On-chain terms connect to each other: addresses identify accounts, hashes identify transactions or blocks, gas represents execution cost, EVM describes an execution environment, while DApps and validators serve application and network roles. This section therefore focuses on reasoning through the relationship between Gas, EVM & Layer 2 and the resulting on-chain state rather than memorizing interface locations.

A practical review habit

  • Identify the active network and the object represented by Gas, not only its display name.
  • When EVM & Layer 2 is involved, confirm that both concepts share the intended network and permission context.
  • Keep public verification details such as a transaction hash when troubleshooting, but never expose recovery secrets.

04

Common assumptions to avoid

A common mistake around EVM & Layer 2 is treating display information as final on-chain truth, or assuming that a workflow that was safe once will be identical on another network, asset or DApp. Re-read the current request every time.

On-chain terms connect to each other: addresses identify accounts, hashes identify transactions or blocks, gas represents execution cost, EVM describes an execution environment, while DApps and validators serve application and network roles. This section therefore focuses on reasoning through the relationship between EVM & Layer 2, DApps & validators and the resulting on-chain state rather than memorizing interface locations.

A practical review habit

  • Identify the active network and the object represented by EVM & Layer 2, not only its display name.
  • When DApps & validators is involved, confirm that both concepts share the intended network and permission context.
  • Keep public verification details such as a transaction hash when troubleshooting, but never expose recovery secrets.

05

Make DApps & validators part of a routine

Making DApps & validators part of a routine means adding checkpoints before, during and after an operation: verify the conditions, read the request, then confirm the result through the transaction hash, network state or approval record.

On-chain terms connect to each other: addresses identify accounts, hashes identify transactions or blocks, gas represents execution cost, EVM describes an execution environment, while DApps and validators serve application and network roles. This section therefore focuses on reasoning through the relationship between DApps & validators, Addresses & keys and the resulting on-chain state rather than memorizing interface locations.

A practical review habit

  • Identify the active network and the object represented by DApps & validators, not only its display name.
  • When Addresses & keys is involved, confirm that both concepts share the intended network and permission context.
  • Keep public verification details such as a transaction hash when troubleshooting, but never expose recovery secrets.

Important security reminder

Seed phrases and private keys should remain under the user’s control, and official personnel will not request them or verification codes. Check the address, network and amount before a transfer; on-chain transactions generally cannot be unilaterally reversed by a wallet. Third-party DApps and smart contracts carry risk, so review the spender and permission scope and consider revoking unused approvals.

Before you continue

Use a repeatable review routine

  • Verify the active network and target address or contract
  • Read the amount, fee, signature or permission scope
  • Never send a seed phrase, private key or verification code to anyone
  • Verify the result through a transaction hash or approval record
  • If a request is unclear, stop and verify the source before continuing