# Vantemio Donations: producto y documentación técnica

Revisión 2026-10-16 · En desarrollo · Implementación de testnet

## 1. Propósito y estado

Vantemio Donations conecta perfiles de creadores, apoyo de la audiencia y alertas de transmisión. Es un proceso separado de las [compras en Market](market.md): el apoyo no crea un pedido ni un voucher Boson. La distribución de vídeo es una función multimedia independiente; la cadena no transmite el directo.

El código inspeccionado apunta solo a Base Sepolia e incluye perfiles, intenciones de pago, verificación de recibos, registros de liquidación y una bandeja de alertas. Código y pruebas aisladas no demuestran servicio público operativo, persistencia de producción, canal conectado, auditoría independiente ni mainnet. Las [reglas](donations-policy.md) y la [hoja de ruta](donations-roadmap.md) establecen la aceptación pendiente.

El software Vantemio, las suscripciones cuando se ofrezcan, los servicios de pago y las donaciones se pagan en criptomonedas. La oferta especifica redes y tokens compatibles, importe, comisiones y confirmación. Los pagos fiduciarios y la conversión o retirada integrada a moneda fiduciaria quedan fuera del producto; el cambio externo del usuario es independiente de Vantemio.

## 2. Participantes y responsabilidad

| Participante | Responsabilidad |
|---|---|
| Donante | Revisar creador, red, activo, importe y acción de wallet; conservar la referencia. |
| Creador o streamer | Controlar perfil autorizado, wallet receptora y presentación; proteger canal y overlay. |
| Sitio y backend | Vincular intención al perfil vigente, verificar transferencia, registrar liquidación y entregar historial y alertas permitidos. |
| Wallet y red | Autorizar y ejecutar la transacción firmada en la cadena elegida. |
| OBS y plataforma | Mostrar alertas permitidas y transmitir mediante sus propias integraciones. |

Station conserva la autoridad sobre trabajos Studio admitidos por separado. Una donación, conexión de canal o token OBS no autoriza producción, publicación, gasto ni acceso a datos ajenos.

## 3. Flujo del donante

1. Abrir el perfil correcto y comprobar al receptor. El nombre del canal no prueba propiedad de la wallet.
2. Obtener la intención vigente, vinculada a identidad de solicitud, versión del perfil, donante, receptor, activo, importe, red y nonce.
3. Revisar transacción y coste de red antes de firmar. El código admite ETH de testnet y USDC de testnet configurado; cambiar una etiqueta no habilita mainnet.
4. Conservar intención original y hash después del envío. Una ventana de wallet, hash o captura no constituye liquidación verificada.
5. Seguir la verificación. Ante incertidumbre, conciliar el envío original antes de autorizar otro pago.

Un perfil desactualizado puede producir conflicto y exigir otra intención. Si la transacción anterior ya fue firmada o enviada, se investiga primero; la intención nueva no debe generar automáticamente una segunda transferencia.

## 4. Red, activos y contabilidad de comisión

