# Protocol

### Protocol Overview

The **Chroom protocol** is a decentralized Real Time Communication Network operating an algorithmic prosumer marketplace for real-time data, powered by a blockchain and a native protocol token

* **Clients** – representing the demand side – spend tokens to acquire **Chroom** data to power meetings, audio spaces, and other applications requiring real-time data.
* **Media Nodes** – representing the supply side – earn tokens by enabling low-latency real-time data to provision the Clients.

The **Chroom Network** utilizes **Proof of Resource** to ensure fair compensation for Media Nodes and enforce performance standards by tracking and rewarding nodes based on on-chain Quality of Service data, incentivizing high up-time and optimal service quality from node operators.

The network functions as a **multisided algorithmic marketplace**:

* **Supply:** Media Nodes providing network resources (bandwidth, compute).
* **Demand:** Consumer and industrial applications built on the **Chroom Network**.
*

### Chroom Protocol Sketch

<table data-full-width="false"><thead><tr><th>Network</th><th>Media Node</th><th data-hidden></th></tr></thead><tbody><tr><td><p></p><ol><li><p>At request by registry (Smart Con- tracts):                                                          (a) The Rewards Contract queries the Proof of resource Contract for node data</p><p>(b) Rewards for each Media Node are calculated</p><p>(c) The Rewards Contract requests token release from the Reserve Contract</p><p>(d) Tokens are transferred to each Media Node’s pool Contract</p><p>(e) The Pool Contract distributes rewards per its rules</p></li></ol><p></p><p></p></td><td><p></p><ol><li>Listen for requests from Orches- trator</li><li>Process RTC workloads</li><li>Perform QoS Tests on request from Registry Nodes</li></ol><p>at each epoch t: </p><ol><li>For each Client C, Report RTC Usage</li><li>Claim Rewards Earned for giving RTC Usage</li></ol></td><td></td></tr></tbody></table>

<table data-full-width="false"><thead><tr><th>Network</th><th>Orchestrator</th><th data-hidden></th></tr></thead><tbody><tr><td><p></p><p>at any time: at any time:</p><ol><li>Perform QoS Tests on Media Nodes and collect analytics</li><li>Request for Media Nodes from Registry:</li><li>Listen for Media Nodes entry re- quests to the network (a) query Media Nodes from reg- istry based on</li><li>Gossip New Media node entries to the network input parameters</li><li>Verify Media Nodes are Alive 2. Allocate and Balance RTC Work- load on Media Nodes</li><li>Serve latest Media Node entries and metadata to clients</li></ol></td><td><p></p><ol><li>Listen for requests from Orches- trator</li><li>Process RTC workloads</li><li>Perform QoS Tests on request from Registry Nodes</li></ol><p>at each epoch t: </p><ol><li>For each Client C, Report RTC Usage</li><li>Claim Rewards Earned for giving RTC Usage</li></ol></td><td></td></tr></tbody></table>

### Protocol Diagram

<figure><img src="?path=%2Ffiles%2FeZbwLNOA6AeLMhLZkuYp" alt=""><figcaption></figcaption></figure>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://chroom1.gitbook.io/chroom/general-project-information/images-and-media.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.