# The role of the Coordinator

The Coordinator is Cubbit's centralized intelligence that is in charge of:

• Ensuring the security of transactions.
• Facilitating communications between agents.
• Optimizing the payload distribution across the network.
• Keeping track of file locations and uptime via metadata.
• Triggering recovery procedures for files in the swarm.

The Coordinator is cryptographically blind — it only knows the files' location and their functional metadata. All payloads are stored on the distributed storage nodes, ensuring high performance and resilience through geo-distribution.

The Cubbit Coordinator has a key role in data distribution, peer selection, and recovery procedures.

## The role of the Coordinator in file distribution and peer selection​

Every file stored on Cubbit is encrypted with AES-256, split into chunks, multiplied into $n + k$ shards (using an algorithm called Reed-Solomon), and geo-distributed on the peer-to-peer network of nodes. The original file can be recovered from any subset of n shards out of the $n + k$.

After the Reed-Solomon redundancy procedure, the Coordinator determines which agents are most suitable for hosting the encrypted shards of files. Each of the $n + k$ shards is stored on a different agent.

To do so, the Coordinator runs machine learning algorithms to nullify the probability of losing files and grant a steady network performance. The Coordinator spreads the chunks as far as possible from each other while minimizing network latency and other factors (bandwidth usage, storage optimization, etc.)

If you want to dive deeper into how the Reed-Solomon algorithm works, check out its section.

## How the Coordinator triggers the recovery procedure​

From the $n + k$ shards created by the redundancy protocol, you only need $n$ shards to download a file from the Swarm.

To ensure the highest standards of durability and availability, the Coordinator monitors the uptime status of each Cubbit Cell, triggering a recovery procedure when the total number of online shards hits a certain threshold — namely, $n + \frac{k}{2}$.

When the recovery procedure is triggered, the Coordinator alerts the remaining online storage nodes that host that file to contact a set of newly available nodes to fully restore the number of online shards to the maximum level.

If you want to dive deeper into how the file recovery procedure works, check out here.