IBC and x/bank Compatibility
How x/tokenization tokens reach x/bank, IBC, and other chains. Map of the four mechanisms and when to use each.
Tokens in x/tokenization are not sdk.Coin values and cannot be sent over IBC directly. Four mechanisms bridge the gap. This page tells you which one fits your job.
# The same collection seen three ways (mainnet LCD)
curl https://lcd.bitbadges.io/bitbadges/bitbadgeschain/tokenization/get_balance/21/bb1p0rrel3365scadq5k9pv0x0zp9j22js6dnw70d # native balance
curl https://lcd.bitbadges.io/cosmos/bank/v1beta1/balances/bb1p0rrel3365scadq5k9pv0x0zp9j22js6dnw70d/by_denom?denom=badges:21:utoken # wrapped x/bank coin
curl https://lcd.bitbadges.io/bitbadges/bitbadgeschain/sendmanager/balance/bb1p0rrel3365scadq5k9pv0x0zp9j22js6dnw70d/badgeslp:21:utoken # alias denom viewThe Four Mechanisms
| Mechanism | Denom it produces | Mints or burns | Configured where | Use it when |
|---|---|---|---|---|
| Alias Denoms | badgeslp:<collectionId>:<denom> | No | aliasPaths on the collection | A local module (pools, send manager) needs an sdk.Coin view of native tokens |
| Cosmos Coin Wrapper Paths | badges:<collectionId>:<denom> | Yes, a new x/bank denom | cosmosCoinWrapperPaths on the collection | Tokens must leave the chain over ICS-20 or sit in any x/bank account |
| Backed Minting | An existing ibc/ denom | No, escrows the IBC coin | invariants.cosmosCoinBackedPath at creation | Each token must be backed 1:1 by an existing IBC asset (compliant wrappers of ATOM, USDC, and so on) |
| Transfer tokens hook | None | Runs MsgTransferTokens | The ICS-20 memo of an inbound transfer | An inbound IBC transfer should mint or move tokens atomically |
Two supporting pages complete the picture:
- Rate limits: the
x/ibc-rate-limitmiddleware that caps net flow, unique senders, and per-address volume per channel and denom. - Cross-Chain Queries: interchain queries that let another chain verify ownership without moving tokens.
Ask your agent:
Give collection 1 an alias denom with symbol DEMO and 6 decimals so token ID 1 can sit in a liquidity pool.The MCP builder tools (add_alias_path) produce the objects on this page.
How to Choose
Alias denoms and wrapper paths both start from a native collection. The alias is an accounting view and never leaves x/tokenization state. The wrapper path burns native tokens and mints a real x/bank coin, which is the only form ICS-20 can carry. Backed minting is the reverse direction: an IBC asset already exists and the collection issues tokens against it. The transfer tokens hook is not a denom mechanism at all. It is a trigger that runs a token transfer when an IBC packet lands.
All four route through MsgTransferTokens and obey the collection's approvals. Wrapper and backed operations require prioritized approvals with the matching special-address flag (allowSpecialWrapping or allowBackedMinting). See Special Address Flags.
Native x/tokenization balances never travel over IBC. Only x/bank coins do. Wrap first, then transfer.