A token mapping table pairs a source contract with its destination representation. It lets bridge contracts apply the same deposit and withdrawal rules to a specific asset on both networks, while keeping lookalike tokens distinct; the decisive fields are chain identity and contract address, not a familiar name or ticker.
What does a mapping table actually connect?
A mapping records which destination token corresponds to a particular source token. For an ERC-20 transfer from Ethereum to Polygon, the pair is the Ethereum contract address and its mapped Polygon contract; the Polygon contract address is sometimes called the child token address.
In Polygon Bridge, the mapping is part of the route’s contract logic: the root-side token is associated with a child-side token, and the bridge’s predicates handle custody and issuance. For the return path, Polygon Bridge withdrawals use the mapped pair to identify which Polygon representation to burn and which Ethereum asset to release.
This is different from a wallet’s token list. A list helps a user interface display an asset; an on-chain mapping tells the bridge which contracts may participate in a route. OASIS Open’s L2 Token List specification describes the underlying problem as agreeing which destination-chain token corresponds to a source token.
How does the pair control a transfer?
The mapping is looked up when the bridge processes a transfer, then the relevant contracts enforce the asset accounting. On a typical lock-and-mint route, a deposit locks the source tokens and causes the mapped destination token to be minted or released; the reverse direction burns the mapped tokens before unlocking the source balance.
Think of the key as a tuple: (source chain ID, source contract address). Its value is the destination contract address. Chain IDs prevent an address on one network from being confused with the same hexadecimal address elsewhere. Names, symbols, and decimals remain useful metadata, but they are not safe keys: unrelated contracts can all call themselves “USD” or use the ticker “ABC.”
Decimals need checking because they affect displayed amounts, even when the bridge maps the right contracts. If a source token uses 6 decimals and its destination representation uses 18, a deposit of 12.5 source tokens should still represent 12.5 destination tokens; the raw integer changes from 12,500,000 to 12,500,000,000,000,000,000. A mapping that points to a token with different transfer or supply behavior can break that expectation.
What should you verify before choosing a route?
Verify the mapping using both chain IDs and full contract addresses, then check that the destination token is the expected representation. Confirm its decimals and whether the route supports the token’s behavior: fee-on-transfer, rebasing, pausable, or nonstandard ERC-20 tokens may not behave like a plain fixed-balance token.
For example, suppose you want to move 250 tokens and the source contract charges a 1% transfer fee. The bridge may receive only 247.5, while a conventional mapping assumes the requested 250 arrived; check whether the route rejects such tokens or accounts for the net amount. A ticker match cannot answer that.
Mapping authority is another trade-off. Some routes use permissionless standard representations; others require an approved mapping or custom child contract. The first can reduce listing friction, while the second can provide tighter control over token behavior. A mapping can also be stale after a contract migration or token upgrade, so confirm that the route’s current pair matches the issuer’s intended contracts.
For your comparison, separate three checks: the route’s actual contract pair, its handling of the token’s transfer rules, and the permissions that created the mapping. Ethereum.org’s glossary defines a token by its smart contract, a useful reminder that a symbol alone does not establish identity. Before acting, ask yourself: can I verify the exact source-to-destination contract pair and the behavior this route assumes?