title: do all NEAR blockchain transactions require a receiver account?
body: <p>reading through some <a href="https://docs.google.com/document/d/1VRef627Y-Md1qAdRn0RFUojPxOs5nQmHyHBFYewwbZQ/edit#" rel="nofollow noreferrer">documentation here</a> and saw that part of the definition of a transaction is that all actions are performed "on top of the receiver's account" and also that the receiver account is "the account towards which the transaction will be routed."</p>
  
  <p>also in the nearlib SDK, <a href="https://github.com/nearprotocol/nearlib/blob/master/src.ts/transaction.ts" rel="nofollow noreferrer">the transactions interface</a> includes a method called signTransaction that requires <code>receiverId</code> as a parameter</p>
  
  <pre class="lang-js prettyprint-override"><code>async function signTransaction(receiverId: string, nonce: number, actions: Action[], blockHash: Uint8Array, signer: Signer, accountId?: string, networkId?: string): Promise&lt;[Uint8Array, SignedTransaction]&gt; {
  </code></pre>
  
  <p>but looking over the list of transactions supported by nearcore I wonder why do some of these transaction require a receiver.</p>
  
  <blockquote>
    <p>why would any transactions require a "receiver" except for maybe <code>Transfer</code>, <code>AddKey</code>, <code>DeleteKey</code>, and <code>DeleteAccount</code>?</p>
  </blockquote>
  
  <p>amd I think of the idea of "receiver" too literally, as in "they receive the outcome or impact of the transaction"? and instead it's not the right way to think about it?</p>
  
  <p>or is receiverId optional in some cases but the interface just requires a value to avoid validation cruft?</p>
  
  <p>here's what I believe to be the <a href="https://github.com/nearprotocol/nearcore/blob/54b597cfc53de24aa7c9813eea87926ad9752aa1/core/primitives/src/transaction.rs#L37-L46" rel="nofollow noreferrer">full list of supported transactions</a></p>
  
  <pre class="lang-rust prettyprint-override"><code>pub enum Action {
      CreateAccount(CreateAccountAction),
      DeployContract(DeployContractAction),
      FunctionCall(FunctionCallAction),
      Transfer(TransferAction),
      Stake(StakeAction),
      AddKey(AddKeyAction),
      DeleteKey(DeleteKeyAction),
      DeleteAccount(DeleteAccountAction),
  }
  </code></pre>