# 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.

Clients, which can be wallets or applications, send and receive messages (data objects) through nodes in IOTA. Nodes are the entry and exit points for these messages, and those nodes communicate with each other and with the connected clients.

There are several types of messages implemented in IOTA. Some messages transfer value (the IOTA token or digital assets), while others transfer only pure data, and some message types can even contain both value and data. This flexible message structure enables the decentralized transport of data and value in a single message with the highest security grade and the total absence of fees. The network nodes take care of the secure distribution of all those 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 sees demand in many major industries. Read more about IOTA Data use cases.

## What is an IOTA message?​

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

Every application that uses the protocol can issue these information objects to a node. The job of an Iota node is to verify incoming messages and broadcast them through the network if they are considered valid and follow the standard specifications of the protocol.

If a node decides that a message is valid, it will send it to its direct 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 what this message is and what should be done with it. Only if this information is stated correctly, a node will accept and process a message. A more detailed description of this process on protocol level can be found in TIP-0006 (Tangle Message).

## Sending a message in IOTA​

So-called clients create messages. Those clients can be an IOTA wallet or any other application generating IOTA messages. The client sends those messages to an IOTA node to process them.

To ensure 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 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 themselves as part of the network the node belongs to.

Parents length and Parents ID

This is the amount and the identifier of the messages 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." Therefore nodes make sure the data structure of the Tangle evolves as specified in the protocol.

Because 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 type of payload is part of the message. The node needs to know this, as some payload types need to processed 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 if the node allows it, PoW can be done by the node instead of the client. This is a handy feature as it enables very low-powered devices to issue messages (like sensors, chips, etc.) without doing the PoW in the local device. If connected to a node that allows remote PoW, those low-power devices can send messages, and the node (which is usually running on a more powerful device) does the PoW for them. This is one of the reasons why IOTA is so suitable for IoT and data applications. Users planning 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 in IOTA, in general, is extremely low, it is no problem to do this even for a large number of devices by 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.

## Message structure​

This is the defined syntactical 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.