Architecture

Bootstrap Integrations

Every external protocol the app depends on was chosen against the same criteria: the Constitution requires durable protocol primitives, never company products; decentralized control; and no single point of failure. Each integration below names the constitutional article it satisfies and the ECP module that governs it.

Governing principle (Constitution, Article III§ 1): build on durable protocol primitives (IPFS, libp2p, EVM, Arweave) — never company products that pivot. The database engine stays swappable behind dataService.

10 integrations at bootstrap

Expand each card to see the constitutional basis and the reason for selection.

OrbitDB on IPFS + libp2p

ECP: All modules  |  Status: Integrated — bootstrap builds

The mutable data layer. Every ECP domain maps to an OrbitDB store (document or event-log). Member writes are signed by the wallet’s did:key and replicate peer-to-peer.

Constitutional basis

Art. III§ 1: durable protocol primitives, never company products. Art. III§ 4: durability without a single point of failure. Art. I§ 3: decentralization of control — no single entity controls the data.

Why this integration

OrbitDB is an open-source, peer-to-peer database built on IPFS and libp2p — both IETF-track protocol primitives. It has no company dependency, no central server, and no API key. The dataService abstraction keeps the database engine swappable.

IPFS (InterPlanetary File System)

ECP: E004 Decentralized storage module  |  Status: Integrated — bootstrap builds

Content-addressed storage. Every piece of data is identified by a cryptographic hash of its content, making it tamper-evident and location-independent.

Constitutional basis

Art. III§ 1: durable protocol primitive (IETF-track, open standard). Art. III§ 4: content-addressed and pinned/replicated across many independent providers.

Why this integration

IPFS is an open protocol, not a company product. Content addressing means data integrity is mathematically guaranteed. Supported by a large independent ecosystem of implementations and pinning services.

Filecoin

ECP: E004 Decentralized storage module  |  Status: Integrated — bootstrap builds

Long-term persistence. Cryptographic proof-of-storage ensures pinned data survives even if individual operators leave the network.

Constitutional basis

Art. III§ 4: durability without a single point of failure. Art. III§ 3: privacy-matched storage — public data on provably durable storage.

Why this integration

Filecoin is a decentralized storage network with cryptographic proof that data is being stored. No single company controls it. Storage deals are verifiable on-chain. Complements IPFS by adding economic incentives for long-term retention.

Arweave

ECP: E004 Decentralized storage module  |  Status: Integrated — bootstrap builds

Permanent, immutable storage. Used for public data that must never be altered: approved releases, the ECP’s version history, and the protocol’s code archive.

Constitutional basis

Art. III§ 1: durable protocol primitive. Art. V§ 2: each approved release is an immutable IPFS/Arweave artifact. Art. III§ 3: permanent-public storage for public data and code only.

Why this integration

Arweave’s pay-once-store-forever model means data persists without recurring fees or company survival. It is a permissionless protocol, not a service. Used only for public, immutable data — never for private or deletable content (Constitution, Art. III§ 3).

Storacha

ECP: E004 Decentralized storage module  |  Status: Integrated — bootstrap builds

Fast pinning and hot-cache layer. Provides low-latency access to recently uploaded content while it propagates to longer-term storage.

Constitutional basis

Art. III§ 4: durability without a single point of failure — another independent provider in the replication set. Art. II: data ownership — member data stays on open protocols.

Why this integration

Storacha (formerly web3.storage) provides IPFS pinning with a decentralized architecture. It stores data on Filecoin and makes it available over IPFS, bridging hot and cold storage. The dataService abstraction means it can be replaced without protocol changes.

Lit Protocol

ECP: E011 Zero knowledge module  |  Status: Integrated — bootstrap builds

Decentralized encryption and access control. Private content is encrypted client-side before storage, and access conditions are enforced by a distributed key network — not a server.

Constitutional basis

Art. II: privacy by right — private data is Lit-encrypted. Art. I§ 3: decentralization of control — no single entity controls encryption keys. Art. I§ 5: self-custody — no central party can seize or lock members out.

Why this integration

Lit Protocol distributes key management across a network of nodes using threshold cryptography. No single node holds a complete key. Access conditions are programmable and on-chain, meaning the protocol — not a company — enforces who can decrypt what.

Semaphore

