# Data Transfer

IOTA offers the ability to transfer Data for free. The Data transfer is fast, immutable, unforgeable, and secure and is one of the core features of IOTA. This capability opens up a wide array of use cases that most other cryptocurrencies cannot serve in a way that IOTA does.

In IOTA, clients like wallets or applications send and receive messages (data objects) through nodes. Nodes are the entry and exit points for these messages, and they communicate with each other and with the connected clients.

There are several types of messages implemented in IOTA. Some transfer value (the IOTA token or digital assets), while others transfer no value, but pure Data and other types can contain both. This enables the decentralized transport of Data and Value in a single message with the highest security grade and the total absence of fees. The nodes of the network take care of the secure distribution of all messages in the Tangle.

## Data Usage​

Many applications and use cases can profit from this combination of free, secure, and fast data and value transport, which is a demand in all major industries. Read more about IOTA Data use cases here.

## What is an IOTA message?​

A message is an object consisting of information that is broadcasted in the Tangle.

Every application that uses the protocol is free to issue these information objects to a node. The job of an Iota node is to verify and broadcast all these information objects through the network if they are valid and follow the standards of the protocol.

If a node decides that a message is valid, it will send it to its neighbors using the gossip protocol. Every neighbor that receives the message transfers it again to its neighbors and so on. Very quickly, every other node in the network sees the message and has the same information and the same knowledge of the "State" of the network at a given time.

A Message consists of basic information that defines the type and structure of the message, and it can also contain different Payloads. A Payload is an attachment that can include an IOTA transaction and many other kinds of data.

The IOTA protocol categorizes these information packages into different types and handles certain types differently than others. Therefore, every message sent to the network must contain a unique label as an identifier that describes exactly what this message is and what should be done with it. Only with this information "printed" on the 'label', a node will accept and process a message. This can be understood as similar to filling out a label before sending a package using your local postal service.

A more detailed description of this process on the protocol level can be found here.

## Sending a message in IOTA​

Messages are created by so-called clients. This can be an IOTA wallet or any other application that can generate IOTA messages. The client sends those messages to an IOTA node to process them.

To make sure that a message is valid and a node knows what to do with the message, the message label created by a client must provide several pieces of information for the node to be processed and enter the network.

Message ID

The message ID is created as a unique cryptographic hash out of the bytes contained in the message. It is created by the client (application) or wallet that issues the message.

Network ID

An identification in which IOTA network the message belongs (Mainnet / Testnet / private network) - Nodes will only accept messages that identify themself as part of the network the node belongs to.

Parents length and Parents ID

This is the amount and the identifier of the messages which are referenced by the new message. To build up the graph structure of the Tangle, every new message in the Tangle must reference 2 - 8 previous messages. The node selects those two messages and sends the IDs to the client, and the client must include this information into the message "label."

As messages in IOTA are not allowed to exceed a size of 32kb, the message must declare the size of its payload to the node... like you would need to report the weight of a package if you want to send it with a courier in advance.

A definition of which kind of payload is contained in the message. The Node needs to know this, as some payload types need to be handled differently than others.

Nonce

That is the nonce that lets this message fulfill the Proof-of-Work requirement. Proof of work is mainly done locally on the device that issues the message and is a form of spam protection. But it can also be done by the node if the node allows this. That is a very useful feature as it enables very low-powered devices to issue messages (like sensors, chips, etc.) Those sensors can send a message to a node that allows messages without already performed POW, and then the POW is done by the node (which is usually running on a more powerful device). This is one of the key features of the protocol and the reason why IOTA is so suitable for IoT and Data applications. So users who want to issue many data messages from a huge amount of extremely low-power devices only need to connect those devices to a node that allows them to do the POW for them (which will be, in most cases, their own node). As the POW requirement is extremely low, it is no problem to do this even for a large number of devices for a node.

A side note - in the upcoming 2.0 IOTA version, this POW requirement will become adaptive and is planned to be completely removed for times of normal network loads... Read more about IOTA 2.0 here: (link to content)

## Message structure​

This is the defined outer structure of every message in the IOTA protocol (the label of our package):

NameTypeDescription
NetworkIDuint64Network identifier. This field will signify whether this message was meant for mainnet, testnet, or a private net. It also tells what protocol rules apply to the message. It is the first 8 bytes of the BLAKE2b-256 hash of the concatenation of the network type and the protocol version string.
Parents' length uint8 The number of messages we directly approve. Can be any value between 1-8.
Parents ByteArray[32 * parents length]The Message IDs that are referenced.
Payload Lengthuint32 The length of the Payload. Since its type may be unknown to the node it must be declared in advance. 0 length means no payload will be attached.
An outline of a general payload
NameTypeDescription
Payload Typeuint32The type of the payload. It will instruct the node on how to parse the fields that follow.
Data FieldsANYA sequence of fields, where the structure depends on payload type.
Nonceuint64The nonce which lets this message fulfill the Proof-of-Work requirement.

All this information must be created by a client (wallet software or other programs that generate IOTA messages) to issue a message to a node and make sure the node knows what to do with this message.

### Message validation​

A message is considered valid if the following syntactic rules are met:

1. The message size must not exceed 32 KiB (32 * 1024 bytes).
2. Analyzing the Syntax structure of the message (parsing) does not leave any unknown bits - this means that all the message information is fully readable by the node... unreadable information could contain malicious code and is therefore denied.
3. If the payload type is known to the node.
4. If the Message PoW Hash indicates that the minimum requirements of POW requested by the network or the node have been fulfilled.
5. Number of parent messages must be between 1-8.

The message will only be accepted for processing if these parameters are met and readable by the node.

A message may contain a payload. Three payload types are currently defined in the mainnet, but developers can create their custom payloads and attach them to messages as long as they fit the general requirements. This means an IOTA message can contain many types of information, and the IOTA Token as transaction payload is just one of many. Below is a table of the currently specified core payloads with a link to their specifications.