Aevia

Descrevemos Aevia, um protocolo que separa a persistência do conteúdo de vídeo de sua distribuição. Criadores assinam manifestos tipados que enumeram o conteúdo por identificadores imutáveis (CIDs) e ancoram esses manifestos em uma Layer 2 pública do Ethereum. Provider nodes operados independentemente replicam os bytes referenciados e recebem compensação fee-for-service em uma stablecoin atrelada ao dólar, auditada por um protocolo periódico de proof-of-replication baseado em challenge-response. Distribuição — ranking, subsídio e surface no feed — é governada por um risk score público e por um conselho ecumênico de doze assentos com poder de veto sobre parâmetros do protocolo. A arquitetura resultante dá ao trabalho de um criador uma propriedade que plataformas de vídeo existentes não oferecem: sua existência continuada não é condicional ao favor continuado de um único custodiante.

Plataformas comerciais de vídeo operam um contrato implícito e compartilhado com seus criadores: o criador fornece conteúdo, e a plataforma fornece distribuição em troca de uma parte da publicidade ou da assinatura. O contrato é frágil. Incentivos jurídicos, comerciais ou políticos de uma plataforma podem mudar — e quando mudam, criadores são desplataformados, monetização é revogada, conteúdo é removido. A audiência anterior se torna inacessível não porque os bytes foram destruídos, mas porque o único caminho que conectava os bytes à audiência foi cortado.

A falha simétrica é igualmente corrosiva. Algumas plataformas escolhem amplificar material que a sociedade ao redor já decidiu que não merece amplificação. O resultado é uma discussão pública interminável em que cada lado está convencido de que algum outro lado capturou o aparato de moderação.

Ambas as falhas compartilham uma premissa estrutural: que hospedar e recomendar são o mesmo ato. Uma plataforma detém os bytes e decide quem os vê. Se separarmos essas duas decisões — se tratarmos persistência (os bytes continuam existindo) e distribuição (os bytes são exibidos para pessoas) como camadas arquiteturais independentes — podemos ser honestos sobre moderação: qualquer plataforma que recomenda algo está curando, e fingir o contrário é desonesto ou ingênuo. Mas os bytes em si não precisam desaparecer para serem descurados.

Este paper descreve Aevia, um protocolo e um conjunto de clientes de referência que separam persistência de distribuição. O protocolo é content-addressed e ancorado em uma blockchain pública. A replicação é executada por provider nodes operados independentemente, compensados pelo serviço em stablecoin. Distribuição — ranking, surface de feed, subsídio — é governada por um risk score publicado e por um júri rotativo. A arquitetura resultante tem uma propriedade que plataformas de vídeo existentes não têm: a existência continuada do trabalho de um criador não está condicionada ao favor continuado de um único custodiante.

Chamamos essa propriedade de soberania. O axioma central do paper — persistência não implica distribuição — é ao mesmo tempo princípio de design e constraint. É o que torna a arquitetura honesta: não pretendemos ser neutros sobre o que recomendamos, e não pretendemos controlar o que apenas existe.

O restante deste paper está organizado como segue. §2–§4 descrevem a camada de persistência: content addressing, manifestos assinados e o registry on-chain. §5–§6 descrevem as camadas de replicação e de rede. §7–§8 descrevem a camada de distribuição e sua governança. §9 analisa o modelo de privacidade. §10 examina adversários. §11 e §12 cobrem verificação por light-client e o estado estacionário econômico. §13 situa Aevia entre sistemas relacionados. §14 conclui.

A menor unidade de armazenamento em Aevia é um objeto: uma sequência arbitrária de bytes, tipicamente um segmento de vídeo, uma imagem ou um manifesto. Todo objeto é identificado pelo seu Content Identifier (CID), derivado deterministicamente do conteúdo do objeto por uma função hash criptográfica.

Adotamos CIDv1 conforme especificado pelo projeto Multiformats [3]. Um CID codifica o algoritmo de hash, o digest e o codec do conteúdo. Aevia fixa o algoritmo em SHA-256 e a codificação textual em multibase base32 para garantir uma representação canônica e URL-safe. Para qualquer objeto O, seu CID é:

onde codec é o prefixo multicodec identificando o tipo de conteúdo (raw = 0x55 para bytes opacos, json = 0x0200 para manifestos estruturados), 0x12 é o identificador multihash para SHA-256 e 0x20 é o comprimento do digest em bytes (32).

Duas propriedades desse esquema são load-bearing para o resto do protocolo. Primeira, imutabilidade: o CID é função dos bytes; qualquer modificação de um bit altera o hash e, portanto, o CID. Duas partes referindo-se ao mesmo CID detêm conteúdo byte-idêntico. Segunda, independência de localização: o CID não embute host, URL ou operador. Um CID pode ser satisfeito por qualquer nó que detenha os bytes; o protocolo não privilegia nenhuma fonte específica.

Manifestos Aevia referenciam segmentos de vídeo por CID, não por URL. Essa é a condição mínima suficiente para persistência: o conteúdo de um criador pode ser servido por qualquer operador disposto, porque o pedido é “me dê o objeto cujo SHA-256 é X”, não “me dê o que quer que esteja hospedado na URL Y”.

Um manifesto é um documento JSON estruturado que descreve um item de conteúdo. O manifesto enumera segmentos por CID, carrega metadados (criador, timestamp, duração) e é assinado criptograficamente pelo criador. O schema do manifesto, em forma abreviada, é:

A assinatura é computada sobre a codificação JSON canônica [2] do manifesto com o campo signature excluído. A chave de assinatura é a chave privada Ethereum do criador, e a assinatura segue o formato typed-data EIP-712 [6] com um domain separator fixado ao protocolo Aevia e seu chain ID.

Verificação é determinística e offline. Dado um manifesto M, um verificador:

1. Extrai M.signature e o remove de M para obter M'.
2. Computa a codificação JSON canônica de M'.
3. Computa o digest EIP-712 sobre os bytes canônicos e o domain separator da Aevia.
4. Recupera o endereço do signer a partir de M.signature e do digest.
5. Verifica que o endereço recuperado é igual a M.creator.

Qualquer mismatch em qualquer passo invalida o manifesto. Nenhum round-trip de rede é necessário; o verificador precisa apenas dos bytes do manifesto e do domain separator. Essa propriedade torna prática a verificação offline leve (§11).

Assinaturas provam autoria. Elas não provam tempo — uma assinatura diz ao verificador quem assinou, não quando. Para um protocolo público, a prova de timestamp importa: ela estabelece precedência, resolve disputas e habilita raciocínio com janelas de tempo, como janelas de takedown e rotação de júri.

Aevia usa um Content Registry on-chain para ancoragem de timestamp. O registry é um contrato Solidity deployado em Base, um rollup Ethereum Layer 2. O contrato expõe uma única operação mutante:

O contrato armazena (manifestHash → (creator, registeredAt)) e emite um evento a cada registro. O timestamp de bloco on-chain fornece um lower bound autoritativo da idade do manifesto.

Escolhemos Base por três razões. Primeiro, Base herda a segurança do Ethereum via fraud proofs de optimistic rollup; nenhuma premissa de trust separada é necessária além da do Ethereum. Segundo, as fees em Base são aproximadamente 0,1–1% das fees do Ethereum Layer 1, tornando o registro econômico para criadores individuais. Terceiro, a infraestrutura de account abstraction de Base permite que Aevia patrocine gas para criadores via relayer, de modo que um criador de primeira viagem assina um manifesto sem segurar ETH nativo.

Registro com gas patrocinado é importante para onboarding, mas não deve criar um gargalo de confiança. O relayer é permissionless no sentido de que qualquer sponsor pode submeter qualquer manifesto assinado; a assinatura é verificada on-chain, e o sponsor recebe uma taxa fixa por registro. Sponsors não podem forjar manifestos nem modificar os dados registrados.

O registry é append-only: manifestos registrados não podem ser removidos, apenas superados por registros subsequentes. Um criador que deseja publicar uma revisão registra um novo manifesto apontando para novos CIDs; o manifesto antigo permanece no registry com seu timestamp original. Consumidores selecionam a versão mais recente consultando o registry. Isso é deliberado: o Registry serve como registro histórico do que foi publicado, independente de uma versão permanecer corrente ou não.