La red actual es Base Sepolia, `chainId 84532`. El contrato USDC configurado es `0x036CbD53842c5426634e7929541eC2318f3dCF7e`. Son parámetros de testnet. Base documenta el [identificador](https://docs.base.org/base-chain/api-reference/ethereum-json-rpc-api/eth_chainId); Circle publica la [dirección y condición de tokens de prueba](https://developers.circle.com/stablecoins/usdc-contract-addresses).

La asignación contable se calcula en unidades mínimas:

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

`creatorAllocation = total − platformFee`

La asignación nominal de plataforma es 1%, redondeada hacia abajo. **La transacción preparada actual envía el total al creador. No envía otro 1% a la plataforma ni recauda una división 99/1 atómica en cadena.** La asignación contable y el movimiento real deben mostrarse por separado. Un campo treasury no prueba un pago a tesorería. Los costes de red son distintos. Antes de pagos reales deben aceptarse y conciliarse recaudación, pagador y totales mostrados.

## 5. Configuración del creador y OBS

Flujo previsto: autenticarse como propietario → comprobar perfil receptor → conectar un canal realmente compatible → obtener acceso al overlay limitado al creador → probar en privado → activar la escena. Una capacidad declarada o URL OAuth no demuestra conexión completada.

OBS admite una página web como Browser Source. [OBS Browser Source](https://obsproject.com/kb/browser-source). Usar la URL suministrada por el despliegue aceptado; no inventarla a partir de una ruta de API. El backend incluye tokens OBS revocables y con caducidad. Una URL con token es una credencial: no debe aparecer en directo, capturas o repositorios públicos; el acceso expuesto se sustituye o revoca.

Verificar pago, crear alerta, recuperarla y confirmar entrega son eventos distintos. La confirmación no prueba que una persona viera la alerta en directo. Recargar una escena no debe producir otra liquidación. La interfaz inspeccionada no demuestra voz automática, conexión a todas las plataformas ni visibilidad garantizada.

## 6. Límites del backend

| Familia API existente | Función y límite |
|---|---|
| `/api/donations/config`, `/api/donations/platforms` | Configuración y capacidades declaradas, sin demostrar disponibilidad operativa. |
| `/api/donations/creator/profile` | Leer o actualizar perfil versionado con controles de propietario aplicables. |
| `/api/donations/intent` | Preparar pago del perfil vigente, sin firmar ni enviar. |
| `/api/donations/verify` | Obtener pruebas, verificar vinculación y entregar liquidación al almacén seleccionado. |
| `/api/donations/history`, `/api/donations/alerts` | Historial autorizado o alertas acotadas. |
| `/api/donations/obs/token`, `/api/donations/obs/revoke`, `/api/donations/alerts/delivered` | Emitir/revocar acceso y confirmar entrega bajo autorización aplicable. |

Las rutas describen interfaces inspeccionadas, no su disponibilidad pública. Se usan dos vistas RPC configuradas con comprobaciones de concordancia y confirmación; su independencia real requiere verificación del despliegue. El servicio usa memoria por defecto si no recibe un almacén persistente. La durabilidad tras reinicios y atomicidad de liquidación/alerta deben verificarse en el consumidor persistente real.

## 7. Fallos y recuperación

Se rechazan redes y activos no admitidos, importes inválidos, campos modificados y versiones o receptores incorrectos. Confirmaciones insuficientes, desacuerdo RPC, proveedores caídos y resultado desconocido deben seguir explícitos. Versión/receptor pueden devolver `409`; sin RPC configurado, la verificación puede no estar disponible.

La identidad de liquidación vincula red y hash. La recuperación conserva solicitud e intención originales y concilia recibo, registro y alerta antes de repetir. Una reorganización debe conservar registro anterior y corrección. Transferencia, contabilidad local, acceso al overlay y presentación no se reducen a un único éxito.

## 8. Aceptación de la versión

Se requiere el recorrido real sitio/backend/almacén persistente/dos RPC y prueba OBS privada: vinculación correcta; rechazo de receptor ajeno y perfil antiguo; reinicio; duplicados de transacción y alerta; token revocado o caducado; aislamiento de historial; fallo RPC y reorganización; igualdad entre fuentes, HTML, descargas y repositorio en cinco idiomas. Fixtures y almacenes aislados apoyan la verificación, sin probar disponibilidad real.

## 9. Base y documentos relacionados

Inspección del 16 de octubre de 2026: `stream-donations.mjs` SHA-256 `6f60190b4d230fe5c4a1e00532661686af15f824b635246ef32490c402ea664c`; `stream-settlement.mjs` `13f1f99d32af189d9193f1e9b7a3a52c600c04b23bb443b4df9f6b060bf1d246`; API `donations.mjs` `7a7ae513078dbdaae19971bbd67ebbd85a55798f5ad26980d751004ddefb6cf7`. Identifican bytes examinados, no aceptación de un despliegue.

[Reglas Donations](donations-policy.md) · [Hoja de ruta Donations](donations-roadmap.md) · [Privacidad](privacy.md) · [Condiciones](terms.md) · [Documentación técnica](technical.md)