rfc-8 · economic architecture

arquitetura econômica

versão 0.1 · atualizado 2026-04-18 · status: publicado


abstract

Arquitetura Econômica

Especifica a arquitetura econômica do protocolo Aevia: quais tesourarias custodiam cUSDC, quem controla cada uma, como fundos movem entre elas, e quais invariantes MUST valer o tempo todo. É a terceira perna do tripé de três documentos que sustenta a postura não-é-oferta-de-securities; as outras duas são RFC-4 (AUP) e RFC-5 (Persistence Pool).

O commitment central de design é que o Persistence Pool é não-discricionário. Aevia LLC pré-funda durante bootstrap e daí em diante não tem claim sobre o saldo; desembolsos são programáticos por RFC-5. Essa é a instanciação técnica do princípio da separação na camada econômica: persistência de conteúdo é um bem público financiado por flows de criadores e operado pelo protocolo; serviços editoriais são bem privado vendido pela Aevia LLC por fee. Colapsar os dois destruiria tanto a Howey defense quanto o incentivo de Provider Nodes pra tratar Pool commitments como críveis.

Toda compensação é denominada em cUSDC em Base L2. Não existe token nativo. Nenhuma tesouraria detém asset especulativo. Isso é deliberado: asset volátil distorceria orçamento de criador, economia operacional de Provider Node, e incentivos de governança do Conselho, e colapsaria a Howey defense que /providers e RFC-5 dependem.

§3

4 tesourarias

  1. PersistencePool — exclusivo do protocolo. Inflow: bootstrap LLC (one-way), Credit Pulse. Outflow: Provider Node payouts via settlement (RFC-5). LLC MUST NOT withdraw.
  2. LLCTreasury — Gnosis Safe 2-of-3, controle 100% Aevia LLC. Inflow: relayer fees, aggregator fees, aevia.video take-rate, boost LLC share, enterprise. Outflow: folha, infra, operacional.
  3. CreatorEscrow — non-custodial intra-tx splitter. MUST NOT hold balance entre transações. Roteia tips/subs/boosts pro creator wallet + LLC take + pool fraction, tudo atômico.
  4. CouncilFund — Gnosis Safe council-only, ≥7-de-12 signers. Inflow: 1% de cada boost + bootstrap LLC. Outflow: stipends de conselheiros, auditorias, publicação do trust ledger. LLC MUST NOT withdraw.

A matriz de transferência on-chain está em §3.6 — cada fluxo permitido enumerado; qualquer transferência fora da matriz é bright-line violation.

§4

boost router

Splitter contract não-custodial que recebe cUSDC pra amplificar um conteúdo específico e divide atomicamente em quatro recipients. É o principal Credit Pulse inflow pro Pool em steady state.

Split default (governável pelo Conselho):

  • creator: 5 000 bps (50%)
  • pool: 3 000 bps (30%)
  • llc: 1 900 bps (19%)
  • council: 100 bps (1%)

Gate obrigatório (MUST): boost MUST revertar se R(c) ≥ θ_feed (RFC-6). Conteúdo que a AUP exclui do feed MUST NOT receber amplificação paga. Esse é o ponto de instanciação arquitetural da AUP na camada de amplificação.

function boost(bytes32 manifestHash, uint256 amount) external;
§7

invariantes (bright lines)

12 invariantes MUST. Enforçados em contrato quando possível, em política de multisig quando não. Os mais críticos:

  • INV-1/2: LLC MUST NOT withdraw do Persistence Pool; bootstrap é one-way, sem clawback.
  • INV-3/4: LLC MUST NOT withdraw do CouncilFund; parâmetros council-governable MUST NOT ser LLC-unilateral.
  • INV-5/6: CreatorEscrow e BoostRouter MUST NOT hold balance entre transações.
  • INV-7/8: tesourarias MUST holdar apenas cUSDC; protocolo MUST NOT emitir token nativo.
  • INV-9: toda transferência MUST emitir evento auditável on-chain.
  • INV-10: aggregator settlement MUST ter janela de contestação ≥72h antes de fundos serem claimable.
  • INV-11: BoostRouter MUST gate em R(c) < θ_feed.
  • INV-12: R(c) ≥ θ_subsidy MUST NOT gerar Credit Pulse inflow pro Pool.
fonte canônica

Esta página renderiza um resumo do RFC-8. O texto normativo completo (1043 linhas com BoostRouter Solidity interface completa, matriz de transferência detalhada, todos os 6 operator fees enumerados, security considerations cobrindo aggregator capture / boost spam / governance capture / Howey reinterpretation / take-rate races, implementation reference com event signatures + bootstrap sequence) está em:

docs/protocol-spec/8-economic-architecture.md →
rfc-8 · economic architecture · aevia.network · aevia.network