Arcturus Docs
  • Note!
  • Bitcoin and Decentralized Structure
  • Introducing to Arcturus Chain
  • For End User
    • How to add Arcturus to Metamask
    • Obtaining tARC from the Faucet
    • Faucet API
    • How to Use Arcscan
  • For Nerds
    • Proof Of Stake
    • Arcturus Chain
      • Accounts
      • Messages and Transactions
      • Messages
      • Arcturus State Transition Function
      • Code Execution
      • Blockchain and Mining
      • Applications
        • Token Systems
        • Financial Derivatives and Stable-Value Currencies
        • Identity and Reputation Systems
        • Decentralized File Storage
        • Decentralized Autonomous Organizations
        • Further Applications
      • Fees
      • Computation And Turing-Completeness
      • Currency And Issuance
      • Mining Centralization
      • Scalability
      • Conclusion
    • Arcturus Pay
      • About
      • Technolog & Use Cases
      • Developer Instructions
        • arcpay_dev-1
        • arcpay_dev-2
        • arcpay_dev-3
  • Updates & News
Powered by GitBook
On this page
  1. For Nerds
  2. Arcturus Chain

Messages

PreviousMessages and TransactionsNextArcturus State Transition Function

Last updated 10 months ago

Contracts have the ability to send "messages" to other contracts. Messages are virtual objects that are never serialized and exist only in the Arcturus execution environment. A message contains:

  • The sender of the message (implicit).

  • The recipient of the message.

  • The amount of ARC to transfer alongside the message.

  • An optional data field.

  • A STARTGAS value.

Essentially, a message is like a transaction, except it is produced by a contract and not an external actor. A message is produced when a contract currently executing code executes the CALL opcode, which produces and executes a message. Like a transaction, a message leads to the recipient account running its code. Thus, contracts can have relationships with other contracts in the same way that external actors can.

Note that the gas allowance assigned by a transaction or contract applies to the total gas consumed by that transaction and all sub-executions. For example, if an external actor A sends a transaction to B with 1000 gas, and B consumes 600 gas before sending a message to C, and the internal execution of C consumes 300 gas before returning, then B can spend another 100 gas before running out of gas.