> For the complete documentation index, see [llms.txt](https://data-programs.gitbook.io/reputation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://data-programs.gitbook.io/reputation/overview/future-design.md).

# Future design

#### Reputation Tokens

In the future, Reputation DAO will have its native tokens called *Reputation Tokens*.

When a *Validator* contributes SP QoS metrics to the *Reputation Database,* it earns *Reputation Tokens* which they can stake to gain voting power in the DAO. Teams that run *Validators* can also spend *Reputation Tokens* to create their own *Reputation Service*.

The infrastructure of the *Reputation Database* will be run by a team that the DAO collectively agrees to hire. This team will join the DAO if not already and will be paid in *Reputation Tokens* for their contribution. This team can be internal or external to PL. The *Reputation Database* will have a throttling limit on the frequency and / or payload size to protect from a single *Validator* overwhelming or flooding the database.

Sometimes the same team that runs a *Validator* also runs a *Reputation Service*. The team has earned tokens from its validator, and can spend them for the reputation service to consume from the DAO database. So they would not need to purchase extra tokens. For instance, Starboard will earn Reputation Tokens for its contribution to the Reputation Database, and they can spend these tokens to gain access to other Validators' data in the database to build their own Reputation Service.

On the other hand, if a *Reputation Service* wants to consume from the *Reputation Database* but does not have data to offer in return (e.g. not currently collecting SP metrics that they are free to share), then they can either buy *Reputation Tokens* to spend, or opt to run an instance of the open-source Retrieval Bot to earn tokens. 

#### High quality data 

Data DAO members have the responsibility to maintain the *Reputation Database* and keep SP reputation metrics as accurate as possible. High quality data makes the DAO token more valuable and the DAO financially sustainable. In the event that a Validator’s collected metrics vastly differs from other *Validators’* metrics around the same SPs, DAO members are expected to investigate and resolve the issue via a claim / voting mechanism.

Though not in place in v1, in the future *Validators* will sign each payload they contribute to the *Reputation Database*. This increases accountability of the reputation data collected to incentivize more accurate measurements and incentivize against abuse such as slandering, bullying, and collusion.

#### Membership

Membership will be invite-only at first, and as the DAO matures it has the opportunity to become permissionless. Alternatively, the DAO could leverage a lightweight KYC process or SBT to issue Auth Tokens to members that are allowed to contribute to the DAO database.

##