[Bug]: precompile/common.AfterBalanceChange panics on addresses that are not 20-bytes long

[Pitasi]

Is there an existing issue for this?

• I have searched the existing issues

What happened?

I have a precompile that moves funds from users to "system" accounts used as escrow.

The addresses generated for these escrow accounts are made like this:

func (k *Keychain) AccAddress() sdk.AccAddress {
	bz := make([]byte, 8)
	binary.BigEndian.PutUint64(bz, k.Id)
	addr := append([]byte("keychain-"), bz...)

	return addr
}

For example, they look like this: warden1ddjhjcmgv95kutgqqqqqqqqqqqqs5sgg2s

The newly introduced call to AfterBalanceChange(...) for the precompile revert logic, tries to parse all addresses that sent or received tokens as 20-bytes long byte arrays here:

evm/precompiles/common/balance_handler.go

Line 87 in af6f8d4

return common.Address(accAddr.Bytes()), nil

This lead to a panic in my particular use case:

runtime error: cannot convert slice with length 17 to array or pointer to array with length 20

My question is:

• should I change my logic? Is it a bad practice to have these custom addresses and working with the EVM?
• or, is there a way to fix AfterBalanceChange?

Cosmos EVM Version

main

How to reproduce?

No response

[linear]

EVM-145 [Bug]: precompile/common.AfterBalanceChange panics on addresses that are not 20-bytes long

[cloudgray]

Thanks for surfacing this — it's a very relevant edge case when bridging Cosmos-native address logic into EVM precompile environments.

I noticed that PR #276 has been opened to address exactly this issue. It replaces the direct conversion to common.Address(accAddr.Bytes()) with a safer call to common.BytesToAddress(...), which gracefully handles variable-length input by left-padding to 20 bytes. This should prevent the panic in cases like yours where the sdk.AccAddress is shorter than 20 bytes.

That said, even with that fix in place, it's generally recommended to use 20-byte addresses for any accounts that interact with EVM precompiles. While Cosmos SDK supports variable-length AccAddress values, relying on implicit padding can lead to subtle bugs — for example:

• Inconsistencies when hashing or encoding addresses within Solidity contracts.
• Mismatches in log topics or off-chain indexing tools due to padded vs. native forms.
• Friction when integrating with external systems expecting canonical 20-byte EVM addresses.

If feasible, you might consider updating your system-generated escrow accounts to follow a fixed 20-byte address format. It’s not strictly required, but it will help avoid edge cases and improve long-term compatibility.

[Pitasi]

Agree.

It's not my case but addresses longer than 20 bytes wouldn't work anyway.

I think I'll just take the last 20 bytes of a hash, similarly to how normal addresses are generated.

Thanks!