Aevia

We describe Aevia, a protocol that separates the persistence of video content from its distribution. Creators sign typed manifests that enumerate content by immutable content identifiers (CIDs) and anchor those manifests on a public Ethereum Layer 2. Independently operated provider nodes replicate the referenced bytes and receive fee-for-service compensation in a fiat-pegged stablecoin, audited through a periodic challenge-response proof-of-replication protocol. Distribution — ranking, subsidy, and feed surfacing — is governed by a public risk score and a twelve-seat ecumenical council with veto authority over protocol parameters. The resulting architecture gives a creator's work a property that existing video platforms do not provide: its continued existence is not conditional on the continued favor of any single custodian.

Commercial video platforms operate a shared, implicit contract with their creators: the creator provides content, and the platform provides distribution in exchange for an advertising or subscription share. The contract is fragile. A platform's legal, commercial, or political incentives can shift — and when they do, creators are deplatformed, monetization is revoked, and content is removed. The prior audience becomes inaccessible not because the underlying bytes were destroyed, but because the single path that connected the bytes to the audience was severed.

The symmetric failure mode is equally corrosive. Some platforms choose to amplify material the surrounding society has decided does not deserve amplification. The result is an endless public argument in which every side is convinced that some other side has captured the moderation apparatus.

Both failures share a structural assumption: that hosting and recommending are the same act. A platform holds the bytes and decides who sees them. If we separate those two decisions — if we treat persistence (the bytes continue to exist) and distribution (the bytes are shown to people) as independent architectural layers — we can be honest about moderation: any platform that recommends anything is curating, and pretending otherwise is either dishonest or naive. But the bytes themselves do not need to disappear to be de-curated.

This paper describes Aevia, a protocol and a set of reference clients that separate persistence from distribution. The protocol is content-addressed and anchored to a public blockchain. Replication is performed by independently operated provider nodes, compensated for their service in a stablecoin. Distribution — ranking, feed surfacing, subsidy — is governed by a published risk score and a rotating jury. The resulting architecture has a property that existing video platforms do not: the continued existence of a creator's work is not contingent on the continued favor of any single custodian.

We call this property sovereignty. The paper's central axiom — persistence does not imply distribution — is both a design principle and a constraint. It is what makes the architecture honest: we do not pretend to be neutral about what we recommend, and we do not pretend to control what merely exists.

The remainder of this paper is organized as follows. §2–§4 describe the persistence layer: content addressing, signed manifests, and the on-chain registry. §5–§6 describe the replication and network layers. §7–§8 describe the distribution layer and its governance. §9 analyzes the privacy model. §10 examines adversaries. §11 and §12 cover light-client verification and the economic steady state. §13 situates Aevia among related systems. §14 concludes.

The smallest unit of storage in Aevia is an object: an arbitrary byte sequence, typically a video segment, an image, or a manifest. Every object is identified by its Content Identifier (CID), derived deterministically from the object's content by a cryptographic hash function.

We adopt CIDv1 as specified by the Multiformats project [3]. A CID encodes the hash algorithm, the hash digest, and the content codec. Aevia fixes the hash algorithm to SHA-256 and the textual encoding to multibase base32 to ensure a canonical, URL-safe representation. For any object O, its CID is:

where codec is the multicodec prefix identifying the content type (raw = 0x55 for opaque bytes, json = 0x0200 for structured manifests), 0x12 is the multihash identifier for SHA-256, and 0x20 is the digest length in bytes (32).

Two properties of this scheme are load-bearing for the rest of the protocol. First, immutability: the CID is a function of the bytes; any modification of a single bit changes the hash and therefore the CID. Two parties referring to the same CID hold byte-identical content. Second, location independence: the CID does not embed a host, a URL, or an operator. A CID can be satisfied by any node that holds the bytes; the protocol does not privilege any particular source.

