About Dual-chain Address Formats Chains like Kaia (ex-Klaytn) and XPLA run an EVM layer alongside a Cosmos SDK layer. Accounts on both sides share the same 20-byte key, but the canonical form differs: EVM uses 0x-prefixed hex with an EIP-55 checksum, while the Cosmos side uses Bech32 with a human-readable prefix (hrp) and a 6-character checksum. This converter re-encodes the same bytes between the two formats so block explorers, SDKs, and dApps can display the user-friendly form for the module they are in.
How to Use Pick a Bech32 prefix from the dropdown, or enable Custom and type any hrp. To encode, paste a 0x hex address and click Hex → Bech32. The prefixed form appears in the Bech32 field. To decode, paste a Bech32 string and click Bech32 → Hex. The hex field is filled with the EIP-55 checksummed form. Use the copy buttons to grab either side for your RPC or wallet config. Examples Hex: 0x5aAeb6053F3E94C9b9A09f33669435E7Ef1BeAed
Bech32 (cosmos): cosmos1tt4wcpflunff3kdqn7vmfgs679m0xh2mjzkvxt
Hex: 0xfB6916095ca1df60bB79Ce92cE3Ea74c37c5d359
Bech32 (kaia): kaia1ldxjcz2u58masmrec7jecragf3hchf4ez9s5hu
Bech32 (xpla): xpla1qypqxpq9qcrsszg2pvxq6rs0zqg3yyc54hkxun
Hex: decoded to 20-byte hex with EIP-55 checksum
Deep Dive into Dual-chain Architectures Kaia and XPLA's shared key model Kaia (formerly Klaytn) and XPLA each operate an EVM execution layer alongside a Cosmos SDK module. The two layers share the same underlying 20-byte account identifier derived from a secp256k1 public key, so one signer controls both sides simultaneously. Kaia explorers render the same balance as 0x… on the EVM page and kaia1… on the Cosmos page. The Cosmos EVM module used by Cronos, Evmos, and newer chains follows the same pattern: a single keccak256-derived address expressed in two encodings.
Checksum comparison: EIP-55 vs Bech32 EIP-55 mixes the case of each hex letter based on the keccak256 hash of the lowercase address. It detects casing-level mistakes but a fully lowercase address still decodes. Bech32 appends a 6-character BCH checksum over the payload plus human-readable prefix — any single-character change causes decoding to fail outright. Because the prefix is part of the checksum input, copying kaia1… bytes and pasting them with a cosmos prefix will not validate: the checksum is HRP-dependent even though the underlying 20 bytes are identical.
secp256k1 vs Ed25519, and why it does not change the prefix Cosmos Hub uses secp256k1 signatures, Solana uses Ed25519, and Injective mixes in Ethereum-style secp256k1. The Bech32 prefix is a convention chosen by each chain, not a function of the curve. That is why an Injective Ethereum key still renders as inj1… and not as 0x… on the native module side — the encoding layer is independent of the signature scheme.
Real-world Integration When onboarding a Kaia or XPLA user, a dApp often needs the EVM hex form for contract calls but the Cosmos Bech32 form for IBC transfers in the same session. Start by running the user's pasted address through the multi-chain validator to confirm which side they submitted, then use this converter to produce the other representation. Passing the hex output through the Ethereum address checksum tool normalises it to EIP-55 so downstream contract call data matches the casing that block explorers and ABI decoders expect.
Wallet SDKs like Cosmos Kit, Keplr, and Leap sometimes expose only the Bech32 form, while ethers.js and viem expose only the hex form. Server-side indexing jobs that store addresses as lowercase hex will miss events from users whose UI shows them the Bech32 string — running the Bech32 through this tool at ingestion time gives the indexer a canonical hex key to index against, eliminating duplicate user records.
For cross-chain Cosmos deployments, pair this converter with the Bech32 converter to map a single user identity across Kaia (EVM-compatible), Osmosis (pure Cosmos), and Neutron (CosmWasm). The raw 20-byte key is the same, only the HRP changes. This makes airdrop snapshot reconciliation straightforward: dedupe on the raw bytes, then re-encode to each target chain's prefix for the distribution script.
Key Features BIP-173 Bech32 encode and decode with 6-character checksum. EIP-55 checksum applied to the hex output via ethers.getAddress. Presets for Kaia, XPLA, Cosmos, Osmo, Juno, Neutron, Celestia, Injective. Custom prefix support for any SDK-compatible hrp up to 83 characters. Client-side only. No keys, no RPC, no tracking. Frequently Asked Questions Q: Is this Bech32 or Bech32m? A: Cosmos SDK chains and dual-chain networks use classic Bech32 (BIP-173). Bech32m (BIP-350) is used by Taproot. The bech32 package in use here handles the classic variant, which is what kaia, xpla, cosmos, osmo, and similar prefixes expect.
Q: Does the checksum protect against typos? A: Yes. Both EIP-55 mixed-case hex and the 6-character Bech32 checksum detect every single-character substitution. A wrong char causes decoding to fail, which is safer than silently treating the address as a new key.
Q: Can I convert a 32-byte key? A: No. This tool is for 20-byte EVM-compatible addresses. Validator consensus addresses (cosmosvaloper, cosmosvalcons) and 32-byte keys need a different payload size and are not supported here.
Q: Are funds at risk during conversion? A: No. The tool only re-renders the address string. Funds depend on the private key, which is never entered, generated, or transmitted.
Q: What happens if the Bech32 prefix is too long? A: Bech32 allows a prefix up to 83 characters. Longer prefixes cause the bech32 package to throw and the tool reports the error inline.