41

Within a Solidity function, is the transaction hash available as a global variable from within the contract? I would have thought it would be something like tx.hash in the same way you can do tx.origin etc.

My thinking is that the transaction hash will not be available until the contract has been mined. Is this correct?

1

1 Answer 1

36

Here you have all the global variables in Solidity:

Global Variables

  • block.coinbase (address): current block miner’s address
  • block.difficulty (uint): current block difficulty
  • block.gaslimit (uint): current block gaslimit
  • block.number (uint): current block number
  • block.blockhash (function(uint) returns (bytes32)): hash of the given block - only works for 256 most recent blocks
  • block.timestamp (uint): current block timestamp
  • msg.data (bytes): complete calldata
  • msg.gas (uint): remaining gas
  • msg.sender (address): sender of the message (current call)
  • msg.value (uint): number of wei sent with the message
  • now (uint): current block timestamp (alias for block.timestamp)
  • tx.gasprice (uint): gas price of the transaction
  • tx.origin (address): sender of the transaction (full call chain)
  • keccak256(...) returns (bytes32): compute the KECCAK256 hash of the (tightly packed) arguments
  • sha256(...) returns (bytes32): compute the SHA256 hash of the (tightly packed) arguments
  • ripemd160(...) returns (bytes20): compute RIPEMD of 256 the (tightly packed) arguments
  • ecrecover(bytes32, uint8, bytes32, bytes32) returns (address): recover public key from elliptic curve signature
  • addmod(uint x, uint y, uint k) returns (uint): compute (x + y) % k where the addition is performed with arbitrary precision and does not wrap around at 2**256.
  • mulmod(uint x, uint y, uint k) returns (uint): compute (x * y) % k where the multiplication is performed with arbitrary precision and does not wrap around at 2**256.
  • this (current contract’s type): the current contract, explicitly convertible to address
  • super: the contract one level higher in the inheritance hierarchy
  • selfdestruct(address): destroy the current contract, sending its funds to the given address
  • <address>.balance: balance of the address in Wei
  • <address>.send(uint256) returns (bool): send given amount of Wei to address, returns false on failure.

As you say, as the transaction is not mined you can't find here the tx.hash.

8
  • 4
    It's the same reason you can't do block.hash(block.number), since the blockhash depends on the result of the contract execution, so it's a circular reference. Apr 5, 2016 at 17:34
  • 8
    Actually, the transaction hash only depends on the data of the transaction (example: 0xabc sends 0xcde 10 Ether with nonce n, gas g...), not its execution.
    – eth
    Jul 26, 2016 at 11:46
  • 31
    The TxHash is known indeed before the block is mined. It is the first info the caller get in the callback. So why cannot it be available in the EVM. This would be nice. Feb 20, 2017 at 6:00
  • 2
    @AlirezaZojaji this might be a misunderstanding. The tx hash is the value calculated with only the input of the transaction and is calculated before it reaches the EVM since it is returned to the caller (the program outside making the transaction) so it can check the transaction state. The question is "would it be possible / interesting to bring that tx hash as a constant in the solidity language?" like you have the current tx.origin. A tx.hash for instance. Jul 8, 2020 at 15:10
  • 3
    The transaction hash does not depend on the mining process. The transaction (along with its hash) exists in the mempool before the block is mined.
    – Orestis P.
    Oct 7, 2021 at 16:10

Your Answer

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

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