Aevia manifests reference video segments by CID, not by URL. This is the minimum sufficient condition for persistence: a creator's content can be served by any willing operator, because the request is for “give me the object whose SHA-256 is X,” not “give me whatever is hosted at URL Y.”

A manifest is a structured JSON document describing a content item. The manifest enumerates segments by CID, carries metadata (creator, timestamp, duration), and is cryptographically signed by the creator. The manifest schema, in abbreviated form, is:

The signature is computed over the canonical JSON encoding [2] of the manifest with the signature field excluded. The signing key is the creator's Ethereum private key, and the signature follows the EIP-712 [6] typed-data format with a domain separator fixed to the Aevia protocol and its chain ID.

Verification is deterministic and offline. Given a manifest M, a verifier:

1. Extracts M.signature and removes it from M to obtain M'.
2. Computes the canonical JSON encoding of M'.
3. Computes the EIP-712 digest over the canonical bytes and the Aevia domain separator.
4. Recovers the signer address from M.signature and the digest.
5. Checks that the recovered address equals M.creator.

Any mismatch in any step invalidates the manifest. No network round-trip is required; the verifier needs only the manifest bytes and the domain separator. This property makes lightweight offline verification practical (§11).

Signatures prove authorship. They do not prove time — a signature tells a verifier who signed, not when. For a public protocol, timestamp proof matters: it establishes precedence, resolves disputes, and enables time-bounded reasoning such as takedown windows and jury rotation.

Aevia uses an on-chain Content Registry for timestamp anchoring. The registry is a Solidity contract deployed on Base, an Ethereum Layer 2 rollup. The contract exposes a single mutating operation:

The contract stores (manifestHash → (creator, registeredAt)) and emits an event on each registration. The on-chain block timestamp provides an authoritative lower bound on the manifest's age.

We chose Base for three reasons. First, Base inherits Ethereum security via optimistic rollup fraud proofs; no separate trust assumption is needed beyond Ethereum's. Second, Base fees are approximately 0.1–1% of Ethereum Layer 1 fees, making registration economical for individual creators. Third, Base's account abstraction infrastructure allows Aevia to sponsor gas for creators via a relayer, so a first-time creator signs a manifest without holding native ETH.

Gas-sponsored registration is important for onboarding but must not create a trust bottleneck. The relayer is permissionless in the sense that any sponsor may submit any signed manifest; the signature is verified on-chain, and the sponsor receives a fixed fee per registration. Sponsors cannot forge manifests or modify the registered data.

The registry is append-only: registered manifests cannot be removed, only superseded by subsequent registrations. A creator who wishes to publish a revision registers a new manifest pointing to new CIDs; the old manifest remains in the registry with its original timestamp. Consumers select the latest version by querying the registry. This is deliberate: the Registry serves as an historical record of what was published, which is independent of whether a given version remains current.

The Content Registry proves that content existed at a specific time; it does not ensure that the content remains accessible. Accessibility requires that the raw bytes — the video segments themselves — continue to live on physical infrastructure operated by willing custodians.

Aevia's persistence layer is an economic market. Provider nodes replicate content and are compensated, in a dollar-denominated stablecoin (cUSDC on Base), for time spent hosting and responding to retrieval requests. The compensation contract — the Persistence Pool — holds a running balance in cUSDC and disburses to provider nodes based on auditable metrics.

A provider node's compensation over a payment epoch t is:

where:

• R_i(t) is the fraction of replication challenges successfully answered by node i during epoch t, in [0, 1].
• B_i(t) is the total byte-hours of content replicated by node i during epoch t.
• W_region(i) ∈ {0.5, 1.0, 1.5} is a region weight encoding geographic redundancy (low, medium, high scarcity).
• ρ(t) is the pool's unit rate for epoch t, computed as (pool_balance · ε) / Σ_i (R_i · B_i · W_region), where ε is the per-epoch disbursement fraction.

