# Read requests

In previous sections, it was explained how HotPocket nodes work in unison and how the DApp is called upon to act on the consensed information. This ensures that the entire HotPocket cluster moves forward in-sync with each other and each DApp acts upon the consensed information. Even though this is desirable for security, it has a time penalty resulting from having to carry out consensus verification among the entire cluster of nodes.

"Read requests" are a great way to communicate with a DApp on a single HotPocket node without the overhead of consensus. It constitutes a request/response cycle in which the DApp provides the data that the user requested. To facilitate this, upon receiving a read request from the user, HotPocket invokes the DApp in **read-only** mode. In this mode, the DApp has read-only access to the last-consensed [state](state) and extracts the required information out of it according to the request it received as a "user input". It can then send the extracted information to the user in the form of a "user output".