# Evrylife Consensus Protocol - zkrPOGO (zero knowldge randomized proof of group opinion)

## Evrylife App Moderation, Development, and Automation

Moderation automation is important to help reduce the amount of mod tasks that are required to be done by users. Things like spam in community discussions and interaction fields, Messaging limits to non connected users, and other actions which may violate community guidelines that can be reduced from simple app safeguards. Evrylife is being designed to use open source moderation automation that is community governed.

Moderation automation can occur in various sections of the Evrylife application. On an app wide level for all users for things like ‘flagging limits’, ‘interaction limits’, ‘tagging limits’ and things of that nature. Moderation can also take place at a ‘Channel’ level where communities can enable and govern their own moderation automation modules for their community.

## Evrylife App zkrPOGO tasks (performed by humans and AI service agents)

Mod tasks allow for Evrylife users to govern, moderate, and improve the Evrylife applications code, the directory database, and the content users add to it.

There are several different types of mod tasks that help to make the Evrylife application operate. Here are some examples of mod tasks in the Evrylife application:

* Tag audit mod tasks - are given to moderators to help audit content to ensure that it is tagged and categorized correctly. These mod tasks help to make content more discoverable and displayed in the correct categories. 
* Flagged content mod tasks - are given to moderators to review and provide an opinion on content that has been flagged by other users. These mod tasks help to keep the content made visible on Evrylife in line with the community guidelines. This can include content or the interactions that occur on a piece of content. Flagged content mod tasks is a way to conduct **decentralized content moderation for a social media application** such as Evrylife. It is a type of '**proof of group consensus'** that can be utilized to fight spam and content that violates a set of community guidelines.
* Database improvements mod tasks - are given to moderators where they can provide suggestions for editing existing topics or they can suggest adding new topics, locations, and breakdowns. These mod tasks help to improve the interoperable web 3 database. 
* Content tag requests mod tasks - are where users can choose to have other users tag their content for them. Content verifications - Mod tasks which help to validate things such as causes. 
* Developer mod tasks - are where developers are incentivized to participate in Evrylife app improvement proposals (EAIPs) to help create new features voted by the community to be created.

## Zero Knowledge Randomized Proof of Group Opinion (zkrPOGO)

