Polkadot keeps token balances in separate chain records

Locate the balance on its holding chain

Start with the chain, account, and asset that the wallet uses to display a balance. A network-wide portfolio total can combine several holdings that applications access separately. Open the individual holding to identify its chain, then compare the account and asset with that chain's ledger. A matching balance establishes where the tokens exist, even when another network view shows nothing. A successful local transfer spends funds from the account record on its source chain.

An empty balance on one chain does not describe every holding across the ecosystem. Likewise, a token visible elsewhere does not automatically fund the chain that an application uses. Network selection controls the records that the interface reads. It does not relocate assets or make them available to another chain's applications.

Local payments and cross-chain transfers change different ledgers

A same-chain payment changes balances within one ledger, while a cross-chain transfer involves asset handling across participating chains.

A payment on the holding chain

The chain debits the sender and credits the recipient under its local asset rules. The recipient address identifies an account on that chain. Transaction fees also follow the chain's configuration. Sharing an account identifier with another network does not extend this payment to that network. The credited balance remains available where the payment occurred, subject to the asset's transfer restrictions and account requirements.

A transfer to another chain

XCM, the Cross-Consensus Message Format, describes instructions that another consensus system can execute. A transfer identifies the destination, asset, and beneficiary within their appropriate contexts. The receiving chain must recognize the asset and accept the selected transfer mechanism. An address alone cannot supply those missing relationships. Shared security and a common message format leave each parachain's asset records distinct.

Why can DOT appear on more than one chain?

DOT can have balances on multiple chains because supported cross-chain mechanisms establish corresponding holdings in separate ledgers. In a reserve-backed transfer, a reserve chain holds the underlying asset. Another chain records a representation backed by those reserves. Asset Hub is the primary reserve location for DOT, and participating parachains can maintain their own DOT representations. Backing held in a chain's sovereign account is distinct from the token holder's personal balance.

Teleportation uses a different accounting relationship. It removes assets from circulation at the source and creates corresponding assets at the destination. This mechanism requires the receiving system to trust the source's handling of that asset. Reserve transfers instead rely on a trusted reserve location. Each chain configures the asset-and-chain combinations that it accepts, so neither mechanism implies that every token can move between every pair of chains.

The Asset Hub migration moved Relay Chain balances

Polkadot migrated account balances from the Relay Chain to Asset Hub on November 4, 2025. Asset Hub, also called Polkadot Hub, became the location for those balances and the associated staking and governance activity. The migration moved the balances automatically. A personal cross-chain transfer was not necessary to make that move happen. Older transaction histories and instructions can therefore describe a balance location that differs from the chain that now holds it.

That migration concerned Relay Chain balances. Crowdloan funds still locked at the time remained on the Relay Chain. It did not combine every parachain's ledger into one balance. Holdings on other chains still require their own network context.

Asset IDs and XCM locations identify different contexts

An asset identifier distinguishes a token's actual record from the name or symbol that a wallet displays. On Polkadot Hub, locally issued fungible assets use the Assets pallet and numeric asset IDs. Foreign assets use XCM locations as identifiers. A familiar token name does not establish that two records describe the same asset. Asset metadata includes a name and symbol that creators can choose, so identity checks need the chain and its underlying identifier.

An XCM location describes an asset or destination relative to the system interpreting it. Its encoded path can change when viewed from another chain. Local numeric IDs also belong to their chain's asset registry. Comparing these identifiers without their context can confuse separate assets or separate representations of one asset.

View full-size image

Fee deductions can reduce the destination credit

Cross-chain costs can include local execution, message delivery, and execution on the receiving chain. A route through intermediate chains can add delivery and execution costs along the way. The source transaction's fee estimate therefore may cover only part of the operation. Fee estimation needs the actual route and the assets that its participating chains accept for payment. A balance in an unsupported fee token cannot satisfy that route's fee requirement.

The pallet-xcm transfer_assets call pays destination execution fees from the transferred asset selected for fee payment. When that selected asset is also the token being sent, fee deductions can reduce the amount credited to the beneficiary. Separate fee assets and other supported methods can allocate costs differently. The execution budget also matters: insufficient purchased execution can stop the remote operation. Compare the requested amount, the applicable fee deductions, and the final destination credit without assuming that every method uses identical accounting.

Recipient minimums can prevent a new asset balance

The destination's account rules determine whether it can create and retain the recipient's asset balance. These requirements belong to the receiving chain and asset. A valid address does not establish that the account satisfies them, and a sufficient sending balance does not resolve a missing destination prerequisite.

The account's existence requirement

A native-token existential deposit helps determine whether an account remains in chain state. On Asset Hub, an asset marked sufficient can support an account without a native DOT balance. A non-sufficient asset needs an existing account supported under the chain's account rules. Sufficiency concerns account existence; it does not automatically make the asset acceptable for transaction fees. Account references and other retained balances also affect whether the chain can remove an account.

The asset's minimum holding

Each asset can have its own minimum balance, including assets that are sufficient. The amount credited after any applicable deductions must satisfy the relevant deposit rules. A transfer that leaves the recipient below the asset minimum can fail to establish the intended holding. The destination's asset configuration supplies that threshold. It can differ from the sending chain's minimum, so copying a source-chain value into a destination check can produce the wrong answer.

Does source-chain success prove that the recipient received the tokens?

Source-chain success confirms local execution, while arrival requires a destination credit for the intended asset and beneficiary.

XCM processing is asynchronous. The sending chain can finish its transaction while another system still has instructions to process. A source transaction hash identifies the local transaction. An outgoing message identifier helps trace the cross-chain handoff. Neither identifier, by itself, demonstrates that the receiving chain deposited the assets. Local execution events and destination execution events answer different questions.

The recipient's asset record shows its current balance on the destination. Match deposit events with the message's destination execution to identify the amount credited by this transfer, especially when the account has other activity. A portfolio total may change for unrelated reasons, including movements on another chain. Reading the relevant asset record avoids treating an aggregate increase as proof of this particular transfer.

Destination execution can also stop before the intended deposit completes. A successful source operation does not guarantee an automatic refund after that failure. The remote outcome determines whether the assets reached the beneficiary or remain elsewhere in the execution process.

Separate display problems from remote execution failures

A missing wallet entry can reflect the selected network or the assets that the interface displays. The chain's account and asset records establish whether a balance exists there. If those records show the intended credit, wallet settings or data retrieval explain the display discrepancy. Updating a wallet that still queries an obsolete balance location addresses a display problem without moving tokens.

When destination execution stops with assets still in XCM holding, the configured asset-trap handler determines their treatment. A supported claim mechanism can make trapped assets recoverable by the entitled origin. ClaimAsset requires the matching assets and claim identifier; possession of the sender's address alone does not establish a valid claim. Recovery depends on the runtime and the recorded failure. Establish that outcome before repeating a submitted request, because another transfer creates another operation and cannot repair the first one.