O Content Registry prova que o conteúdo existiu em um momento específico; não garante que o conteúdo permanece acessível. Acessibilidade requer que os bytes brutos — os próprios segmentos de vídeo — continuem vivendo em infraestrutura física operada por custodiantes dispostos.

A camada de persistência de Aevia é um mercado econômico. Provider nodes replicam conteúdo e são compensados, em uma stablecoin atrelada ao dólar (cUSDC em Base), pelo tempo gasto hospedando e respondendo a pedidos de retrieval. O contrato de compensação — o Persistence Pool — mantém saldo corrente em cUSDC e desembolsa para provider nodes com base em métricas auditáveis.

A compensação de um provider node ao longo de uma epoch de pagamento t é:

onde:

• R_i(t) é a fração de challenges de replicação respondidos com sucesso pelo nó i durante a epoch t, em [0, 1].
• B_i(t) é o total de byte-horas de conteúdo replicado pelo nó i durante a epoch t.
• W_region(i) ∈ {0.5, 1.0, 1.5} é o peso regional codificando redundância geográfica (escassez baixa, média, alta).
• ρ(t) é a taxa unitária do pool para a epoch t, computada como (pool_balance · ε) / Σ_i (R_i · B_i · W_region), onde ε é a fração de desembolso por epoch.

O protocolo de challenge-response é o núcleo da prova de replicação. Em intervalos aleatórios, o contrato do pool emite um challenge c_k consistindo de (i) um CID-alvo x, (ii) uma faixa aleatória de bytes [a, b] dentro do objeto identificado por x e (iii) um número de bloco n no qual o challenge expira.

Cada provider node alegando deter x deve responder antes do bloco n com os bytes brutos x[a..b] e um commitment de prova on-chain. O contrato verifica os bytes contra o CID conhecido; para objetos grandes, uma árvore Merkle de chunks de conteúdo permite verificação O(log n) sem armazenar o objeto completo on-chain. Uma resposta correta e em tempo incrementa R_i; uma resposta ausente ou incorreta a decrementa.

O protocolo resiste a dois ataques. Um nó que alega deter conteúdo que não tem não consegue responder a um challenge de faixa aleatória sem armazenar o conteúdo; buscar de um peer no momento do challenge é derrotado por janelas de resposta apertadas (latência típica de fetch inter-peer excede a janela). Um nó que armazenou o conteúdo mas está offline no momento do challenge é indistinguível de um que perdeu os dados; o protocolo trata ambos como falhas, o que é o incentivo correto — o contrato paga por disponibilidade, não por custódia alegada.

Challenges são distribuídos por Poisson com taxa esperada λ por nó por epoch. Setar λ de modo que o número esperado de challenges por epoch seja grande (ex: 100 ou mais) reduz a variância de R_i e torna a compensação previsível para operadores honestos.

Conteúdo deve fluir de provider nodes para viewers. Aevia usa libp2p como substrato de transporte e a distributed hash table (DHT) Kademlia [9] para descoberta de conteúdo.

Todo provider node opera um host libp2p identificado por um par de chaves ed25519 auto-gerado. O host participa de uma DHT Kademlia delimitada pelo namespace do protocolo /aevia/kad/1.0.0. A DHT armazena mapeamentos (cid → [provider_peer_id, ...]), permitindo que qualquer nó descubra quais peers alegam deter um CID dado. A DHT é eventually consistent sob premissas de maioria honesta; providers que replicam um CID pela primeira vez chamam Provide(cid) para anunciar disponibilidade, e viewers chamam FindProviders(cid) para obter o conjunto atual de peers candidatos.

Peers atrás de NAT ou firewalls restritivos não podem ser alcançados por dial direto. Tratamos isso com Circuit Relay v2: peers NATted registram-se em nós relay públicos e anunciam sua identidade alcançável /p2p/<relay>/p2p-circuit/p2p/<peer> na DHT. Viewers discam a identidade de relay; o relay encaminha o stream criptografado.