Having mod tasks performed by the community and not a private team is a way to make content moderation more fair. Zero knowledge randomized proof of group opinion (zkrPOGO) allows for a community to participate in optional mod tasks to determine if content flagged is in violation of the [community guidelines](https://docs.evrylife.org/evrylife-foundation-wiki-docs/evrylife-application/evrylife-community-guidelines). 

zkrPOGO mod tasks are performed at random and with volume by users who request to do them. When a decision has been reached by enough users and a consensus has been reached then the decision will go into effect. 

#### What zkrPOGO Actually Does (Current Implementation)

zkrPOGO = **Zero-Knowledge Random Proof of Group Opinion** It's the mechanism that selects moderators/developers/ai service agents randomly and fairly, using cryptography to ensure privacy and prevent biased behaviour and gaming.

* **On-chain components** (executed on the blockchain):
  * **Random selection** — Semaphore zero-knowledge proofs run on-chain to pick eligible users (stake ≥100 EVRY, score ≥50/75, preferences match) without revealing who was considered or excluded.
  * **Eligibility check** — Stake verification and nullifier checks happen on-chain (prevents double-voting or Sybil attacks).
  * **Consensus threshold execution** — When enough moderators reach ≥70% agreement, the final decision (approve/reject task) is executed on-chain (e.g., update content flag, merge dev branch, release reward).
  * **Reward claim** — Prorated treasury claim is triggered on-chain after consensus.
* **Off-chain / Ceramic components** (not on-chain):
  * **Task push** — The actual notification and "My Active Tasks" UI update happens via Ceramic streams + libp2p (real-time P2P sync). This is fast and private but not recorded on Ethereum/Solana/etc.
  * **Moderation/review content** — The yes/no vote, tag audit, content review text, or dev branch work itself lives in Ceramic (user-signed TileDocuments). Only the final consensus outcome is pushed on-chain.
  * **Preferences** — User task-type preferences (which pillars they want) are stored in Ceramic profile.
  * **Sandbox points accrual** — Tracked in Ceramic epoch\_points stream (pre-treasury bootstrap).

#### Summary – On-Chain vs Off-Chain

| Part of zkrPOGO                | On-Chain? | Where It Lives              | Why                    |
| ------------------------------ | --------- | --------------------------- | ---------------------- |
| Random selection of moderators | Yes       | Semaphore proofs (EVM)      | Privacy & fairness     |
| Eligibility (stake/score)      | Yes       | Smart contract checks       | Sybil resistance       |
| Final consensus execution      | Yes       | Smart contract (after ≥70%) | Immutable outcome      |
| Reward claim                   | Yes       | Treasury contract call      | Trustless distribution |
| Task push to user dashboard    | No        | Ceramic + libp2p            | Speed & privacy        |
| Actual review/vote content     | No        | Ceramic streams             | Low cost, user-owned   |
| User preferences               | No        | Ceramic profile             | User control           |
| Sandbox points (pre-airdrop)   | No        | Ceramic epoch\_points       | Transitional bootstrap |

A community score that is in good standing is required to perform zkrPOGO mod/dev tasks.

{% content-ref url="evrylife-community-guidelines" %}
[evrylife-community-guidelines](https://evrylife-web-3-explorer.gitbook.io/evrylife-foundation-wiki-docs/evrylife-application/evrylife-community-guidelines)
{% endcontent-ref %}

## Evrylife App Mod Score and Community Score

A mod score helps to ensure that users are providing quality feedback. A community score helps to ensure users are adding content, categorizing their content, and upholding the community guidelines with the actions they take on the platform. The formulas that make up the mod score and community score are community governed variables.

If a user does not have a good community standing then they may have certain actions of their account restricted. They may not be able to flag content, or perform mod tasks, additionally their wallet may get slashed which can in turn cover the rewards for those who reported and performed the mod tasks involved in the contents review process.

Users who have a mod score and community score in good standing can perform mod tasks and can report content using the flagging system.

Users can choose specific topics, locations, flag types etc to receive more mod tasks related to their preferences. A higher community score and more specialized flag requests may provide a higher reward rate.

### zkrPOGO, Snapshot, EAIP's

Full governance and control over the Evrylife application will occur through zkrPOGO (zero knowledge randomized proof of group opinion) consensus protocol. 

The Evrylife application is a dynamic entity that will continue to change and evolve over time. The community can vote to decide to improve and modify the application through EAIP's (evrylife app improvement proposals), along with smaller tasks and features done through mod tasks and dev tasks through zkrPOGO. 

Moderation tasks help keep the platform clean from content that violates the community guidelines, and dev tasks help to keep the platform evolving with any reported issues, upgrades, and changes that aim to improve the platform.

### Evrylife App Improvement Proposals (EAIPs) 

Big changes or changes in community governed variables require a EAIP (evrylife app improvement proposal). These are for things that alter the tokenomics, or request a large feature change to the applications, or including new infrastructure partners. These larger requests still use zkrPOGO to get passed through as an EAIP, at which point they will also use Snapshot (snapshot.org) to reach consensus. Depending on the type of request it may be required to go back through zkrPOGO for development and verification to be included/integrated.

## Evrylife App Governance

The Evrylife application is a dynamic entity that changes and evolves over time. The community has the power to improve and modify the application. You can learn more about Evrylife application smart contract and code governance here:

{% content-ref url="../evrylife-utility-token/evrylife-app-governance" %}
[evrylife-app-governance](https://evrylife-web-3-explorer.gitbook.io/evrylife-foundation-wiki-docs/evrylife-utility-token/evrylife-app-governance)
{% endcontent-ref %}

{% content-ref url="../docs-and-resources/subscribe-to-project-updates" %}
[subscribe-to-project-updates](https://evrylife-web-3-explorer.gitbook.io/evrylife-foundation-wiki-docs/docs-and-resources/subscribe-to-project-updates)
{% endcontent-ref %}