Everest is a community-curated registry of crypto projects, not just a discovery website. The repo README explicitly centers add / challenge / vote / delegation flows.
The core primitive is project identity plus challengeable curation. Projects are represented through ERC-1056 identities, while the registry’s legitimacy comes from whether members challenge and vote on misrepresentation.
The Graph’s launch post makes the subgraph layer especially important. Everest is meant to be queried and reused by other applications, so the open API is part of the mechanism rather than an implementation detail.
The contracts README exposes the governance/control surface more clearly than the homepage copy: Everest is a DAO where Ethereum accounts apply as members, whitelisted members can challenge misrepresentation, and majority vote can remove members.
The repository also contains an analytically important caveat: adding or challenging required real DAI deposits, and in v1 the contracts remained owned by an address controlled by The Graph team. That means the registry mixes community curation with transitional admin custody.
Everest is therefore a useful lower-bound comparison point between token-curated registries, challenge-based list governance, and softer publisher-led metadata registries.
Specific source signals worth retaining
The repo README is the best concise source for the core architecture: Ethereum + IPFS + The Graph + 3Box, ERC-1056 project identities, add/challenge/vote/delegate flows, and the explicit centralization warning around DAI permits and contract ownership.
The contracts README is the best source for the actual governance framing: member application, whitelisted challengers, majority-vote removal, and the idea that the code can be forked to curate other lists beyond crypto projects.
The Graph launch post is the best source for the intended reuse pattern: Everest as project identities and a subgraph-backed open API for job boards, events, blogs, and other apps.
Why this entry belongs in the corpus
It strengthens the registry cluster with a project-identity layer that sits between generic token lists and heavier challenge/arbitration systems.
It helps separate several surfaces that later products often blur together: publisher-controlled metadata, community challenge rights, delegated voting, deposit economics, and downstream query-layer adoption.
The durable insight is that ecosystem legibility often depends less on a neutral directory and more on who can challenge, who can vote, who controls deposits, and which query endpoint downstream apps actually treat as canonical.