ECP: E011 Zero knowledge module  |  Status: Deferred — identity stripping uses simpler methods during bootstrap; cryptographic ZK is planned for post-handoff

Zero-knowledge group membership proofs. A member can prove they belong to a group (e.g. eligible reviewers) without revealing which member they are.

Constitutional basis

Art. II: privacy by right — review is identity-stripped and anonymized. Art. IV: zkr-POGO consensus — identities are stripped from the review.

Why this integration

Semaphore is an open-source, audited zero-knowledge protocol from the Ethereum PSE (Privacy & Scaling Explorations) group. It produces proofs that are verifiable on-chain without revealing the prover’s identity. No company dependency; the circuits are open and self-hostable.

OrbitDB / libp2p (ECIES)

ECP: E017 Messaging module  |  Status: Integrated — bootstrap builds

End-to-end encrypted messaging. Messages are encrypted with keys derived from the member’s wallet. No plaintext mode exists.

Constitutional basis

Art. II: privacy by right. Art. I§ 5: self-custody — encryption keys are wallet-derived, so only the member controls them.

Why this integration

ECIES (Elliptic Curve Integrated Encryption Scheme) runs over libp2p’s existing transport. No separate messaging service or company API. Keys derive from the same wallet the member already holds, so there is no additional custody risk.

Hyperlane

ECP: E001 Token contract module, SC005 HyperlaneISM, SC006 WarpRouteEVRY  |  Status: Smart contracts deployed (Sepolia)

Cross-chain message passing and token bridging. Allows EVRY to move between chains without a centralized bridge operator.

Constitutional basis

Art. I§ 3: decentralization of control — no single entity controls the bridge. Art. III§ 1: durable protocol primitive — permissionless, modular interoperability.

Why this integration

Hyperlane is a permissionless interoperability protocol. The Interchain Security Module (ISM) is configured by the protocol, not a company. Validators are independent. The Warp Route is an audited, non-custodial bridge — no trusted intermediary holds funds.

ENS (Ethereum Name Service)

ECP: E005 Profile module  |  Status: Integrated — bootstrap builds

Name resolution and the protocol’s governed deployment address. evrylife.eth is the community’s address; its contenthash points to the live release.

Constitutional basis

Art. V§ 2: evrylife.eth is the community’s address; the ENS contenthash advances only by a passing vote. Art. I§ 3: decentralization — ENS is an on-chain protocol, not a company’s domain registrar.

Why this integration

ENS is a decentralized naming protocol on Ethereum. The name evrylife.eth is controlled by the DAO multisig, not a registrar that can be pressured to seize it. Resolution is on-chain and censorship-resistant.

Constitutional criteria checklist

Every integration must pass all applicable criteria before inclusion:

CriterionSourceWhat it means
Protocol primitive, not a company productArt. III§ 1The integration is an open protocol or standard, not a proprietary service that can pivot, paywall, or shut down.
Decentralized controlArt. I§ 3No single entity controls the integration’s network, keys, or governance.
No single point of failureArt. III§ 4The integration replicates across independent operators; no node’s disk is the source of truth.
Self-custody compatibleArt. I§ 5Members hold their own keys; the integration does not require handing custody to a third party.
Privacy-matchedArt. III§ 3Private data is encrypted and deletable; permanent storage is used only for public data and code.
SwappableArt. III§ 1The dataService abstraction or equivalent interface means the integration can be replaced without a protocol rewrite.
No centralized loginArt. III§ 2The integration does not require an email-account service or centralized authentication.
Governed by the ECPArt. IVThe integration is registered in the ECP; adding or retiring it requires zkr-POGO consensus (EAIP after bootstrap).

Adding or retiring an integration

After bootstrap, any change to the integration stack — adding, replacing, or retiring a protocol — requires a member-filed EAIP (Evrylife Amendment and Improvement Proposal), zkr-POGO community consensus, and an update to the ECP registries before the change can ship. The same constitutional criteria above apply to any proposed addition.

Source: KB009 (Architecture Reference), KB039 (Constitution, Articles I, II, III, V) in the Evrylife Control Plane knowledgebase — DAO-governed documents, amendable only through zkr-POGO consensus. Integration descriptions are derived from the architecture reference and verified against the Constitution’s requirements.
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.338, 33 registries, 1,867 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.