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?


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)
  • sha3(...) returns (bytes32): compute the Ethereum-SHA3 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
  • .balance: balance of the address in Wei
  • .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.

| improve this answer | |
  • 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. – Tjaden Hess Apr 5 '16 at 17:34
  • 4
    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 '16 at 11:46
  • 20
    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. – Guenole de Cadoudal Feb 20 '17 at 6:00
  • @GuenoledeCadoudal Sounds like a good question to ask. – eth Aug 20 '17 at 18:29
  • @GuenoledeCadoudal because when EVM is running the transaction, its data is not completely made, and so its hah cannot be determined. – Alireza Zojaji Jul 7 at 13:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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