# Overview (https://docs-dmpho5eos-ton-core-docs.vercel.app/llms/foundations/messages/overview/content.md)



## Messages [#messages]

Messages are objects of the following structure:

```tlb
message$_
    {X:Type}
    info:CommonMsgInfo
    init:(Maybe (Either StateInit ^StateInit))
    body:(Either X ^X)
= Message X;
```

* `init` is an optional field of [`StateInit`](/llms/foundations/messages/deploy/content.md) type used to initialize the contract state, stored either in-place or in a ref of the cell with a message.
* `body` is the actual message content that can be stored either in-place or in a reference. Typically, it is the payload of the message that will be read by the receiver.
* `info` describes the type of the message, and fields specific to messages of this type:
  * [Internal messages](/llms/foundations/messages/internal/content.md) are messages from one contract to another.
  * [Incoming external](/llms/foundations/messages/external-in/content.md) messages are messages from the outside world to the contract.
  * [Outbound external](/llms/foundations/messages/external-out/content.md) messages are messages from the contract to the outside world. They can be interpreted as logs.

## Transactions [#transactions]

A transaction is a record that stores the state changes of a contract. A contract's state cannot be changed without a transaction. When a contract processes a message, a transaction may occur as the result of its processing.

* When an internal message is processed, a transaction is always created.
* When an incoming external message is processed, a transaction will be created only if the contract [accepts](/llms/foundations/messages/external-in/content.md) the message.
* When an outbound external message is processed, a transaction is never created, because outbound external messages can't change contract state.

However, a transaction may be created independently of message processing by

* tick-tock transactions,
* split-prepare transactions,
* split-install transactions,
* storage-tx transactions.

Each transaction has the following structure:

```tlb
    transaction$0111
    account_addr:bits256
    lt:uint64
    prev_trans_hash:bits256
    prev_trans_lt:uint64
    now:uint32
    outmsg_cnt:uint15
    orig_status:AccountStatus
    end_status:AccountStatus
    ^[
        in_msg:(Maybe ^(Message Any))
        out_msgs:(HashmapE 15 ^(Message Any))
    ]
    total_fees:CurrencyCollection
    state_update:^(HASH_UPDATE Account)
    description:^TransactionDescr
= Transaction;
```

Transactions implement the concept of `AccountChain` described in the [TON Blockchain whitepaper](/llms/foundations/whitepapers/tblkch/content.md). Each account state can be interpreted as a separate blockchain, so transactions follow a strict order defined by the `prev_trans_hash` field. Thanks to the TON consensus protocol, a transaction becomes final when the first masterchain block references it by storing the hash of the corresponding `ShardChain` state, which in turn stores the hash of the `AccountChain` state.

Because transactions form the `AccountChain`, each one carries a logical timestamp, `lt`, that strictly increases with every new transaction of the account. The `now` field stores the Unix time when the transaction was created.

The `state_update` field is a [Merkle update](/llms/foundations/serialization/merkle-update/content.md) that captures the difference between the previous and current state of the account. The [contract status](/llms/foundations/status/content.md) before and after the transaction is duplicated for convenience.

Other fields, such as `in_msg`, `out_msgs`, and `outmsg_cnt`, relate to the [messages](/llms/foundations/messages/overview/content.md) processed and emitted during the transaction. A trace may start from a transaction rather than a message, in which case `in_msg` is `Nothing`. However, a trace cannot continue without messages: if it contains `n` transactions it must contain at least `n-1` messages. Consequently, a trace can include at most one non-ordinary transaction, because messages can trigger only an [ordinary transaction](/llms/foundations/messages/ordinary-tx/content.md).

The `total_fees` field stores the total number of [fees](/llms/foundations/fees/content.md) paid by the transaction. These fees may eventually be paid in extra currencies, but that feature is not implemented yet.