Para viewers em browser, Aevia usa WebTransport e WebRTC. O cliente estabelece uma conexão WebTransport com um provider node — diretamente quando possível, via um gateway WebTransport libp2p caso contrário — e solicita segmentos HLS por CID. O provider serve os bytes após verificar que o requester está dentro dos rate limits aplicáveis.

Retrieval de conteúdo é oportunístico e paralelo. Um cliente pode requisitar o mesmo CID de múltiplos providers concorrentemente, aceitando a primeira resposta válida. Uma resposta válida é aquela cujos bytes produzem o CID esperado; respostas inválidas são descartadas sem retry para aquele peer. Esse design oferece defesa natural contra providers maliciosos servindo conteúdo corrompido: o cliente descobre a corrupção imediatamente e seleciona um peer honesto dentre os candidatos restantes.

As decisões de distribuição do protocolo — qual conteúdo recebe subsídio do persistence pool, qual conteúdo aparece no feed curado, qual conteúdo o algoritmo de ranking eleva — são governadas por um Risk Score. O Risk Score é uma computação off-chain com fórmula publicada:

com pesos default α = 0.4, β = 0.3, γ = 0.3. Cada componente é normalizado para o intervalo [0, 1]:

• R_legal(c) reflete o sinal de risco legal do conteúdo. Entradas incluem pedidos de takedown DMCA dirigidos ao CID [11], notice-and-action DSA [12] e subpoenas. Um CID sem sinais legais tem R_legal = 0; um CID com takedown ativo não contestado tem R_legal ≈ 1.
• R_abuse(c) reflete sinais de reporte de usuários e júri. Entradas incluem contagem de flags (ponderada pela reputação do reporter), resultados de revisão por júri e sinais de conteúdo prévio do mesmo criador. Um CID novo de um criador novo começa com R_abuse = 0; decisões acumuladas do júri elevam ou reduzem o score.
• R_values(c) reflete alinhamento com a Acceptable Use Policy (AUP). Entradas incluem saída de classificador (treinado em um dataset público de conteúdo AUP-conforme e AUP-excluído) e resultados de revisão manual. R_values é mais alto para conteúdo que o classificador ou revisores identificam como dentro das categorias excluídas pela AUP.

Dois thresholds governam o comportamento do protocolo:

• R(c) ≥ θ_subsidy exclui c do subsídio do persistence pool. Provider nodes que replicam c não recebem compensação ponderada por W_region; podem ainda deter e servir c por conta própria.
• R(c) ≥ θ_feed exclui c do feed curado e das superfícies de ranking operadas por clientes Aevia. O conteúdo permanece recuperável por CID; simplesmente não é promovido.

Thresholds default são θ_subsidy = 0.5 e θ_feed = 0.3. Ambos são parâmetros do protocolo, sujeitos a governança (§8). Os números absolutos importam menos que a propriedade de design: a decisão de subsidiar ou surface é pública, auditável e contestável.

Os scores componentes R_legal, R_abuse, R_values são recomputados periodicamente e publicados em um Trust Ledger público, onde toda mudança de score carrega uma assinatura criptográfica do serviço de ranking do pool. Um criador que acredita que um score está incorreto pode solicitar revisão por júri (§8).

Mudanças de parâmetro — os pesos α, β, γ; os thresholds θ_subsidy, θ_feed; a taxa de challenge λ; o desembolso por epoch ε — não ficam a critério da Aevia LLC. São decididas por um Conselho Ecumênico: doze assentos independentes, mandatos de quatro anos, com poder de veto sobre propostas de parâmetro.

A composição do Conselho é deliberadamente plural. Os assentos são ocupados por indivíduos (não organizações) com perspectiva teológica, filosófica ou profissional publicamente declarada: clérigos em exercício, acadêmicos de direito seculares, ativistas de direitos humanos, criptógrafos técnicos, entre outros. Nenhuma tradição ou interesse único detém maioria. Uma proposta de parâmetro requer maioria simples (≥7/12) para passar, mas qualquer conselheiro pode exercer um veto único por mandato para bloquear uma proposta que considere incompatível com os valores declarados do protocolo.

Deliberações do Conselho são registradas no Trust Ledger público. Cada deliberação publica: o texto da proposta, votos por conselheiro, invocações de veto e opiniões divergentes. O Ledger é em si um log Merkle-anchored em Base, tornando-o auditável e append-only.

