Transactions¶
Tx¶
Field | Type | Description | |
---|---|---|---|
Hash | bytes | Hash of body | |
Body | Nonce | uint64 | Increasing number used only once per sender account |
Account | bytes | Decoded sender account address | |
Recipient | bytes | Decoded receiver account address | |
Amount | bytes | Amount of transfer | |
Payload | bytes | Smart contract data | |
Limit | uint64 | Reserved | |
Price | bytes | Reserved | |
Type | int | 0 is normal type, 1 is governance type | |
Sign | bytes | ECDSA signature with secp256k1 |
Payload¶
A payload can be any kind of binary data, but is most often used with JSON strings for smart contract calls.
Transaction types¶
There are two kinds of transactions.
Normal type¶
Normal transactions are used to transfer tokens and calling smart contracts.
Governance type¶
Governance transactions are used for calling system contracts, such as staking and voting. Transactions of this type have a special payload format and recipient.
The following table shows the specification for each field of the transaction body.
Action | Recipient | Amount | Payload |
---|---|---|---|
staking | aergo.system |
amount to stake | {"Name":"v1stake"} |
unstaking | aergo.system |
amount to unstake | {"Name":"v1unstake"} |
voting | aergo.system |
0 | {"Name":"v1voteBP","Args":[<peer IDs>]} |
create name | aergo.name |
1 aergo | {"Name":"v1createName","Args":[<a name string>]} |
update name | aergo.name |
1 aergo | {"Name":"v1updateName","Args":[<a name string>, <new owner address>]} |
The aergo.system transactions, including staking, unstaking and voting, can be sent about once per day per account. For staking and unstaking, there is a limit to the amount of requests. It must be over 10000 aergo based on the amount of staked. Therefore, the first staking request should exceed 10000 aergo, and in the case of the unstaking request, more than 10000 must be left or withdrawn altogether.
Transaction receipts¶
See also
See API → Receipt for a detailed explanation of all the receipt data.
Every transaction generates a receipt upon succesful execution.
The status
can be one of three values:
- SUCCESS
- Simple value transfer transactions and succesful contract executions.
For contract calls, the result is available in
result
. - ERROR
- Failed contract execution. The error message can be found in
result
. - CREATED
- Succesful contract deployment transaction. The created address can be found in
contractAddress
.