# Consensus Algorithm

As previously noted, our Escrow node is a voting transaction confirmation node. Each Escrow node is randomly selected according to a determined transaction volume and receives transaction confirmation status from a randomly selected Rep node. During the 10-block generation, five Rep nodes, excluding the sending and receiving nodes from the seven selected nodes, vote on each transaction, Escrow nodes determine true or not-true of a transaction using a decision-making formula. The number of Rep nodes participating in the vote will change depending on the scale of Rep nodes joining in the future. If the sum of the transaction’'s true/not-true results are greater than or equal to 75% (the threshold value), the transaction's token is released. Figure 2 shows the flow diagram for true/not-true transactions.<br>

<figure><img src="/files/vkMdRLc4AcJFE6LhlIsF" alt=""><figcaption></figcaption></figure>

## **Escrow Accounts**

Escrow node escrow accounts help prevent the mistake of giving tokens to the wrong party. The Escrow node holds the tokens until the transactions in the escrow account are confirmed by selected multiple Rep nodes, and when the Escrow node confirms that the transaction is true, it releases the tokens to the recipient's wallet.

## **​​Escrow Account Determination Formula**

![](https://lh7-us.googleusercontent.com/NyfJRUfivzo69fKSUsoiFkzHBfyYalMOjfYW_aWXXwdCu-a3ICHqXDn_PotRQEEBNaMr_ZXk05aiWmNsBUy4BQajOX-A7rv9sM4qU2YNIaPypUIkZOkBqKCmF4UzRW9iZuiWhiY1X1cK8-7B3pIfWUlwLzLyHUGj)

θj is the bias coefficient of the decision condition when the NFT content has comments.

In the default setting example below, seven nodes were selected, five nodes responded True except for sender and receiver nodes, and one node responded Not-True. If the threshold is less than or equal to 75%, the transaction is considered a "True" transaction.

<table><thead><tr><th>User Type</th><th>Rep Node</th><th width="149">Reply Signal</th><th>Result</th><th>Custody</th></tr></thead><tbody><tr><td>NFT buyer</td><td>A</td><td>T</td><td>True</td><td>True</td></tr><tr><td>NFT seller</td><td>B</td><td>T</td><td>True</td><td>True</td></tr><tr><td>Other user</td><td>C</td><td>NT</td><td>True</td><td>True</td></tr><tr><td>Other service</td><td>D</td><td>NT</td><td>True</td><td>True</td></tr><tr><td>Other user</td><td>E</td><td>NT</td><td>True</td><td>True</td></tr><tr><td>Other service</td><td>F</td><td>T</td><td>Not true</td><td>Not true</td></tr><tr><td>Other user</td><td>G</td><td>NT</td><td>True</td><td>True</td></tr></tbody></table>

In the above example, the result is True both when the response signal is True (lines 1 and 2) and when it is not (lines 3,4, and 5).

The motivation for maintaining Xenea is it has the capability of PoD mining with a confirmation vote for each transaction. The Xenea algorithm randomly selects a number of nodes to identify the transaction nodes. If consensus is reached, all selected nodes will receive token rewards. Thus, all participating Rep nodes have the opportunity to receive rewards if they reply to the transaction confirmation within the required time frame.

<figure><img src="/files/kI1pQhqm6n5PPhMcNLJL" 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://docs.xenea.io/whitepaper/consensus-algorithm.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.