Crypto Address Formats: A Field Guide for Swaps (2026)

Two addresses of the same length can belong to chains with nothing in common. On 27 October 2026 we pulled recent blocks from five chains and counted the shapes: Bitcoin block 973,380 carried 49 payable outputs in exactly three lengths — 20 at 42 characters, 22 at 34, 7 at 62 — while Litecoin block 3,202,605 produced 45 outputs at 43, 34 and 63 characters, and a single Tron block, 87,479,169, contained 524 transactions whose addresses are all 34 characters starting with T. Character count narrows the field; it never names the chain.

The families, by prefix and length. Bitcoin: 1… and 3… are 34 characters of base58check, bc1q… is 42 for a v0 single-sig output and 62 for v0 multisig, bc1p… is 62 and carries a taproot key. Litecoin: L…, M… and 3… are 34; ltc1q… is 43 for single-sig and 63 for multisig; ltcmweb1… is 121 characters of bech32 and lives in the extension block. Zcash: t1… and t3… are 35, zs1… is a Sapling shielded address, u1… is a unified address, and d-… is 34 characters of null-data that looks like an address and cannot receive anything. Monero: 4… is primary, 8… is a subaddress, both 95 characters; an integrated address is 106 and still starts with 4. Tron: T… is always 34. EVM chains: 0x plus 40 hex digits, always 42. Solana: base58, no prefix, 43 to 44 characters for 32 bytes. (SOL to XMR guide)

What the checksum actually covers. Four different mechanisms are in play, and they fail in different ways. Legacy Bitcoin, Litecoin, Zcash t-addresses and Tron all use base58check: take the payload, hash it twice with SHA-256, append the first four bytes, then base58-encode the whole thing. Tron's payload is 21 bytes because it starts with the byte 0x41, which is why every T address decodes to a 0x41-prefixed account. Monero does something else entirely: it encodes in 8-byte blocks, each block becoming 11 base58 characters (the final 5 bytes become 7), and the four checksum bytes are the first four bytes of Keccak-256. That is why a Monero address is 95 characters and not 94 or 96 — the length is arithmetic, not policy. SegWit uses bech32, a BCH-style checksum over the human-readable part and the data, with two constants: v0 outputs must use the constant that means bech32, v1 and later must use bech32m. And EIP-55 has no checksum bytes at all: it hides the check in the capitalisation of the hex letters, so 0xdac1… and 0xdAC1… are the same account written two ways, one unverified and one verified. (BCH to XMR guide)

