Contract ABI Specification
The Contract Application Binary Interface (ABI) is the standard way to interact with contracts in the Ethereum ecosystem, both from outside the blockchain and for contract-to-contract interaction. Data is encoded according to its type, as described in this specification. The encoding is not self describing and thus requires a schema in order to decode.
We assume the interface functions of a contract are strongly typed, known at compilation time and static. We assume that all contracts will have the interface definitions of any contracts they call available at compile-time.
This specification does not address contracts whose interface is dynamic or otherwise known only at run-time.
The first four bytes of the call data for a function call specifies the function to be called. It is the first (left, high-order in big-endian) four bytes of the Keccak-256 (SHA-3) hash of the signature of the function. The signature is defined as the canonical expression of the basic prototype without data location specifier, i.e. the function name with the parenthesised list of parameter types. Parameter types are split by a single comma — no spaces are used.
Starting from the fifth byte, the encoded arguments follow. This encoding is also used in other places, e.g. the return values and also event arguments are encoded in the same way, without the four bytes specifying the function.
The following elementary types exist:
uint<M>: unsigned integer type of
0 < M <= 256,
M % 8 == 0. e.g.
int<M>: two’s complement signed integer type of
0 < M <= 256,
M % 8 == 0.
address: equivalent to
uint160, except for the assumed interpretation and language typing. For computing the function selector,
int: synonyms for
int256respectively. For computing the function selector,
int256have to be used.
bool: equivalent to
uint8restricted to the values 0 and 1. For computing the function selector,
fixed<M>x<N>: signed fixed-point decimal number of
8 <= M <= 256,
M % 8 ==0, and
0 < N <= 80, which denotes the value
v / (10 ** N).
ufixed<M>x<N>: unsigned variant of
ufixed: synonyms for
ufixed128x18respectively. For computing the function selector,
ufixed128x18have to be used.
bytes<M>: binary type of
0 < M <= 32.
function: an address (20 bytes) followed by a function selector (4 bytes). Encoded identical to
The following (fixed-size) array type exists:
<type>[M]: a fixed-length array of
M >= 0, of the given type.
The following non-fixed-size types exist:
bytes: dynamic sized byte sequence.
string: dynamic sized unicode string assumed to be UTF-8 encoded.
<type>: a variable-length array of elements of the given type.
Types can be combined to a tuple by enclosing them inside parentheses, separated by commas:
(T1,T2,...,Tn): tuple consisting of the types
n >= 0
It is possible to form tuples of tuples, arrays of tuples and so on. It is also possible to form zero-tuples (where
n == 0).
Mapping Solidity to ABI types
Solidity supports all the types presented above with the same names with the exception of tuples. On the other hand, some Solidity types are not supported by the ABI. The following table shows on the left column Solidity types that are not part of the ABI, and on the right column the ABI types that represent them.
uint type that is large enough to hold all values
For example, an
enum of 255 values or less is mapped to
enum of 256 values is mapped to