The challenge-response protocol is the core of the replication proof. At random intervals, the pool contract emits a challenge c_k consisting of (i) a target CID x, (ii) a random byte range [a, b] within the object identified by x, and (iii) a block number n at which the challenge expires.

Each provider node claiming to hold x must respond before block n with the raw bytes x[a..b] and an on-chain proof commitment. The contract verifies the bytes against the known CID; for large objects, a Merkle tree of content chunks allows O(log n) verification without storing the full object on-chain. A correct, timely response increments R_i; a missing or incorrect response decrements it.

The protocol resists two attacks. A node claiming to hold content it does not have cannot respond to a random-range challenge without storing the content; fetching from a peer at challenge time is defeated by tight response windows (typical inter-peer fetch latency exceeds the challenge window). A node that has stored the content but is offline at challenge time is indistinguishable from one that has lost the data; the protocol treats both as failures, which is the correct incentive — the contract pays for availability, not for claimed custody.

Challenges are Poisson-distributed with expected rate λ per node per epoch. Setting λ such that the expected number of challenges per epoch is large (e.g., 100 or more) reduces the variance of R_i and makes compensation predictable for honest operators.

Content must flow from provider nodes to viewers. Aevia uses libp2p as the transport substrate and the Kademlia distributed hash table (DHT) [9] for content discovery.

Every provider node operates a libp2p host identified by a self-generated ed25519 keypair. The host participates in a Kademlia DHT scoped to the protocol namespace /aevia/kad/1.0.0. The DHT stores mappings (cid → [provider_peer_id, ...]), allowing any node to discover which peers claim to hold a given CID. The DHT is eventually consistent under honest-majority assumptions; providers that newly replicate a CID call Provide(cid) to announce availability, and viewers call FindProviders(cid) to retrieve the current set of candidate peers.

Peers behind NAT or restrictive firewalls cannot be reached by direct dial. We address this with Circuit Relay v2: NATted peers register with public relay nodes and announce their reachable identity /p2p/<relay>/p2p-circuit/p2p/<peer> in the DHT. Viewers dial the relay identity; the relay forwards the encrypted stream.

For browser-based viewers, Aevia uses WebTransport and WebRTC. The client establishes a WebTransport connection to a provider node — directly when possible, through a libp2p WebTransport gateway otherwise — and requests HLS segments by CID. The provider serves the bytes after verifying the requester is within applicable rate limits.

Content retrieval is opportunistic and parallel. A client may request the same CID from multiple providers concurrently, accepting the first valid response. A valid response is one whose bytes hash to the expected CID; invalid responses are discarded without retry to that peer. This design provides natural defense against malicious providers serving corrupted content: the client discovers corruption immediately and selects an honest peer from the remaining candidates.

The protocol's distribution decisions — which content receives subsidy from the persistence pool, which content is surfaced in the curated feed, which content the ranking algorithm boosts — are governed by a Risk Score. The Risk Score is an off-chain computation with a published formula:

with default weights α = 0.4, β = 0.3, γ = 0.3. Each component is normalized to the interval [0, 1]:

• R_legal(c) reflects the content's legal-risk signal. Inputs include DMCA takedown requests targeting the CID [11], DSA notice-and-action reports [12], and subpoenas. A CID with no legal signals has R_legal = 0; a CID with an active, un-rebutted takedown has R_legal ≈ 1.
• R_abuse(c) reflects user-report and jury signals. Inputs include flag counts (weighted by reporter reputation), jury review outcomes, and prior-content signals from the same creator. A new CID from a new creator begins with R_abuse = 0; accumulated jury decisions raise or lower the score.
• R_values(c) reflects alignment with the Acceptable Use Policy (AUP). Inputs include a classifier output (trained on a public dataset of AUP-conforming and AUP-excluded content) and manual review outcomes. R_values is higher for content that the classifier or reviewers identify as within the AUP's excluded categories.

Two thresholds govern protocol behavior:

