fix(erc20): add zero-address validation in transfer (#975)

[aglichandrap]

Problem

The ERC-20 precompile's transfer() and transferFrom() functions do not validate that the recipient address is non-zero. Per ERC-20 standard (EIP-20), transfers to address(0) should revert, but currently they succeed, causing permanent token loss.

Fix

Added zero-address validation in the common transfer() function:

if to == (common.Address{}) {
    return nil, fmt.Errorf("%w: %s", erc20.ErrERC20, "transfer to zero address")
}

This check covers both Transfer and TransferFrom since they both call transfer().

Testing

• Transfer(to=0x0, amount=100) → should revert
• Transfer(to=validAddr, amount=100) → should succeed
• TransferFrom(from=validAddr, to=0x0, amount=100) → should revert

Fixes #975

[greptile-apps]

PR author is not in the allowed authors list.

[aljo242]

no test coverage for the new zero-address guard. the pr description lists three cases — please add them:

• transfer(to=address(0), amount>0) should revert
• transferFrom(from=valid, to=address(0), amount>0) should revert
• transfer(to=validAddr, amount>0) should still pass

also worth adding a from == address(0) check for transferFrom — transfers from the zero address are also invalid per erc-20 spec.

[aljo242]

missing tests for the new zero-address guard and missing from == address(0) check in transferFrom.

[aglichandrap]

Thanks for the review @aljo242! I've addressed both points:

1. Tests for zero-address guard

Tests were already added in commit d8f8c470:

• TestTransfer: "fail - transfer to zero address" (line 122)
• TestTransferFrom: "fail - transfer to zero address" (line 265)
• TestTransferFrom: "fail - transfer from zero address" (line 274)

2. from == address(0) check in TransferFrom

Added in commit 291d8502:

// Validate that the sender is not the zero address.
if from == (common.Address{}) {
    return nil, fmt.Errorf("%w: %s", erc20.ErrERC20, "transfer from zero address")
}

Also updated the test expectation to match the new error message (was "insufficient allowance", now "transfer from zero address").

All 3 requested test cases are now covered with proper validation.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days-before-close if no further activity occurs.