Why some ERC20 tokens have different Transfer event ABI signature than Transfer(address,address,uint256)?

Question

Looking at ChainLink ABI (using this tool) I see

{
"anonymous": false,
"inputs": [
  {
    "indexed": true,
    "name": "from",
    "type": "address"
  },
  {
    "indexed": true,
    "name": "to",
    "type": "address"
  },
  {
    "indexed": false,
    "name": "value",
    "type": "uint256"
  },
  {
    "indexed": false,
    "name": "data",
    "type": "bytes" <----- HERE
  }
],
"name": "Transfer",
"type": "event"
}

a fourth field "data" that results in signature Transfer(address,address,uint256,bytes) which translates to Keccak-256 hash of 0xe19260aff97b920c7df27010903aeb9c8d2be5d310a2c67824cf3f15396e4c16 which is different from 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef that I expect to look for.

At the same time Etherscan show the correct function hash. What I am doing wrong here? I am parsing the ABI and generating signatures for each event and this works fine for other ERC20 tokens from top 10.

"0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef" => array:4 [
"anonymous" => false
"inputs" => array:3 [
  0 => array:3 [
    "indexed" => true
    "name" => "from"
    "type" => "address"
  ]
  1 => array:3 [
    "indexed" => true
    "name" => "to"
    "type" => "address"
  ]
  2 => array:3 [
    "indexed" => false
    "name" => "value"
    "type" => "uint256"
  ]
]
"name" => "Transfer"
"type" => "event"
]

Answer 1

ERC-20 is a standard. It says what kind of functions and events the contract should have, in order to be ERC-20 compliant. It even dictates some small details about how the functions should be implemented.

The problem with such standards is that it's next to impossible to enforce their usage. In theory, lots of things should be done in a contract for it to be ERC-20 compatible. In reality, quite many contracts claim to be ERC-20 compatible even if they do some things differently.

One such different thing may be the event signature. The standard (https://eips.ethereum.org/EIPS/eip-20) says that the Transfer event has to have the signature you expected. But that's impossible to enforce.

You may claim that the token is then not ERC-20 compliant, and you might be right. Unfortunately, for most parties, it's close enough that they accept it as it is.

Furthermore, it's next to impossible to determine which contract is fully ERC-20 compliant and which is not. For example you can't be sure that the contract emits the same event every time - maybe every 100th time it emits a different event. Unless you analyze the source code by hand.

Simply put: you just have to accept the fact that some "ERC-20 compliant" tokens are only close enough.

Answer 2

The LINK token is actually not an ERC-20 token but an ERC-677 token.

This token standard has a function transferAndCall:
function transferAndCall(address receiver, uint amount, bytes data) returns (bool success)

This transfers tokens to receiver, via ERC20's transfer(address,uint256) function. It then logs an event Transfer(address,address,uint256,bytes). Once the transfer has succeeded and the event is logged, the token calls onTokenTransfer(address,uint256,bytes) on the receiver with the sender, the amount approved, and additional bytes data as parameters.