# Vantemio Donations: produto e documentação técnica

Revisão 2026-10-16 · Em desenvolvimento · Implementação de testnet

## 1. Objetivo e estado

Vantemio Donations conecta perfis de criadores, apoio da audiência e alertas de transmissão. É um fluxo separado das [compras no Market](market.md): apoio não cria pedido de produto nem voucher Boson. Distribuição de vídeo é função de mídia separada; transações da blockchain não transportam o vídeo ao vivo.

O código inspecionado destina-se apenas à Base Sepolia e inclui perfis, intenções de pagamento, verificação de recibos, registros de liquidação e caixa de saída de alertas. Código e testes isolados não comprovam serviço público operacional, persistência de produção, canal conectado, auditoria independente ou mainnet. As [regras](donations-policy.md) e o [roteiro](donations-roadmap.md) descrevem o aceite pendente.

Software Vantemio, assinaturas quando oferecidas, serviços pagos e doações usam pagamentos em criptomoedas. A oferta define redes e tokens suportados, valor, taxas e confirmação. Pagamentos fiduciários e conversão ou retirada integrada para moeda fiduciária ficam fora do produto; o câmbio externo do usuário é independente do Vantemio.

## 2. Participantes e responsabilidade

| Participante | Responsabilidade |
|---|---|
| Apoiador | Conferir criador, rede, ativo, valor e ação da carteira; preservar referência da transação. |
| Criador ou streamer | Controlar perfil autorizado, carteira receptora e apresentação; proteger canal e overlay. |
| Site e backend | Vincular intenção ao perfil vigente, verificar transferência, registrar liquidação e disponibilizar histórico e alertas permitidos. |
| Carteira e rede | Autorizar e executar a transação assinada na rede escolhida. |
| OBS e plataforma | Apresentar alertas permitidos e transmitir pelas próprias integrações. |

Station conserva a autoridade sobre trabalhos Studio admitidos separadamente. Apoio, conexão de canal ou token OBS não autorizam produção, publicação, gasto ou acesso a dados de outro criador.

## 3. Fluxo do apoiador

1. Abrir o perfil correto e conferir o destinatário. Nome do canal não comprova propriedade da carteira.
2. Obter intenção vigente, vinculada a identidade da solicitação, versão do perfil, apoiador, destinatário, ativo, valor, rede e nonce.
3. Conferir transação e custo de rede antes de assinar. O código admite ETH e USDC de testnet configurados; mudar uma legenda não ativa mainnet.
4. Preservar intenção original e hash após o envio. Janela de carteira, hash ou captura não constituem liquidação verificada.
5. Acompanhar verificação. Em caso de incerteza, conciliar o envio original antes de autorizar outro pagamento.

Perfil desatualizado pode gerar conflito e exigir nova intenção. Se a transação anterior já foi assinada ou enviada, investigá-la primeiro; a substituição não deve criar automaticamente uma segunda transferência.

## 4. Rede, ativos e contabilidade da taxa

