Evrylife Foundation

Governance

How the community decides

On most platforms a handful of people decide what you may say, what gets built and where the money goes. On Evrylife those decisions are made by the members, through one public process, and there is no central authority that can overrule it.

The path every change takes

Two ways in. No shortcuts.

A build task is always the result of a community decision, never the start of one.

Report a problem

Something is broken. Members review the report, and only when the community confirms it does it become a task to build.

Propose an improvement (EAIP)

A design change, a new capability, or a change to a governed setting. It is triaged, then voted on. If it passes, it becomes a task to build.

  1. A member speaks up

    They report a problem or propose an improvement.

  2. Random members review

    Reviewers are assigned by chance. You cannot pick yours.

  3. Approved work is ordered

    Only an approved outcome becomes a build task.

  4. It gets built

    The change is built to match what was approved.

  5. Members verify it

    The result is checked, and the public rulebook is updated to record it.

zkr-POGO, in plain words

zkr-POGO is Evrylife's consensus system. The name stands for Zero Knowledge Randomized Proof of Group Opinion. Three ideas make it fair:

  • Random assignment. Eligible reviewers are selected at random for each moderation case, build or proposal. Nobody chooses their judge, and nobody chooses their case.
  • Hidden identities. The names of the reviewer and of the person who raised the matter are stripped from the task, so decisions are about the content and not the person. Full cryptographic zero-knowledge (via Semaphore) is planned and not yet in place.
  • Skin in the game. Stake and reputation bound who can review. Careless or abusive reviewing costs standing.

What no vote can change

  • The total supply24B EVRY, hard-capped and immutable.
  • The anti-greed policyZero founder, investor or team allocation.
  • The proposal process itselfChanging it requires a constitutional amendment.
The Guardian. An automated check blocks any code change that violates the Constitution: kill-switches, back doors, anti-greed breaches or re-centralization.

The details: improvement proposals (EAIPs)

An EAIP (Evrylife Application Improvement Proposal) is the formal way to change the protocol after bootstrap. Nothing is added to or changed in the public rulebook without one.

What a proposal can cover

  • Governed settings (thresholds, rates, limits)
  • Module additions or modifications
  • Feature requests
  • Treasury allocation changes
  • Smart contract upgrades via the DAO proxy (the token contract itself is immutable)
  • Structural changes to the topic map
  • Adding or removing cause pillars
  • Knowledgebase document updates
  • Adding or retiring integrations

What a proposal must include

  1. Minimum stake: the proposer must hold at least min_proposal_stake EVRY.
  2. Description: a clear statement of what changes and why.
  3. Impact assessment: which registries, modules, features and settings are affected.
  4. Feasibility: assessed by development-level reviewers.
  5. Linked modules: every proposal references the modules it affects.

How it is reviewed

  1. The proposer submits it in the app.
  2. zkr-POGO assigns reviewers from the holders of the proposal-reviewer badge.
  3. Reviewers assess feasibility and alignment with the protocol's principles.
  4. The proposal goes to a community vote.
  5. The vote needs quorum_percentage participation.
  6. Approval needs consensus_threshold agreement.
  7. execution_delay_days pass before it is implemented.
  8. It is built and verified through zkr-POGO development tasks.

The governed settings

Even the voting rules are settings the community controls, within fixed ranges.

SettingDefaultRangePurpose
consensus_threshold66.6750–95Required agreement for passage
quorum_percentage105–30Minimum participation
execution_delay_days21–14Delay before execution
min_proposal_stake100001000–100000Minimum stake to propose
delegation_power_limit5000010000–500000Maximum delegated voting power
Join the waitlist → See governance so far Constitution, Article IV
Where this comes from: every figure on this page is generated at build time from the Evrylife protocol’s public control plane — ECP v7.7.294, 33 registries, 1,830 rows — read from a committed snapshot of the protocol's control-plane export. evrylife.org is an independent Foundation site that relays public protocol data: it is not a DAO-governed artifact and holds no protocol state of its own. Explanatory text is quoted from the public knowledgebase.