• R(c) ≥ θ_subsidy excludes c from persistence-pool subsidy. Provider nodes replicating c receive no W_region-weighted compensation; they may still hold and serve c at their own expense.
• R(c) ≥ θ_feed excludes c from the curated feed and ranking surfaces operated by Aevia clients. The content remains retrievable by CID; it simply is not promoted.

Default thresholds are θ_subsidy = 0.5 and θ_feed = 0.3. Both are parameters of the protocol, subject to governance (§8). The absolute numbers are less important than the design property: the decision to subsidize or surface is public, auditable, and contestable.

The component scores R_legal, R_abuse, R_values are recomputed periodically and published to a public Trust Ledger, where every score change carries a cryptographic signature from the pool's ranking service. A creator who believes a score is incorrect can request a jury review (§8).

Parameter changes — the α, β, γ weights; the θ_subsidy, θ_feed thresholds; the challenge rate λ; the per-epoch disbursement ε — are not at the discretion of Aevia LLC. They are decided by an Ecumenical Council: twelve independent seats, four-year terms, with veto authority over parameter proposals.

The Council's composition is deliberately plural. Seats are held by individuals (not organizations) with a publicly declared theological, philosophical, or professional perspective: practicing clergy, secular legal scholars, human rights activists, technical cryptographers, and others. No single tradition or interest holds a majority. A parameter proposal requires simple majority (≥7/12) to pass, but any Council member may exercise a one-time veto per term to block a proposal they judge incompatible with the protocol's stated values.

Council deliberations are recorded on the public Trust Ledger. Each deliberation publishes: the proposal text, per-member votes, veto invocations, and dissenting opinions. The Ledger is itself a Merkle-anchored log on Base, making it auditable and append-only.

Council elections occur every four years. The electorate is the set of established operators — creators and provider nodes who have been active for at least twelve months and who have maintained AUP conformance. Election mechanics are themselves governed by the Council (meta-governance); the initial bootstrap Council is appointed by Aevia LLC with a public justification for each seat.

This structure balances two tensions. First, centralized governance collapses to the preferences of Aevia LLC; the Council exists to prevent this. Second, purely decentralized governance suffers either from plutocracy (one token, one vote) or from Sybil risk (one person, one vote, where “person” is unverifiable). The fixed twelve seats, long terms, and plural composition are a deliberate simplification that trades off some legitimacy for predictable, non-capturable decision-making.

Aevia's privacy guarantees follow from its architecture rather than from operational opacity. Three threat models bound the analysis.

Passive observer. An entity that watches the public blockchain and public IPFS gateway traffic observes every registered manifest (creator address, timestamp, CID), every public provider-node peer ID, and every DHT announcement. It cannot observe which viewer watched which content (unless the viewer fetches through a public gateway), email addresses, or IP addresses of creators signing through the relayer.

Active adversary. An entity that operates one or more malicious provider nodes, joins the DHT, and observes retrieval requests sees which CIDs are requested from their nodes and from which peer IDs. It cannot observe the real-world identity of the requesting peer (peer IDs are ephemeral and regenerated frequently) or aggregate viewership of any CID (each adversary sees only requests routed to them).

Legal coercion. A government or party that obtains a court order compelling Aevia LLC to disclose data has access to any data Aevia LLC holds: creator email addresses (if provided), relayer logs (retained thirty days), payment records, and Council deliberations. It does not have access to data Aevia LLC does not hold, which includes the on-chain manifests (already public), the content bytes stored by independent provider nodes outside Aevia LLC's control, and the real-world identities of viewers (not collected).

The protocol's privacy properties are asymmetric by design. Authorship is public (creators sign manifests with on-chain wallets); viewership is private (no identity tracking at the retrieval layer); administrative metadata is legally discoverable but deliberately minimized.

Creators who require anonymity have two paths. They may sign with a wallet unconnected to their real-world identity, accepting the operational burden of key management. Or they may sign through a pseudonymous relayer — a service that re-signs manifests on behalf of creators after a KYC check, retaining only the pseudonym linkage. Aevia does not operate such a relayer in v1; the protocol admits their construction by third parties.