Eleições do Conselho ocorrem a cada quatro anos. O eleitorado é o conjunto de operadores estabelecidos — criadores e provider nodes ativos há pelo menos doze meses e que mantiveram conformidade com a AUP. A mecânica das eleições é governada pelo próprio Conselho (metagovernança); o Conselho inicial de bootstrap é nomeado pela Aevia LLC com justificativa pública para cada assento.

Essa estrutura equilibra duas tensões. Primeira, governança centralizada colapsa nas preferências da Aevia LLC; o Conselho existe para prevenir isso. Segunda, governança puramente descentralizada sofre ou de plutocracia (one token, one vote) ou de risco Sybil (one person, one vote, onde “person” é inverificável). Os doze assentos fixos, mandatos longos e composição plural são uma simplificação deliberada que troca alguma legitimidade por decisões previsíveis e não-capturáveis.

As garantias de privacidade de Aevia seguem de sua arquitetura e não de opacidade operacional. Três modelos de ameaça delimitam a análise.

Observador passivo. Uma entidade que observa a blockchain pública e o tráfego de gateways IPFS públicos observa todo manifesto registrado (endereço do criador, timestamp, CID), todo peer ID público de provider node e todo anúncio na DHT. Não consegue observar qual viewer assistiu qual conteúdo (a menos que o viewer busque via gateway público), endereços de e-mail ou IPs de criadores assinando via relayer.

Adversário ativo. Uma entidade que opera um ou mais provider nodes maliciosos, entra na DHT e observa pedidos de retrieval vê quais CIDs são requisitados de seus nós e de quais peer IDs. Não consegue observar a identidade real do peer que requisita (peer IDs são efêmeros e regenerados com frequência) nem a audiência agregada de qualquer CID (cada adversário vê apenas requisições roteadas a ele).

Coerção legal. Um governo ou parte que obtenha ordem judicial compelindo Aevia LLC a divulgar dados tem acesso a qualquer dado que Aevia LLC detenha: endereços de e-mail de criadores (se fornecidos), logs do relayer (retidos trinta dias), registros de pagamento e deliberações do Conselho. Não tem acesso a dados que Aevia LLC não detém, o que inclui os manifestos on-chain (já públicos), os bytes de conteúdo armazenados por provider nodes independentes fora do controle da Aevia LLC e as identidades reais de viewers (não coletadas).

As propriedades de privacidade do protocolo são assimétricas por design. Autoria é pública (criadores assinam manifestos com wallets on-chain); audiência é privada (sem tracking de identidade na camada de retrieval); metadados administrativos são legalmente descobríveis mas deliberadamente minimizados.

Criadores que requerem anonimato têm dois caminhos. Podem assinar com uma wallet não conectada à sua identidade real, aceitando o ônus operacional de gestão de chaves. Ou podem assinar via relayer pseudônimo — um serviço que re-assina manifestos em nome de criadores após um KYC, retendo apenas a ligação com o pseudônimo. Aevia não opera tal relayer em v1; o protocolo admite sua construção por terceiros.

Analisamos cinco classes de ataque.

(a) Provider desonesto. Um adversário opera um provider node que alega deter conteúdo que não tem, coletando subsídio fraudulentamente. O protocolo de challenge-response (§5) exige que o provider produza faixas arbitrárias de bytes do conteúdo alegado dentro de um deadline apertado. Buscar de um peer no momento do challenge é bloqueado pelo deadline. A probabilidade de um provider desonesto sobreviver à epoch t sem ser detectado, dados λ challenges por epoch e probabilidade de detecção por challenge p, é (1 − p)^λ. Com λ = 100 e p = 0.9, a probabilidade de sobrevivência é 10^−100. Na prática, o adversário é detectado já na primeira epoch.

(b) Provider Sybil. Um adversário opera muitas identidades de provider node para inflar sua participação na compensação. A compensação é proporcional a byte-horas replicadas e auditadas, não à contagem de nós. Um adversário rodando cem nós Sybil cada um detendo 1% do conteúdo recebe a mesma compensação total que um único nó detendo 100% — a soma é a mesma. O adversário não consegue inflar B_i sem de fato deter os bytes. O peso W_region introduz um incentivo menor para diversidade geográfica, o que favorece ligeiramente operadores multi-site reais, mas Sybil não é o vetor de ameaça crítico aqui.

