protocol · spec
specification
six normative documents in ietf style. they govern manifest schema, content addressing, identity, aup, persistence pool, and risk score.
version 0.1 · canonical source github.com/Leeaandrob/aevia/tree/main/docs/protocol-spec
aevia rfcs follow the ietf style and use rfc 2119 for normative language — MUST and SHOULD carry weight. they are at once the source of truth for implementers and the public contract that investors and lawyers can read.
each rfc is versioned in the repository and anchored on base l2 when published. the index below shows current state. individual rendering is at /spec/{slug}.
| slug | title | status | last updated |
|---|---|---|---|
| rfc-0 | protocol overview | published | 2026-04-14 |
| rfc-1 | manifest schema | published | 2026-04-15 |
| rfc-2 | content addressing | published | 2026-04-15 |
| rfc-3 | authentication and signature | published | 2026-04-16 |
| rfc-4 | acceptable use policy | published | 2026-04-16 |
| rfc-5 | persistence pool | published | 2026-04-16 |
| rfc-6 | risk score | planned | sprint 3 |
| rfc-7 | moderation | planned | sprint 4 |
documents
overview
how the layers fit together. what the thesis is. what is in scope and what is not.
manifest schema
signed json structure describing each piece of content: cid, creator, segments, metadata, signature.
content addressing
cid, ipfs, gateways, and the immutability guarantee of content on base l2.
authentication and signature
privy embedded wallet on base, eip-712, offline verification without gas.
acceptable use policy
what aevia does not amplify, why that preserves section 230, dmca procedures.
persistence pool
how cusdc flows to nodes that prove replication, payment formula, and monitoring.
references
- IETF RFC 2119 — Key words for RFCs
- IPFS Whitepaper — Benet (2014)
- Ethereum EIP-712 — Typed structured data hashing
- DMCA §512 — Safe harbor procedure
- Section 230 (47 U.S.C. §230) — Intermediary immunity