A deposit needs a valid Ethereum-to-Polygon token mapping. For an integrator, that mapping connects the Ethereum contract users approve and deposit to the Polygon contract that represents the asset they receive.
Keep the two contract addresses and chain IDs together in your token configuration; a ticker or token name is not enough to identify an asset. That is also why wallet setup for Polygon Bridge matters to an app flow: users need to select the intended source network before they approve the Ethereum token.
A mapping links two contracts through the bridge
On a standard PoS Bridge deposit, the user calls the Ethereum-side bridge with the root token address, amount, and recipient. The bridge checks that the token is mapped, locks the ERC-20 in its predicate contract, then sends a state-sync message to Polygon. When the message reaches ChildChainManager, it calls the mapped child token’s deposit function to mint the corresponding amount to the recipient.
For example, suppose your app supports a project token at Ethereum address A and the mapped Polygon token at address B. Your deposit UI should show A on Ethereum, then switch its balance and transaction tracking to B on Polygon after the deposit message executes. The token’s symbol and decimals help render amounts; they do not prove that A and B are the right pair.
The mapping is bridge-specific. A token may already exist on Polygon because its issuer deployed it there, but that does not make it the child token used by the PoS Bridge. Likewise, mapping does not merge independently deployed tokens or make their balances interchangeable.
Check the mapping before enabling deposits
Confirm the root and child addresses against the bridge’s authoritative mapping data before listing a token. On the PoS Bridge, the RootChainManager maintains the Ethereum-side association; ChildChainManager stores the corresponding child-side mapping. The address pair, network IDs, and bridge contract version should all match your integration configuration.
A safe integration check should use contract addresses, not metadata. At minimum, verify that the Ethereum token reports the expected decimals and that the configured Polygon address is the bridge-mapped child token. Then test a small deposit on a supported environment and confirm that the child balance changes for the intended recipient.
Mapping status also determines who can enable a token. Standard child tokens can be mapped permissionlessly through FxPortal, but custom child-token mappings for the PoS Bridge can require an authorized mapper. So if a token is absent from a bridge interface, deploying a Polygon token yourself does not automatically make it depositable through that bridge.
Token behavior can break the expected amount
ERC-20 compatibility alone does not guarantee that a token behaves safely in this flow. The PoS Bridge assumes ordinary token transfers; rebasing tokens and tokens that charge transfer fees can cause the amount locked on Ethereum to differ from what the bridge expects to mint or release.
Check the token’s transfer behavior before you advertise an exact 1:1 bridge amount. If the token takes a fee on transfer, the requested deposit amount may not be the amount received by the predicate. If it rebases, balances may change independently of bridge deposits and withdrawals. Reject unsupported tokens or clearly account for their mechanics in your app.
Questions integrators ask next
Can I create a missing Polygon token myself?
You can deploy a Polygon ERC-20, but that alone does not connect it to an Ethereum token in the PoS Bridge. A valid mapping must associate the Ethereum root contract with the intended child contract through the bridge’s mapping process. For a custom child token, confirm who is authorized to submit that mapping and verify the completed pair before you expose deposits.
What should I store for each bridged asset?
Store both chain IDs, both contract addresses, the token decimals on each side, and the bridge mapping status. Keep the addresses as the identity keys in your code; symbols and names are display metadata and can be duplicated or changed. Also record which bridge implementation the pair belongs to, since a mapping in one bridge does not establish a mapping in another.