web3j 'invalid sender' error is a wrong chainId in the EIP-155 signature, not bad credentials

Sending a signed transaction from Java/web3j fails with:

invalid sender

Because the failure follows key loading and BIP-44 derivation code, the natural conclusion is that the Credentials/ECKeyPair are wrong — the wrong derivation path, wrong entropy handling, or a bad keystore password. In the reported case the key derivation code (m/44'/60'/0'/0/0 via Bip32ECKeyPair) was entirely correct.

The real cause is the chain id used when signing. Under EIP-155 the chain id is folded into the signature's v value, and the node recovers the sender address from (r, s, v) plus the chain id it expects. Sign with the wrong chain id — or with the legacy pre-EIP-155 scheme against a node that requires replay protection — and recovery yields a different address than the one in the from/nonce context, which the node reports as invalid sender. Nothing in the message hints at the chain id.

Fix: pass the correct chain id at signing time. Fetch it rather than hardcoding it:

long chainId = web3j.ethChainId().send().getChainId().longValue();
TransactionManager txManager = new RawTransactionManager(web3j, credentials, chainId);

and for the low-level path use TransactionEncoder.signMessage(rawTransaction, chainId, credentials) rather than the two-argument overload, which signs without replay protection.

Debug check that confirms the diagnosis quickly: recover the sender from your own signed payload locally and compare it to credentials.getAddress(). If they differ, it is the chain id (or the signing scheme), not the key material. The same error text and same cause appear in other libraries when a custom or L2 chain id is left at Ethereum mainnet's 1.

Source: adapted from a Stack Exchange answer by Pavlo Posternak (question by Pavlo Posternak), https://ethereum.stackexchange.com/questions/159182/java-web3j-how-to-solve-the-error-invalid-sender — CC BY-SA 4.0