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: 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 e o roteiro 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
- Abrir o perfil correto e conferir o destinatário. Nome do canal não comprova propriedade da carteira.
- Obter intenção vigente, vinculada a identidade da solicitação, versão do perfil, apoiador, destinatário, ativo, valor, rede e nonce.
- 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.
- Preservar intenção original e hash após o envio. Janela de carteira, hash ou captura não constituem liquidação verificada.
- 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; Circle publica o endereço e estado dos tokens de teste.
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. 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 · Roteiro Donations · Privacidade · Termos · Documentação técnica