Vantemio Donations : produit et documentation technique
Révision 2026-10-16 · En développement · Implémentation sur réseau de test
1. Objet et état
Vantemio Donations relie profils de créateurs, soutien du public et alertes de diffusion. Ce parcours est distinct des achats Market : le soutien ne crée ni commande de produit ni voucher Boson. La distribution vidéo est une fonction média séparée ; la blockchain ne transporte pas la vidéo en direct.
Le code inspecté cible uniquement Base Sepolia : profils, intentions de paiement, vérification des reçus, registres de règlement et file d’alertes. Code et contrôles isolés ne démontrent ni service public opérationnel, ni persistance de production, ni chaîne connectée, ni audit indépendant, ni mainnet. Les règles et la feuille de route précisent la réception restante.
Les logiciels Vantemio, les abonnements lorsqu’ils sont proposés, les services payants et les dons se paient en cryptomonnaies. L’offre précise réseaux et jetons pris en charge, montant, frais et confirmation. Les paiements en monnaie fiduciaire ainsi que la conversion ou le retrait intégré en monnaie fiduciaire sortent du périmètre du produit ; le change externe de l’utilisateur est indépendant de Vantemio.
2. Participants et responsabilités
| Participant | Responsabilité |
|---|---|
| Donateur | Vérifier créateur, réseau, actif, montant et action du portefeuille ; conserver la référence. |
| Créateur ou streamer | Contrôler profil autorisé, portefeuille destinataire et présentation ; protéger chaîne et overlay. |
| Site et backend | Lier l’intention au profil actuel, vérifier la transaction, consigner le règlement et fournir historique et alertes autorisés. |
| Portefeuille et réseau | Autoriser et exécuter la transaction signée sur la chaîne choisie. |
| OBS et plateforme | Présenter les alertes permises et transmettre le programme par leurs intégrations. |
Station garde l’autorité sur les tâches Studio admises séparément. Don, connexion de chaîne ou token OBS n’autorisent ni production, ni publication, ni dépense, ni accès aux données d’un autre créateur.
3. Parcours du donateur
- Ouvrir le bon profil et vérifier le destinataire. Le nom de chaîne ne prouve pas la propriété du portefeuille.
- Obtenir l’intention actuelle, liée à l’identité de demande, version du profil, donateur, destinataire, actif, montant, réseau et nonce.
- Vérifier transaction et frais réseau avant signature. Le code accepte ETH et USDC de test configurés ; changer une étiquette n’active pas mainnet.
- Conserver intention d’origine et empreinte de transaction après envoi. Fenêtre de portefeuille, empreinte ou capture ne constituent pas un règlement vérifié.
- Suivre la vérification. En cas d’incertitude, rapprocher le transfert initial avant d’autoriser un autre paiement.
Un profil périmé peut provoquer un conflit nécessitant une nouvelle intention. Si la transaction précédente est déjà signée ou envoyée, l’examiner d’abord ; une intention de remplacement ne doit pas déclencher automatiquement un second transfert.
4. Réseau, actifs et comptabilisation des frais
Le réseau actuel est Base Sepolia, chainId 84532. Le contrat USDC configuré est 0x036CbD53842c5426634e7929541eC2318f3dCF7e. Ce sont des paramètres de test. Base documente l’identifiant ; Circle publie l’adresse et le statut des tokens de test.
L’allocation comptable utilise les unités minimales de l’actif :
platformFee = floor(total × 100 / 10000)
creatorAllocation = total − platformFee
L’allocation nominale de la plateforme est de 1 %, arrondie vers le bas. La transaction préparée actuelle transfère le total au créateur. Elle n’envoie pas séparément 1 % à la plateforme et ne collecte pas une répartition atomique 99/1 en chaîne. Allocation comptable et mouvements réels doivent être présentés séparément. Un champ treasury ne prouve pas un paiement à la trésorerie. Les frais réseau sont distincts. Avant les paiements réels, collecte, payeur et totaux affichés exigent une spécification acceptée et rapprochée.
5. Configuration du créateur et OBS
Parcours prévu : authentification du propriétaire → vérification du profil destinataire → connexion d’une chaîne réellement prise en charge → accès overlay limité au créateur → essai privé → activation de scène. Une capacité déclarée ou URL OAuth ne démontre pas une connexion achevée.
OBS permet une page web en Browser Source. OBS Browser Source. Utiliser l’URL fournie par le déploiement accepté, sans inventer d’URL de production à partir d’un chemin d’API. Le backend comprend des tokens OBS révocables avec expiration. Une URL contenant un token est un identifiant secret : ne pas l’exposer en direct, dans des captures ou dépôts publics ; remplacer ou révoquer l’accès divulgué.
Vérification du paiement, création d’alerte, récupération et accusé de livraison sont distincts. L’accusé ne prouve pas qu’une personne a vu l’alerte en direct. Recharger une scène ne doit pas créer un second règlement. L’API inspectée ne démontre ni voix automatique, ni connexion à toutes les plateformes, ni visibilité garantie.
6. Frontières du backend
| Famille API existante | Fonction et limite |
|---|---|
/api/donations/config, /api/donations/platforms | Configuration et capacités déclarées, sans preuve de disponibilité opérationnelle. |
/api/donations/creator/profile | Lecture ou mise à jour du profil versionné avec contrôles de propriétaire applicables. |
/api/donations/intent | Préparation du paiement du profil actuel, sans signature ni diffusion. |
/api/donations/verify | Obtention des preuves, vérification du lien et transmission au stockage sélectionné. |
/api/donations/history, /api/donations/alerts | Historique autorisé ou alertes limitées. |
/api/donations/obs/token, /api/donations/obs/revoke, /api/donations/alerts/delivered | Émission/révocation d’accès et accusé de livraison sous autorisation applicable. |
Ces routes décrivent le backend inspecté, pas leur disponibilité publique. Deux vues RPC configurées sont utilisées avec contrôles d’accord et confirmations ; leur indépendance réelle doit être établie pour le déploiement. Le service utilise la mémoire par défaut sans stockage persistant fourni. Durabilité après redémarrage et atomicité règlement/alerte doivent être vérifiées sur le consommateur persistant réel.
7. Échecs et reprise
Rejeter réseaux et actifs non pris en charge, montants invalides, champs altérés, versions ou destinataires incorrects. Confirmations insuffisantes, désaccord RPC, fournisseurs indisponibles et issue inconnue restent explicites. Version/destinataire peuvent renvoyer 409 ; sans configuration RPC, la vérification peut être indisponible.
L’identité du règlement lie réseau et empreinte de transaction. La reprise conserve demande et intention d’origine et rapproche reçu, registre et alerte avant répétition. Une réorganisation doit conserver l’ancienne trace et sa correction. Transfert, comptabilité locale, accès overlay et présentation ne se réduisent pas à un unique succès.
8. Réception de la version
Il faut le parcours réel site/backend/stockage persistant/deux RPC et un essai OBS privé : lien correct ; rejet d’un mauvais destinataire et profil périmé ; redémarrage ; doublons de transaction et d’alerte ; token révoqué ou expiré ; isolation d’historique ; panne RPC et réorganisation ; correspondance sources, HTML, téléchargements et dépôt dans les cinq langues. Fixtures et stockage isolé soutiennent la vérification sans prouver la disponibilité réelle.
9. Base et documents associés
Inspection du 16 octobre 2026 : stream-donations.mjs SHA-256 6f60190b4d230fe5c4a1e00532661686af15f824b635246ef32490c402ea664c ; stream-settlement.mjs 13f1f99d32af189d9193f1e9b7a3a52c600c04b23bb443b4df9f6b060bf1d246 ; API donations.mjs 7a7ae513078dbdaae19971bbd67ebbd85a55798f5ad26980d751004ddefb6cf7. Ces valeurs identifient les octets examinés, pas la réception d’un déploiement.
Règles Donations · Feuille de route Donations · Confidentialité · Conditions · Documentation technique