(c) Censura via coerção legal. Um adversário pressiona a Aevia LLC a remover um manifesto específico do Content Registry. O Registry é append-only e on-chain; Aevia LLC não pode deletar unilateralmente um manifesto registrado. Aevia LLC pode ser ordenada a parar de indexar um CID em suas superfícies de cliente, mas indexar é decisão editorial, não decisão de protocolo. O manifesto permanece em Base, descobrível via block explorer; provider nodes fora da jurisdição da Aevia LLC continuam a servir o conteúdo; clientes alternativos podem renderizá-lo. Essa é a expressão arquitetural de persistência ≠ distribuição.

(d) Ataque de eclipse na DHT. Um adversário preenche a tabela de roteamento DHT de um peer-alvo com identidades controladas pelo adversário, isolando o alvo de peers honestos. A estrutura de k-buckets do Kademlia exige que o adversário controle maioria adversarial dos peers nos buckets de roteamento do alvo, que têm largura k e cobrem a vizinhança do alvo no keyspace. Para uma rede de 10.000 peers e k = 20, o ataque exige algo como ~160 peer IDs adversariais estrategicamente posicionados. A DHT de Aevia usa adicionalmente refresh de bucket com probing aleatório, o que previne eclipse permanente; um bucket refrescado incluirá novos peers honestos à medida que entrarem. O ataque é caro e transitório.

(e) Ataque econômico ao Persistence Pool. Um adversário que controla grande fração dos fluxos de compensação do pool pode rebaixar a taxa por epoch de operadores honestos. Não alegamos defesa provavelmente segura. A defesa empírica do protocolo é pluralismo: o contrato do pool é público, o comportamento adversarial é auditável, e um ataque persistente dispara revisão do Conselho (§8). Se um adversário captura o pool, o Conselho pode propor um fork do contrato de compensação que exclua o adversário; a estrutura de veto do Conselho torna essa uma ação possível mas deliberadamente não trivial.

Um light client — um viewer que não mantém um índice completo do Content Registry — pode verificar a validade e a vigência de um manifesto com um pequeno número de requisições de rede.

Dado um manifesto M alegadamente corrente para o criador de endereço c no tempo t:

1. Computar o hash canônico h = H(canonical(M \ signature)).
2. Consultar o Content Registry: registeredAt, registeredCreator = Registry.lookup(h).
3. Verificar registeredCreator == c.
4. Verificar registeredAt ≤ t.
5. Verificar assinatura EIP-712: recover(M.signature, h) == c.
6. Verificar cada CID referenciado: buscar o conteúdo, computar seu CID e comparar ao alegado pelo manifesto.

Uma verificação completa exige uma chamada de contrato (passo 2), uma recuperação de assinatura (passo 5) e um hash-check por CID referenciado (passo 6). Para um manifesto de vídeo típico com 342 segmentos HLS, isso são 342 hashes de conteúdo, um hash de manifesto e uma recuperação de assinatura — aproximadamente 50 ms em hardware de consumidor.

O light client não precisa confiar em nenhum servidor ou gateway. Um gateway malicioso só consegue fazer a verificação falhar (servindo conteúdo errado); não consegue fazer com que um manifesto errado seja aceito.

O Persistence Pool opera sob princípio de conservação: em qualquer epoch, a compensação total paga é igual ao desembolso total do saldo do pool. O pool é reabastecido por uma fração dos fluxos de crédito direcionados pelo criador (o credit pulse) e, durante o bootstrap, diretamente pela Aevia LLC.

Seja S(t) o saldo do pool na epoch t, I(t) a fração de credit pulse entrante e O(t) o desembolso. O saldo evolui como:

Para um equilíbrio estacionário S*, exigimos O(t) = I(t), dando S* = I / ε.

Isso tem uma consequência útil. A taxa por epoch ρ(t) é ε · S(t) / Σ_i (R_i · B_i · W_region). No equilíbrio,