Watch what the chains actually produce. Bitcoin block 973,380: 20 P2WPKH at 42 characters, 14 P2SH and 8 P2PKH at 34, 5 P2WSH and 2 P2TR at 62 — the 62-character group is split between two script types that only the prefix and the checksum variant distinguish. Block 973,390 looked similar: 41 payable outputs among 44 outputs — 24 at 42 characters, 12 at 34, 5 at 62. Litecoin block 3,202,605: 29 P2WPKH at 43 characters (one longer than Bitcoin's, because the bech32 payload lands in a different range), 8 P2PKH and 7 P2SH at 34, 1 P2WSH at 63. Zcash, 100 consecutive outputs: 80 t1 pubkeyhash and 14 t3 scripthash, all 35 characters, plus 6 d- null-data outputs at 34. Tron block 87,479,169: 524 transactions, every single address 34 characters starting with T, split across 201 plain transfers, 118 contract calls, 92 undelegations, 72 delegations and 41 TRC-10 transfers. (Zcash vs Monero 2026)

What this site's validator does with each string. We compiled the validator the order endpoint uses and pushed vectors through it. Monero: a real 95-character primary address, a 95-character subaddress starting with 8 and a 106-character integrated address all passed; the same primary address with its last character changed returned 'address checksum mismatch — a character was likely mistyped or the address was truncated'. Bitcoin: P2PKH at 34 characters, P2WPKH at 42 and an all-uppercase bc1q form passed (bech32 permits all-caps), mixed case was rejected, and a taproot program encoded with the bech32 constant instead of bech32m was refused with 'v1+ segwit address must use bech32m'. EVM: all-lowercase and EIP-55 mixed case passed, a single changed character failed with 'EIP-55 checksum mismatch — a character was likely mistyped', and an all-uppercase 0X form was rejected outright. Tron: a real T address from block 87,479,169 passed, one changed character failed, and an EVM address in a Tron field was refused with 'not a TRON address (expect T followed by 33 base58 characters)'. Zcash: t1 and t3 passed, a one-character edit failed; zs1… and u1… are shape-checked only, by design. The live endpoint applies the same gate before it talks to any provider — a bad Monero payout returned HTTP 400 'invalid_destination_address: address checksum mismatch…', a Litecoin address as a Bitcoin payout returned 'not a Bitcoin address (expect bc1…, 1… or 3…)'. Addresses are capped at 256 characters, memos at 128. (Zcash vs Monero 2026)

Six ways this goes wrong in practice. One: trusting a 34-character string. Bitcoin 1… and 3…, Litecoin L… and M…, Tron T… and Zcash d-… are all 34, and only the first character separates them. Two: trusting 42. A Bitcoin P2WPKH and every EVM address are 42, and one is base58-ish bech32 while the other is hex — a wallet that accepts both on the same screen is a wallet that will one day pay the wrong chain. Three: changing the case of a bech32 or EIP-55 address 'to make it readable'. All-caps bech32 is legal; mixed case is not, and mixed case on EVM is the checksum itself. Four: copying a d- string out of a Zcash explorer. Those 6 of 100 outputs are null-data payloads, not payable addresses, and the validator refuses them. Five: treating a Monero integrated address as interchangeable with a subaddress. Both are accepted by the field and both are 95 or 106 characters, but upstream support for the 106-character form differs, and only 7 of the 546 assets in the catalogue take a memo at all. Six: sending to a Zcash zs1… or u1… address that has a typo. The validator only checks the shape, so the typo survives locally and dies upstream, or does not die at all. (Zcash vs Monero 2026)

The gap we have to be honest about. The dispatcher picks a validator by ticker and network. Monero, Bitcoin, Zcash, Tron, Solana and EVM assets are mapped; Litecoin is not. In the run above, an LTC payout field accepted a real M-segment address, a valid ltc1q address, a Bitcoin 1A1z… address, and an ltc1q address with one character changed — all four returned ok. So for LTC the checksum protection does not exist yet on our side, and a copy-paste error in that field will reach the upstream provider with a clean bill of health. Until that branch is added, verify LTC addresses by hand: count 34 characters for L…/M…, 43 or 63 for ltc1…, and compare the last six characters against the wallet that generated the address, not against your clipboard. The same caution applies to any asset outside those six families — a Dogecoin or Bitcoin Cash address is shape-checked at best, and those fields will accept strings that no wallet can spend to. (BCH to XMR guide)

The five-second check before you paste. Match the prefix to the network printed next to the field, not to the network in your head — 1… and bc1q… are both Bitcoin, but L… is not. Count the characters against the table above; a 34-character string in a field that expects 42 is a wrong-chain paste, not a typo. Never retype an address by hand and never trust the clipboard as the source of truth: compare the last six characters on the device that holds the keys. For EVM payout addresses keep the mixed case exactly as your wallet displays it. For Monero, 4… or 8… at 95 characters, or 106 for an integrated address. For Zcash, know that zs1… and u1… are shape-checked only, so a typo there has to be caught by you. And if an asset takes a memo, the address alone is not the destination — 7 of the 546 assets in the catalogue need that second field. (Zcash vs Monero 2026)

None of this is exotic. It is the ordinary arithmetic of address formats, and it is the last place in a swap where you still have full control: once the deposit is broadcast, nobody — not us, not the provider, not the chain — can redirect it. As of writing, 27 October 2026 around 14:10 UTC, this site quoted 100 USDT-TRC20 at 0.14951806 XMR and 5,000 USDT at 8.35131069 XMR, which is 668.8 and 598.7 USDT per XMR against a spot of 587.79 — the small order carries roughly 15 dollars of fixed cost, which is a separate problem from the address. 1 XMR sold for 571.095008 USDT, 0.05 BTC bought 6.70164415 XMR (134.03288 XMR per BTC), 10 LTC bought 0.93300801 XMR (10.7183 LTC per XMR against a spot of 10.6397), and 1 ZEC bought 2.08812226 XMR. Live rates move; the page is the authority. The address you paste is the only number in the order that nobody can re-quote. (XMR to USDT exit)