I have an function as shown below and I an inserted json into the contract. The string actually seems to be after the first 100 bytes and I am little confused by this.

Here is the function -

function addInventory ( string inventory, bytes32 hashInventory) public {
    inventories[hashInventory] = inventory;

Whole input to the Transaction -


The string is -

{"customer_ref_2":"","warehouse_name":"FTZ","location":"Amsterdam","inventory_id":"FTZ-MT37","bol_number":"324920","commodity_type":"Aluminium","commodity_description":"Aluminium Ingots","weight_in_mt":"19.998","owner":"Concord Resources Ltd","customer_ref_1":"TX South 32"}

This corresponds to -


Solidity put the hash before the string, and the format seems to be hash, number 1, string.

The hash of the string is -


Is the 00..1 some kind of parameter count to the function? Also it seems to put the string after the hash but the function had the string first.

Can anyone explain that?

Edit -

This is the field that confuses me -


It is 63 characters. I expected 32 byte blocks. But I checked the strings and the hash ends and the string starts 63 chars later so 1 char is lost somehow.

1 Answer 1


https://solidity.readthedocs.io/en/v0.4.24/abi-spec.html gives the details of how arguments are encoded. In particular, the "Use of Dynamic Types" example is probably the most relevant.

In particular in your data:

  • 513303f4 is the function selector (first four bytes of the keccak256 hash of "addInventory(string,bytes32)")
  • 0000000000000000000000000000000000000000000000000000000000000040 is the offset to the start of the string parameter data.
  • 651cf427005fbe7159b59790d64aa3b1babb70c8d40a8c44e707582e0e2100a3 is the bytes32 parameter.
  • 0000000000000000000000000000000000000000000000000000000000000112 is the length of the string parameter data.
  • The rest (7b2263...) is the ASCII-encoded string data (including some right padding).
  • that is brilliant. The extra char got me but after checking it did not change the ascii conversion at all. Commented Jun 6, 2018 at 15:58
  • As for the field that confuses you (sorry, didn't see that edit), it is 32 bytes (64 hex characters), and it ends in 0112.
    – user19510
    Commented Jun 6, 2018 at 16:38
  • when I did the conversion to ascii the extra byte did not change the string output. But the input is still in reverse order in the txn to the actual func. I assume the VM puts the fixed length fields first. Commented Jun 7, 2018 at 11:17
  • 0x12 in ASCII is a "device control" character, so it's not visible. As to the ordering of fields, it's sort of true that fixed-length fields come first. I linked to the full details of how arguments are ABI encoded.
    – user19510
    Commented Jun 7, 2018 at 14:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.