A taxa escala linearmente com o fluxo de crédito de criadores e inversamente com volume replicado. À medida que mais criadores enviam crédito pelo pulse, as taxas sobem; à medida que mais provider nodes entram, as taxas caem. O mercado se auto-equilibra.

Break-even para um provider node depende do custo operacional por byte-hora e de R · B · W esperado. Considere um nó em região de alto peso (W = 1.5) com 99% de uptime (R = 0.99), detendo 10 TB por um mês (B ≈ 7.2 · 10^15 byte-horas). O nó ganha 0.99 · 7.2·10^15 · 1.5 · ρ cUSDC. Com ρ ajustado de modo que a taxa de estado estacionário produza aproximadamente $5 por TB-mês para regiões de alto peso, o nó ganha aproximadamente $75/mês pelos 10 TB. Custo operacional para os mesmos 10 TB em infraestrutura de consumidor — eletricidade, banda, amortização de hardware — é tipicamente $15–30/mês. A margem é real mas modesta.

O modelo não depende de valorização especulativa. A compensação é denominada em uma stablecoin atrelada ao dólar; o retorno de um provider é determinado pelo desempenho de replicação, não por movimento de preço de token. Isso é um contraste intencional com designs que dependem da valorização de token nativo para fechar o loop econômico.

Aevia bebe de vários sistemas anteriores, cada um resolvendo um subconjunto do problema.

IPFS [3] introduziu armazenamento content-addressed e a DHT Kademlia para retrieval descentralizado. IPFS não especifica incentivo econômico para persistência; o conteúdo desaparece quando o último nó pinning o larga.

Filecoin [4] construiu uma camada econômica sobre IPFS, usando proof-of-spacetime e proof-of-replication para compensar mineradores de storage. O design do Filecoin mira em arquivamento frio: deals são tipicamente de 6–12 meses com setores grandes e alta latência de retrieval. A camada de persistência de Aevia é de horizonte mais curto e retrieval-first, e opera em Base, não em uma chain dedicada.

Arweave [5] usa modelo diferente: um pagamento único perpétuo em um endowment que capitaliza e financia replicação indefinida. Arweave é otimizado para arquivamento permanente, aceita custo up-front maior e não separa persistência de distribuição.

Livepeer [10] trata de um problema diferente — transcoding em escala — usando estrutura similar de provider node e pagamento, mas focado em processamento de vídeo, não em storage.

LBRY/Odysee, PeerTube e Rumble tratam de distribuição de vídeo sem garantia em nível de protocolo de persistência: seu conteúdo pode ser desplataformado pelo operador da instância federada ou do serviço centralizado. A camada de persistência de Aevia pretende sobreviver a qualquer cliente individual.

BitTorrent demonstrou que replicação distribuída é viável em escala quando alinhada com incentivo de usuário. Aevia generaliza o padrão tornando o incentivo explícito (compensação em cUSDC) em vez de implícito (tit-for-tat choking).

O que Aevia contribui sobre esses é o princípio da separação: persistência e distribuição como camadas econômicas e de governança distintas. O Content Registry ancora persistência; o Risk Score e o Conselho governam distribuição. Sistemas existentes ou colapsam as duas (plataformas de vídeo mainstream) ou tratam apenas de uma (protocolos puros de storage).

Descrevemos um protocolo em que o conteúdo de um criador persiste em uma rede de replicadores economicamente compensados, indexado por um registry on-chain público e assinado com uma identidade criptográfica verificável. Distribuição — ranking, surface de feed, subsídio — é governada por um risk score público e contestável e por um Conselho Ecumênico de doze assentos.

A arquitetura assume uma posição: persistência é infraestrutura e deve ser neutra; distribuição é editorial e deve ser honesta. Não alegamos neutralidade sobre o que recomendamos. Alegamos que a existência continuada do trabalho de um criador não é, e não deve ser, condicional à nossa recomendação.

O protocolo é open-source: Apache-2.0 para os contratos e a especificação; AGPL-3.0 para clientes de referência; MIT para o design system compartilhado. O endereço do Content Registry em Base é público. As deliberações do Conselho estão no Trust Ledger público. Cada afirmação neste paper é verificável no código.