protocol overview

This document describes the Aevia Protocol at the overview level. It defines the thesis, the layered architecture, and the set of normative RFCs that together constitute the specification. Clients and provider nodes intending to be conformant MUST implement the RFCs listed in §5 as applicable to their role.

The keywords MUST, SHOULD, and MAY are to be interpreted as described in RFC 2119.

The protocol thesis is: persistence does not imply distribution. The protocol separates two layers historically collapsed in commercial platforms: (i) the permanence of the bytes (persistence), and (ii) the editorial decision to recommend the bytes to an audience (distribution). This separation is architectural and irreversible at the protocol level.

The protocol is organized in six layers. A conformant implementation MUST honor the order of responsibilities below:

1. addressing (RFC-2) — all content is referenced by CID. Opaque URLs do not constitute canonical reference.
2. identity (RFC-3) — all authorship is proven by an EIP-712 signature over the canonical hash of the manifest.
3. persistence — Content Registry on Base L2 anchors manifests; provider nodes replicate the referenced bytes and prove replication at regular challenge-response intervals.
4. network — libp2p + Kademlia DHT for discovery; Circuit Relay v2 for NAT-bound peers; WebTransport for browser viewers.
5. distribution (RFC-6) — Risk Score governs feed, ranking, and subsidy. The distribution decision is always secondary to persistence.
6. governance (RFC-7) — Ecumenical Council of 12 seats holds veto authority over parameters. Deliberations are anchored on the Trust Ledger.

The protocol preserves the following invariants. Conformant implementations MUST:

• CID immutability — no legitimate protocol flow alters the bytes associated with a CID. Every content revision produces a new manifest with new CIDs.
• append-only Registry — registered manifests are not deletable. Revisions layer, they do not overwrite.
• persistence/distribution separation — no editorial decision (Risk Score, feed, subsidy) alters byte availability. A CID with high R(c) remains retrievable via the DHT; it merely loses subsidy and ranking.
• offline verifiability — manifests MUST be verifiable without additional network round-trips given only the manifest, its declared CID, and the protocol domain separator.
• stablecoin denomination — provider node compensation IS denominated in a dollar-pegged stablecoin (cUSDC on Base). The protocol issues no speculative native token.

Structural threats to the protocol are addressed in §10 of the whitepaper. Implementations MUST consider at least:

• legal coercion against Aevia LLC does not remove on-chain content; alternative implementations continue to serve even if the canonical client is ordered to de-index.
• dishonest provider is defeated by the byte-range challenge within a tight window (RFC-5 §4).
• Sybil is neutralized because compensation is proportional to byte-hours replicated, not node count.
• DHT eclipse is mitigated by bucket refresh with random probing.
• economic capture of the pool triggers Council review (RFC-7).