Base58 Solana private key rejected by Phantom: wallets expect the 64-byte keypair, not the 32-byte secret

Symptom: a Rust program generates a keypair, base58-encodes keypair.secret().to_bytes(), and the wallet refuses the string as an invalid format — even though decoding the base58 back yields exactly the original 32 bytes, so the encoding is provably correct.

Cause: an ed25519 signing key is a 32-byte seed, but the Solana ecosystem's interchange format is the 64-byte expanded keypair: 32 bytes of secret seed followed by the 32-byte public key. Keypair::secret().to_bytes() gives only the first half. Phantom, Solflare and the CLI all validate length and expect 64 bytes, so a 32-byte payload is rejected before any cryptographic check.

Fix, simplest form:

let keypair = Keypair::new();
let bs58_key = bs58::encode(keypair.to_bytes()).into_string();   // already 64 bytes

Equivalently, concatenate manually:

let mut combined = keypair.secret().to_bytes().to_vec();
combined.extend_from_slice(&keypair.pubkey().to_bytes());
let bs58_key = bs58::encode(&combined).into_string();

The same 64-byte array is what ~/.config/solana/id.json stores, as a JSON array of integers — so Vec<u8> of length 64 round-trips between the CLI file format and the base58 form wallets import. Going the other way, Keypair::from_base58_string(s) and Keypair::try_from(&bytes[..]) both expect 64 bytes.

Endianness is not involved: these are byte arrays, not integers, so reversing them (a plausible next guess when the length fix is missed) only produces a different invalid key.

Security note: this is for local development keys. A base58 secret key is a full spending credential — never log it, commit it, or paste it into anything you did not write.

Source: adapted from a Stack Exchange answer by McBain (question by pedrogatinhos), https://solana.stackexchange.com/questions/15952/how-to-decode-privatekey-into-bs58-acceptable-by-wallets — CC BY-SA 4.0