A rede atual é Base Sepolia, `chainId 84532`. O contrato USDC configurado é `0x036CbD53842c5426634e7929541eC2318f3dCF7e`. São parâmetros de testnet. Base documenta o [identificador](https://docs.base.org/base-chain/api-reference/ethereum-json-rpc-api/eth_chainId); Circle publica o [endereço e estado dos tokens de teste](https://developers.circle.com/stablecoins/usdc-contract-addresses).

A alocação contábil usa unidades mínimas do ativo:

`platformFee = floor(total × 100 / 10000)`

`creatorAllocation = total − platformFee`

A alocação nominal da plataforma é 1%, arredondada para baixo. **A transação preparada atual transfere o total ao criador. Não envia outro 1% à plataforma nem recolhe uma divisão atômica 99/1 na cadeia.** Alocação contábil e movimentação real devem aparecer separadamente. Campo treasury não comprova pagamento à tesouraria. Custos de rede são distintos. Antes de pagamentos reais, mecanismo de cobrança, pagador e totais exibidos exigem especificação aceita e conciliada.

## 5. Configuração do criador e OBS

Fluxo previsto: autenticar como proprietário → conferir perfil receptor → conectar canal realmente compatível → obter acesso ao overlay limitado ao criador → testar em privado → ativar cena. Capacidade declarada ou URL OAuth não comprovam conexão concluída.

OBS admite página web como Browser Source. [OBS Browser Source](https://obsproject.com/kb/browser-source). Usar a URL fornecida pelo deployment aceito; não inventar URL de produção a partir de um caminho de API. O backend inclui tokens OBS revogáveis com validade. URL com token é credencial: não divulgar em transmissão, capturas ou repositórios públicos; substituir ou revogar acesso exposto.

Verificar pagamento, criar alerta, recuperá-lo e confirmar entrega são eventos separados. Confirmação não prova que alguém viu o alerta ao vivo. Recarregar cena não deve gerar outra liquidação. A API inspecionada não comprova voz automática, todas as conexões de plataforma ou visibilidade garantida.

## 6. Fronteiras do backend

| Família API existente | Função e limite |
|---|---|
| `/api/donations/config`, `/api/donations/platforms` | Configuração e capacidades declaradas, sem comprovar prontidão operacional. |
| `/api/donations/creator/profile` | Ler ou atualizar perfil versionado com controles de proprietário aplicáveis. |
| `/api/donations/intent` | Preparar descrição de pagamento do perfil vigente, sem assinar ou enviar. |
| `/api/donations/verify` | Obter evidências, verificar vínculo e entregar liquidação ao armazenamento selecionado. |
| `/api/donations/history`, `/api/donations/alerts` | Histórico autorizado ou alertas limitados. |
| `/api/donations/obs/token`, `/api/donations/obs/revoke`, `/api/donations/alerts/delivered` | Emitir/revogar acesso e confirmar entrega sob autorização aplicável. |

As rotas descrevem interfaces inspecionadas, não sua disponibilidade pública. A verificação usa duas visões RPC configuradas, com concordância e confirmações; a independência real exige verificação do deployment. O serviço usa memória por padrão se não receber armazenamento persistente. Durabilidade após reinício e atomicidade de liquidação/alerta precisam ser verificadas no consumidor persistente real.

## 7. Falhas e recuperação

Rejeitar redes e ativos não suportados, valores inválidos, campos alterados e versões ou destinatários incorretos. Confirmações insuficientes, divergência RPC, fornecedores indisponíveis e resultado desconhecido devem permanecer explícitos. Versão/destinatário podem retornar `409`; sem RPC configurado, a verificação pode ficar indisponível.

A identidade da liquidação vincula rede e hash. A recuperação preserva solicitação e intenção originais e concilia recibo, registro e alerta antes de repetir. Reorganização deve preservar registro anterior e correção. Transferência, contabilidade local, acesso ao overlay e apresentação não se reduzem a um único sucesso.

## 8. Aceite da versão

Exige-se percurso real site/backend/armazenamento persistente/dois RPC e teste OBS privado: vínculo correto; rejeição de destinatário alheio e perfil antigo; reinício; duplicatas de transação e alerta; token revogado ou vencido; isolamento de histórico; falha RPC e reorganização; igualdade entre fontes, HTML, downloads e repositório em cinco idiomas. Fixtures e armazenamento isolado apoiam a verificação, sem comprovar prontidão operacional.

## 9. Base e documentos relacionados

Inspecionado em 16 de outubro de 2026: `stream-donations.mjs` SHA-256 `6f60190b4d230fe5c4a1e00532661686af15f824b635246ef32490c402ea664c`; `stream-settlement.mjs` `13f1f99d32af189d9193f1e9b7a3a52c600c04b23bb443b4df9f6b060bf1d246`; API `donations.mjs` `7a7ae513078dbdaae19971bbd67ebbd85a55798f5ad26980d751004ddefb6cf7`. Identificam bytes examinados, não aceite de um deployment.

[Regras Donations](donations-policy.md) · [Roteiro Donations](donations-roadmap.md) · [Privacidade](privacy.md) · [Termos](terms.md) · [Documentação técnica](technical.md)