Skip to main content
added 350 characters in body
Source Link
minhhn2910
  • 1.8k
  • 5
  • 14

According to ABI specification, that input data ends at ...c756cc20c756cc2.

"types": [
    "address",
    "(address,address,address,address,uint256,uint256,uint256)",
    "bytes",
    "bytes"
  ]

The first 8 fixed length parameters are easy to guess because they have 32 bytes each. The two bytes arrays follows:

...000000140 
...000000160

The first bytes array is from byte offset 0x140 which points us to 32 bytes with value 0x0 meaning this byte array is blank.

The second byte array is from offset 0x160, this points to the length of the array ...0000110 = 272 bytes. Counting 272 bytes from the next 32-byte slot, the data ended at c756cc2 and the last part 0x000...e26b9977 is ignored.

According to past answers here, extra data are ignored and does not cause error Is it legal to include arbitrary bytes at the end of the DATA section executing a contract method?

About answer why, I think it could be either error in transaction encoding part or the possibility that the one who crafts that transaction use it for some extra logic off-chain (for example, their own script tracks different txs based on this extra data). Looking at similar txs to 1inch, it's likely that 1inch frontend does this intentionally.

According to ABI specification, that input data ends at ...c756cc20.

"types": [
    "address",
    "(address,address,address,address,uint256,uint256,uint256)",
    "bytes",
    "bytes"
  ]

The first 8 fixed length parameters are easy to guess because they have 32 bytes each. The two bytes arrays follows:

...000000140 
...000000160

The first bytes array is from byte offset 0x140 which points us to 32 bytes with value 0x0 meaning this byte array is blank.

The second byte array is from offset 0x160, this points to the length of the array ...0000110 = 272 bytes. Counting 272 bytes from the next 32-byte slot, the data ended at c756cc2 and the last part 0x000...e26b9977 is ignored.

According to past answers here, extra data are ignored and does not cause error Is it legal to include arbitrary bytes at the end of the DATA section executing a contract method?

According to ABI specification, that input data ends at ...c756cc2.

"types": [
    "address",
    "(address,address,address,address,uint256,uint256,uint256)",
    "bytes",
    "bytes"
  ]

The first 8 fixed length parameters are easy to guess because they have 32 bytes each. The two bytes arrays follows:

...000000140 
...000000160

The first bytes array is from byte offset 0x140 which points us to 32 bytes with value 0x0 meaning this byte array is blank.

The second byte array is from offset 0x160, this points to the length of the array ...0000110 = 272 bytes. Counting 272 bytes from the next 32-byte slot, the data ended at c756cc2 and the last part 0x000...e26b9977 is ignored.

According to past answers here, extra data are ignored and does not cause error Is it legal to include arbitrary bytes at the end of the DATA section executing a contract method?

About answer why, I think it could be either error in transaction encoding part or the possibility that the one who crafts that transaction use it for some extra logic off-chain (for example, their own script tracks different txs based on this extra data). Looking at similar txs to 1inch, it's likely that 1inch frontend does this intentionally.

Source Link
minhhn2910
  • 1.8k
  • 5
  • 14

According to ABI specification, that input data ends at ...c756cc20.

"types": [
    "address",
    "(address,address,address,address,uint256,uint256,uint256)",
    "bytes",
    "bytes"
  ]

The first 8 fixed length parameters are easy to guess because they have 32 bytes each. The two bytes arrays follows:

...000000140 
...000000160

The first bytes array is from byte offset 0x140 which points us to 32 bytes with value 0x0 meaning this byte array is blank.

The second byte array is from offset 0x160, this points to the length of the array ...0000110 = 272 bytes. Counting 272 bytes from the next 32-byte slot, the data ended at c756cc2 and the last part 0x000...e26b9977 is ignored.

According to past answers here, extra data are ignored and does not cause error Is it legal to include arbitrary bytes at the end of the DATA section executing a contract method?