A reply can contain a destination and a count, with each field interpreted under its own type.
SEE IT FOR YOURSELF
Build a transfer call from typed fieldsStep 1 / 4
The standard transfer interface takes an address and a raw integer amount. This diagram uses address one and amount one hundred.
The standard transfer interface takes an address and a raw integer amount. This diagram uses address one and amount one hundred.Keccak-256 of the canonical signature supplies the first four bytes. The transfer selector is a9059cbb.An address is twenty bytes. Standard ABI encoding adds twelve zero bytes on the left to fill one thirty-two-byte word.The integer one hundred is hex 64, left-padded in word one. Selector plus two words produces sixty-eight bytes of standard calldata.
Animated local teaching model. No wallet, RPC or live blockchain data. Some labels and hashes are abbreviated for readability.
Outputs form a tuple
Returning address and uint256 produces the encodings in declared order. Both are static, so the example needs two words without a dynamic offset prefix.
Names help documentation
A named return can explain what a value means, but the name is not embedded in standard result bytes. The schema and trusted call context supply that meaning.
Order errors can look plausible
Swapping two compatible-looking integer fields can produce a technically decoded but semantically wrong result. Validate the exact ABI and implementation context.
Nested and dynamic results extend the same model
A tuple containing arrays or strings needs the relevant head/tail rules. Do not infer every output is one word merely because a simple example was.
Follow the bytes
types: address,uint256
values: ["0x0000000000000000000000000000000000000001","42"]
no function selector prefix
word 0 · argument offset 0 bytes
0x0000000000000000000000000000000000000000000000000000000000000001
word 1 · argument offset 32 bytes
0x000000000000000000000000000000000000000000000000000000000000002a
The first word is the address; the second is the integer.