arquitetura econômica
versão 0.1 · atualizado 2026-04-18 · status: publicado
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.
4 tesourarias
- PersistencePool — exclusivo do protocolo. Inflow: bootstrap LLC (one-way), Credit Pulse. Outflow: Provider Node payouts via settlement (RFC-5). LLC MUST NOT withdraw.
- 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.
- 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.
- 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.
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;
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.
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 →