The Anatomy of a Transaction Receipt

Rob Stupay
Remix Project
Published in
7 min readFeb 25, 2020

--

Have you ever left the supermarket and pulled out the receipt because you wondered what you spent so much money on or if you really did buy that corned beef hash?

Transaction Receipts (txn receipt) in Ethereum are a bit more complicated than a grocery store receipt. Understanding what is in the txn receipt is essential to understand how Ethereum works.

In this article, I’ll go over what happens when a contract is deployed, a transaction receipt is generated, and what Remix shows in its terminal.

Below is the solidity file that I’ll be using in this example. The file is named 2_Owner.sol and it is one of the default solidity files in Remix.

pragma solidity >=0.4.22 <0.7.0;/**
* @title Owner
* @dev Set & change owner
*/
contract Owner {
address private owner;

// event for EVM logging
event OwnerSet(address indexed oldOwner, address indexed newOwner);

modifier isOwner() {
require(msg.sender == owner, "Caller is not owner");
_;
}

/**
* @dev Set contract deployer as owner
*/
constructor() public {
owner = msg.sender;
emit OwnerSet(address(0), owner);
}
/**
* @dev Change owner
* @param newOwner address of new owner
*/
function changeOwner(address newOwner) public isOwner {
emit OwnerSet(owner, newOwner);
owner = newOwner;
}
/**
* @dev Return owner address
* @return address of owner
*/
function getOwner() external view returns (address) {
return owner;
}
}

In Remix, after you have compiled a contract and are in the Deploy & Run module, you will see the Deploy button (see the image below). Clicking this button will start a chain of events that will end with a transaction receipt in Remix’s terminal.

Actually, interacting with any function that costs Gas will generate a txn receipt. There are Gas fees for all functions that save information and change the state of the blockchain.

A deployed contract with 2 functions —changeOwner a “non-payable” function that changes the state and getOwner a “view” function.

In Remix’s Deploy & Run module, buttons that have gas fees are either orange or red. An orange button ( like the one above) is associated with a “not payable” function — meaning it does not accept ether, wei, etc. A red button is associated a “payable” function — meaning that it does accept ether, wei, gwei, etc. For more info see https://remix-ide.readthedocs.io/en/latest/udapp.html#deployed-contracts.

Conversely, when you click on a pure or view function — and in remix these functions have blue submit buttons — these do not change the state of the contract so they don’t consume gas nor do they need to be signed and no txn receipt is created. Nevertheless, in the remix terminal there is a record of what happened.

Under the hood in Remix, when you click on a red or orange button of state changing function, a call is made to the web3.js function sendTransaction with an object that contains the required info & data.

The required information for deploying a contract is different than the required information for an existing contract. This is to say that when you deploy a contract, the contract does not yet have an address — it is returned with the txn receipt — so the to parameter of sendTransaction would be null and if you are interacting with a deployed contract you would have to know its address.

Then, if you using the web3 provider or connecting to a local node — you’ll need to sign the transaction. If you are using the JavaScript Virtual Machine — the signing is done automatically.

Once signed, a transaction ID is created. The Txn ID is the hash of the signed transaction object. It is used to identify the transaction.

( for more on this see: https://medium.com/blockchannel/life-cycle-of-an-ethereum-transaction-e5c66bae0f6e )

The Signed Txn is broadcast to the network where the nodes verify the signing and miner nodes put it in their Txn Pool ( their queue of transaction waiting to get included in the chain). The transactions are typically lined up in order of gas price.

If a transaction gets picked by a miner and that the miner succeeds to mine the block, then the Txn Receipt is generated and added to the block. The block is then broadcast to the network where the other nodes verify it and append it to the chain.

At this point, Remix can retrieve the Txn Receipt and display it in the terminal.

Actually it is displayed in its rolled up state.

a successful txn in the rolled up state

Unroll it by clicking the caret on the right side of the terminal or by clicking the green check or red X on the left side of the terminal. And if you want to start a debugging session — click on the Debug button. (The debugger will be the subject of another article)

Here’s the Txn receipt for a transaction where I deployed the contract 2_Owner.sol — from the default contracts in Remix files explorer.

a txn receipt in the Remix terminal

In this example the fields are:

status: true or false — which informs us if the txn was reverted or not — in this case it was true (0x1).

transaction hash: this is the ID of the transaction

contract address: where the contract got deployed to

from: address of the msg.sender

to: Owner.(constructor) — this is Remix elaborating what is in the Txn Receipt — because in the receipt — when the to address is null— it means that this is the deployment of a new contract.

gas: This is the gas limit. In Remix, the gas limit is set on the top section of the Deploy & Run Transactions plugin.

transaction cost: the amount of gas used

execution cost: this is the code execution portion of the transaction cost

hash: this is the transaction hash again

input: this is the encoded input

decoded input: this is the decoded input parameters. In the contract I deployed, there is no input parameters for the contract’s constructor — so there is nothing here.

decoded output:

logs: The logs are generated when there is an event in the smart contract. So if there is no event, then there are no logs generated.

value: the amount of wei sent with this transaction.

Here’s the logged object:

[  {    "from": "0x692a70d2e424a56d2c6c27aa97d1a86395877b3a",    "topic": "0x342827c97908e5e2f71151c08502a66d44b6f758e3ac2f1de95f02eb95f0a735"      ,"event": "OwnerSet","args": {"0": "0x0000000000000000000000000000000000000000","1": "0xCA35b7d915458EF540aDe6068dFe2F44E8fa733c","oldOwner": "0x0000000000000000000000000000000000000000","newOwner": "0xCA35b7d915458EF540aDe6068dFe2F44E8fa733c","length": 2    }  }]

“from”: is the account I had deployed the contract from.

topic” : is the encoded name of the event and its parameters listed by their types.

“event” : The event that got emitted in the contract when the owner has changed. This event is emitted in the constructor or when interacting with the changeOwner method.

“args”: is a list of the parameters for the event. The first 2 elements of this array are the parameters listed in the order that they occur and the next 2 elements are the parameters listed by name. There are 2 parameters in the event in the 2_Owner.sol file. So the number of elements in this array depends on how many parameters there are for the event.

[

0: 0x000000 — as defined in the constructor’s emit.

1: is the new owner.

OldOwner: is from the event emitted in the contract

NewOwner: is also from the event emitted in the contract

]

After the object there are 2 copy icons. The first copies the logs as it is and the second copies the data encoded.

Remix is going back and forth between a graphic user interface with human readable language for humans and encoding and hashing for the blockchain. The transaction receipt shows some basic information about transaction and what the author of the contract put in it to help communicate with the outside world through it’s events.

A transaction receipt is the outcome of interaction a user has made with Ethereum Blockchain. Its shows both standardized information about what occurred ( status, txn hash, contract address, etc) and also custom information from the events emitted in the smart contract. The transaction receipt does contain encoded information and Remix attempts to display this info so that you humans can read it.

Just like a grocery store receipt, a txn receipt shows you some basic information about what happened, how much it cost, if you hit upon something special ( like an event or a special discount on butter) as well as what functions you interacted with or if you really did get that corned beef hash.

--

--