# DAO Governance

If we talk about defination of DAO, or decentralized autonomous organization, then it's a type of entity structured from the ground up without a central authority. Coin holders have the power to vote on initiatives and decisions for the organization.

## How Proposals Get Discussed in HootChain?

HootChain is like a club where members (holders) can vote on important decisions. But with a global club, how do you make sure everyone's on the same page about what's being voted on? That's where **governance system synchronization** comes in!

### **The Role of Masternodes:**

Masternodes act as the network's custodians, holding a significant amount of HOOT and performing essential functions. In the context of governance system synchronization, they serve as reliable repositories of governance objects, which encompass proposals and related information.

#### **Synchronization Stages:**

The synchronization process occurs in two distinct stages:

1. **Initial Request (Object Sync):** New nodes joining the network initiate this stage by sending a `govsync` message to masternodes. This message, containing a hash of all zeros, acts as a request for the core governance objects themselves.
2. **Follow-Up Requests (Vote Sync):** Once the initial objects are received, the syncing node enters the vote sync stage. It sends specific `govsync` messages containing the hash of each governance object to request the corresponding votes cast by other participants.

### **Masternode Response:**

Upon receiving a `govsync` message, masternodes transmit relevant data back to the requesting node:

* **For Object Sync:**
  * A `ssc` message (Sync Status Count) for `govobj` objects, indicating the number of governance objects to be sent.
  * An `inv` message containing information about both `govobj` (governance objects) and `govobjvote` (governance object votes) objects.
* **For Vote Sync:**
  * A `ssc` message (Sync Status Count) for `govobjvote` objects, specifying the number of votes to be sent.
  * An `inv` message containing information about the specific `govobjvote` objects requested.

### **Requesting Objects and Votes:**

After receiving this information (counts and inventories), the syncing node can utilize `getdata` messages to request individual `govobj` and `govobjvote` objects from masternodes.

To prevent excessive network strain, a limitation exists on the frequency with which new nodes can request the initial object sync. Frequent requests will result in the node being banned.