We analyze five attack classes.

(a) Dishonest provider. An adversary operates a provider node that claims to hold content it does not have, collecting subsidy fraudulently. The challenge-response protocol (§5) requires the provider to produce arbitrary byte ranges of claimed content within a tight deadline. Fetching from a peer at challenge time is blocked by the deadline. The probability of a dishonest provider surviving epoch t undetected, given λ challenges per epoch and per-challenge detection probability p, is (1 − p)^λ. With λ = 100 and p = 0.9, the survival probability is 10^−100. In practice the adversary is detected in the first epoch.

(b) Sybil provider. An adversary operates many provider-node identities to inflate their compensation share. Compensation is proportional to byte-hours replicated and audited, not to node count. An adversary running one hundred Sybil nodes each holding 1% of the content receives the same total compensation as a single node holding 100% — the sum is the same. The adversary cannot inflate B_i without actually holding the bytes. The W_region weight introduces a minor incentive for geographic diversity, which slightly favors genuine multi-site operators, but Sybil is not the critical threat vector here.

(c) Censorship via legal coercion. An adversary pressures Aevia LLC to remove a specific manifest from the Content Registry. The Registry is append-only and on-chain; Aevia LLC cannot unilaterally delete a registered manifest. Aevia LLC can be ordered to stop indexing a CID in its client surfaces, but indexing is an editorial decision, not a protocol decision. The manifest remains on Base, discoverable via block explorer; provider nodes outside Aevia LLC's jurisdiction continue to serve the content; alternative clients can render it. This is the architectural expression of persistence ≠ distribution.

(d) Eclipse attack on DHT. An adversary fills the DHT routing table of a target peer with adversary-controlled identities, isolating the target from honest peers. Kademlia's k-bucket structure requires an adversary to control an adversary-majority of peers in the target's routing-table buckets, which are k wide per bucket and cover the target's key-space neighborhood. For a network of 10,000 peers and k = 20, the attack requires on the order of ~160 strategically placed adversarial peer IDs. Aevia's DHT additionally uses bucket refresh with random probing, which prevents permanent eclipse; a refreshed bucket will include new honest peers as they join. The attack is expensive and transient.

(e) Economic attack on the Persistence Pool. An adversary who controls a large share of the pool's compensation flows can drive down the per-epoch rate for honest operators. We do not claim a provably secure defense. The protocol's empirical defense is pluralism: the pool contract is public, adversary behavior is auditable, and a persistent attack triggers Council review (§8). If an adversary captures the pool, the Council can propose a fork of the compensation contract that excludes the adversary; the Council's veto structure makes this a possible but deliberately non-trivial action.

A light client — a viewer that does not maintain a full index of the Content Registry — can verify a manifest's validity and currency with a small number of network requests.

Given a manifest M claimed to be current for creator address c at time t:

1. Compute the canonical hash h = H(canonical(M \ signature)).
2. Query the Content Registry: registeredAt, registeredCreator = Registry.lookup(h).
3. Verify registeredCreator == c.
4. Verify registeredAt ≤ t.
5. Verify EIP-712 signature: recover(M.signature, h) == c.
6. Verify each referenced CID: fetch the content, compute its CID, and compare to the manifest's claim.

A complete verification requires one contract call (step 2), one signature recovery (step 5), and one hash-check per referenced CID (step 6). For a typical video manifest with 342 HLS segments, this is 342 content hashes, one manifest hash, and one signature recovery — roughly 50 ms on consumer hardware.

The light client does not need to trust any server or gateway. A malicious gateway can only cause the verification to fail (by serving wrong content); it cannot cause a wrong manifest to be accepted.

The Persistence Pool operates on a conservation principle: over any epoch, the total compensation paid equals the total disbursement from the pool balance. The pool is replenished by a fraction of creator-directed credit flows (the credit pulse) and, during bootstrap, by Aevia LLC directly.

