One missing letter, one repaid USDC loan, and one Solana transaction that will never come back. That’s the entire story of how a user lost roughly $20,000 this week and it’s reopened a debate that’s been sitting quietly in Solana’s own GitHub repository since 2019.
The user was repaying a loan through a protocol inside the Backpack wallet, copied their own Solana address to complete the transaction on Binance, and pasted it in. Somewhere in that copy-paste, the final character, a “J”, didn’t make it. The truncated string was still, by pure chance, a technically valid Solana address. Binance’s system accepted it. The transaction confirmed.
And because Solana addresses aren’t checked against a master registry of “real” wallets before a transfer goes through, the funds landed on an address that, statistically, almost certainly nobody controls.
What Happened When One Character Vanished
The core problem here isn’t exotic. It’s the oldest mistake in crypto, a truncated address, except Solana’s address format makes this specific mistake far easier to miss than it would be on most other chains. A reply underneath the original post put it bluntly, arguing the fault sits with Solana’s address design itself for not enforcing a fixed length.
That comment is the part worth actually unpacking, because it raises a real, verifiable technical question: is a Solana address supposed to be a fixed length in the first place?
Is A Solana Address Actually A Fixed Length
No and this is where a lot of people get tripped up, myself included the first time I looked into it closely. A Solana address is the Base58-encoded representation of a 32-byte (256-bit) Ed25519 public key. The underlying key is always exactly 32 bytes. But Base58 encoding doesn’t guarantee a fixed-length output for a fixed-length input, leading zero bytes in the raw key collapse during encoding, which means the resulting string can land anywhere between 32 and 44 characters depending on the specific key. That range is well documented across wallet providers and blockchain reference material, and it means there’s no single “correct” character count to eyeball-check against.
That’s a meaningful difference from Ethereum, where every address is a hex string of exactly 42 characters, “0x” plus 40 hex digits, always. Drop a character from an Ethereum address and it becomes instantly, mechanically invalid. Drop one from most Solana addresses, and there’s a real chance the shorter string still falls inside the valid 32–44 character window and still decodes into something that looks like a legitimate key.
Why Solana Addresses Don’t Include A Checksum
Here’s the detail that turns a length quirk into an actual loss-of-funds risk: Solana addresses carry no checksum. Bitcoin solved this exact class of typo years ago with Base58Check, which appends a checksum so a single wrong or missing character causes decoding to fail outright. Ethereum solved it differently with EIP-55 mixed-case checksumming. Solana did neither. A GitHub issue filed against the core Solana repository back in November 2019, titled “Use Base58Check where humans are involved,” flagged this precise gap, that raw Base58 without a checksum is error-prone anywhere a human is manually handling an address. That issue is now years old.
So to directly answer the headline question: Solana address length is not fixed, and the address format has no built-in mechanism to catch a truncation the way other major chains do. Combine variable length with zero checksum, and you get exactly the scenario that played out this week, a shortened address that looked valid enough to pass every check the system actually performs.
Should Solana Take The Blame For This
I don’t think this is a clean-cut case, but Solana’s core design does carry real weight here. The protocol’s own contributors identified the checksum gap years before this incident and it remains unresolved at the base layer. When a chain’s address format allows a truncated string to still parse as valid, and offers users no automated way to catch that error before signing, that’s a protocol-level UX decision with real financial consequences, not just bad luck on the user’s part.
Does Binance Share Responsibility Too
At the same time, exchanges aren’t passive pipes. Binance, like most major platforms, controls its own withdrawal interface, and that’s a layer completely separate from Solana’s protocol. Many exchanges have implemented protections specifically because Solana lacks a native checksum, withdrawal address allowlisting with time delays, mandatory small test transfers before large withdrawals, or visual address chunking that makes a shortened string easier to spot.
If Binance’s withdrawal flow only validated that the pasted string matched Solana’s general Base58 pattern and length range, without any secondary safeguard, that’s a gap in Binance’s own product design, not something dictated by Solana. In a case like this, I’d argue the responsibility is genuinely shared: Solana built an address format that makes a partial paste look legitimate, and the exchange that processed the withdrawal didn’t add a safety net to catch it before the funds moved.
What this means for anyone moving funds on solana
Practically speaking, this incident is a reminder that Solana’s “just verify the address” advice isn’t as reassuring as it sounds, because length alone doesn’t tell you anything is wrong.
If you’re moving meaningful sums on Solana, verifying the full string character-by-character, not just glancing at whether it “looks about right”, matters more than it would on a chain with a checksum baked in. Until Solana’s tooling closes that six-year-old gap, or exchanges build stronger guardrails on their own end, this is a mistake that will keep happening to someone else.
Disclosure: This is not trading or investment advice. Always do your research before buying any cryptocurrency or investing in any services.Â
Follow us on Twitter @themerklehash to stay updated with the latest Crypto, NFT, AI, Cybersecurity, and Metaverse news!
