In the Solidity tutorial and examples here, I don't see any signature checking. In particular, in the contracts provided there, they don't check whether the sender of a message is actually the person who claims to be. So, my question is:

Question: In contracts written in Solidity, do we usually check the signature (of the message sender)? if yes, when?


The Ethereum protocol is defined such that you can trust that the sender is really set to the owner of the account (in Solidity, that means you can trust msg.sender is already validated). Below are some sections of the yellow paper which define this protocol.

Specifically, a transaction includes several parameters (v, r, and s) that allow everyone to validate the signature.

transaction signature values

Transactions are only considered valid if the signature is valid. (see item 2)

transaction validity

Blocks that include invalid transactions will be rejected as invalid by protocol-respecting miners and peers. (see item 2)

block validity

Miners that attempt to include a transaction with an invalid signature anyway (violating the protocol) will waste their resources: future miners will not build on top of the invalid block, and the malicious miner will never get to spend their block reward.

  • It'd be better to quote the text, instead of using screenshots of the yellow paper since it's blurry and hard to read. – Miguel Mota Nov 27 '17 at 16:49

The address of the sender of a transaction populates msg.sender.

You can check if this address matches a particular address in your function definitions. You do this when you need to. I.E When your functionality requires a specific user to have called it.

You can abstract this 'checking' functionality into a modifier to keep your code DRY.

  • Thanks. I think if we just compare msg.sender with some address we have in mine, the problem would not be solved. I think we need to see if it has the private key related to msg.sender. Am I missing something? – user153465 Aug 16 '17 at 16:46
  • Yes. You can't sign a transaction without the private key. I.E. The function is only executed and msg.sender is only set if the transaction has been signed correctly. – Thomas Clowes Aug 16 '17 at 16:49
  • Right, that means the contract doesn't need to worry about it, and this verification is done by the (full) nodes and miner. Is that right? – user153465 Aug 16 '17 at 16:51
  • Yes. To all extents and purposes. – Thomas Clowes Aug 16 '17 at 16:52

Signatures are checked automatically by the EVM prior to a contract's execution. There's no need to double-check, nor is it possible. In fact, if msg.sender is another contract, it doesn't even make sense.

It is, however, possible to manually verify a signature with ecrecover(). This is useful for state channels, as an example.


The protocol checks for you. It's not a valid transaction unless signed by msg.sender. So, nicely, not a concern.

Many apps need to check for privileges (is this the admin?) so they can check the msg.sender against an access control list of some kind.

A little off topic, but related. tx.origin is a no-go in my opinion because the sender can spoofed in ways that are not possible with msg.sender.

Hope it helps.

  • Thanks for the answer. Which protocol do you mean by "The protocol checks for you"? – user153465 Aug 16 '17 at 16:42
  • Ethereum, miners, verifiers. It's just not a valid transaction unless it's signed by the msg.sender and everyone knows it. – Rob Hitchens Aug 16 '17 at 19:16

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.