---
# System prepended metadata

title: tx.origin V.S msg.sender
tags: [solidity]

---

###### tags: `solidity`

# tx.origin V.S msg.sender

msg.sender的來源可以是合約
tx.origin不能是合約 是來自最初發送交易的帳號 其他合約無法傳入使用
假設要設定合約constructor的owner 如果不想給其他合約使用 
可以用tx.origin 如果用msg.sender 其他合約也能創造

交互上或合約使用 msg.sender
如果確定私人使用 tx.origin

簡易流程:
E.X : A->B->C->MineContract
tx.origin = A
sg.sender = C

------------------------
原文

With msg.sender the owner can be a contract.

With tx.origin the owner can never be a contract.

In a simple call chain A->B->C->D, inside D msg.sender will be C, and tx.origin will be A.

msg.sender is preferred for the flexibility it provides. Furthermore, for Serenity, even though it's a while out, Vitalik recommends avoiding tx.origin: How do I make my DAPP "Serenity-Proof?"

Carefully consider if you really ever need to use tx.origin. Remember, you may not be the only user of your contract. Other people may want to use your contract and want to interact with it via a contract they've been written.

If the origin is really desired in D, then each of the functions in the contracts B, C, D could take an extra parameter to propagate the origin: A would pass its address (this) to B, B would pass the value to C, and C would pass it to D.

EDIT: To emphasize the comment by @WBT below, a contract that uses a passed in value for the origin, must be very careful in how it uses the origin: anyone can pass in a value that is not the real

https://ethereum.stackexchange.com/questions/1891/whats-the-difference-between-msg-sender-and-tx-origin