Let S(t) be the pool balance at epoch t, I(t) the incoming credit-pulse fraction, and O(t) the disbursement. The balance evolves as:

For a steady-state equilibrium S*, we require O(t) = I(t), giving S* = I / ε.

This has a useful consequence. The per-epoch rate ρ(t) is ε · S(t) / Σ_i (R_i · B_i · W_region). At equilibrium,

The rate scales linearly with creator credit flow and inversely with replicated volume. As more creators send credit through the pulse, rates rise; as more provider nodes join, rates fall. The market is self-equilibrating.

Break-even for a provider node depends on operating cost per byte-hour and on expected R · B · W. Consider a node in a high-weight region (W = 1.5) with 99% uptime (R = 0.99), holding 10 TB for a month (B ≈ 7.2 · 10^15 byte-hours). The node earns 0.99 · 7.2·10^15 · 1.5 · ρ cUSDC. With ρ set such that the steady-state rate yields approximately $5 per TB-month for high-weight regions, the node earns roughly $75/month for the 10 TB. Operating cost for the same 10 TB on consumer infrastructure — electricity, bandwidth, hardware amortization — is typically $15–30/month. The margin is real but modest.

The model does not rely on speculative appreciation. Compensation is denominated in a fiat-pegged stablecoin; a provider's return is determined by their replication performance, not by token-price movements. This is an intentional contrast with designs that depend on native-token appreciation to make the economic loop close.

Aevia draws on several prior systems, each of which solves a subset of the problem.

IPFS [3] introduced content-addressed storage and the Kademlia DHT for decentralized retrieval. IPFS does not specify an economic incentive for persistence; content disappears when the last pinning node drops it.

Filecoin [4] built an economic layer on IPFS, using proof-of-spacetime and proof-of-replication to compensate storage miners. Filecoin's design targets cold archival: deals are typically 6–12 months with large sector sizes and high retrieval latency. Aevia's persistence layer is shorter-horizon and retrieval-first, and operates on Base rather than on a bespoke chain.

Arweave [5] uses a different model: a one-time perpetual payment into an endowment that compounds and funds indefinite replication. Arweave is optimized for permanent archival, accepts higher up-front cost, and does not separate persistence from distribution.

Livepeer [10] addresses a different problem — transcoding at scale — using a similar provider-node and payment structure but focused on video processing rather than storage.

LBRY/Odysee, PeerTube, and Rumble address video distribution without a protocol-level guarantee of persistence: their content can be de-platformed by the operator of the federated instance or the centralized service. Aevia's persistence layer is intended to outlive any individual client.

BitTorrent demonstrated that distributed replication is viable at scale when aligned with user incentive. Aevia generalizes the pattern by making the incentive explicit (cUSDC compensation) rather than implicit (tit-for-tat choking).

What Aevia contributes on top of these is the separation principle: persistence and distribution as distinct economic and governance layers. The Content Registry anchors persistence; the Risk Score and Council govern distribution. Existing systems either collapse the two (mainstream video platforms) or address only one of them (pure storage protocols).

We have described a protocol in which a creator's content persists in a network of economically compensated replicators, indexed by a public on-chain registry, and signed with a verifiable cryptographic identity. Distribution — ranking, feed surfacing, subsidy — is governed by a public, contestable risk score and a twelve-seat Ecumenical Council.

The architecture takes a position: persistence is infrastructure and should be neutral; distribution is editorial and should be honest. We do not claim neutrality about what we recommend. We do claim that the continued existence of a creator's work is not, and should not be, conditional on our recommendation.

The protocol is open-source: Apache-2.0 for the contracts and the specification; AGPL-3.0 for reference clients; MIT for the shared design system. The Content Registry address on Base is public. The Council's deliberations are on the public Trust Ledger. Every claim in this paper is verifiable in code.