# Vantemio Donations: Produkt- und technische Dokumentation

Revision 2026-10-16 · In Entwicklung · Testnet-Implementierung

## 1. Zweck und Status

Vantemio Donations verbindet Creator-Profile, Unterstützung durch das Publikum und Stream-Alerts. Dies ist ein separater Produktfluss von [Market-Käufen](market.md): Ein Support-Transfer erzeugt keine Produktbestellung und keinen Boson-Voucher. Die Videoverteilung ist eine separate Medienfunktion; Blockchain-Transaktionen transportieren keinen Live-Videostream.

Der geprüfte Code zielt ausschließlich auf Base Sepolia, mit Creator-Profilen, vorbereiteten Payment-Intents, Belegverifizierung, Settlement-Datensätzen und einer Alert-Outbox. Quellimplementierung und isolierte Checks begründen keinen funktionierenden öffentlichen Zahlungsdienst, keine Produktionspersistenz, keine Live-Channel-Integration, kein unabhängiges Audit und keine Mainnet-Verfügbarkeit. Die [Produktregeln](donations-policy.md) und die [Roadmap](donations-roadmap.md) beschreiben die verbleibenden Abnahmegrenzen.

Vantemio-Software, Abonnements soweit angeboten, bezahlte Dienste und Spenden nutzen Kryptowährungszahlungen. Das Angebot spezifiziert unterstützte Netzwerke und Token, Betrag, Gebühren und Bestätigungsbedingungen. Fiat-Zahlungswege sowie integrierte Umwandlung oder Auszahlung in Fiat liegen außerhalb dieses Produkts; ein externer Umtausch des Nutzers ist unabhängig von Vantemio.

## 2. Teilnehmer und Verantwortung

| Teilnehmer | Verantwortung |
|---|---|
| Spender | Creator, Netzwerk, Asset, Betrag und Wallet-Aktion prüfen; Transaktionsreferenz aufbewahren. |
| Creator oder Streamer | Autorisiertes Profil, Auszahlungs-Wallet und Stream-Präsentation kontrollieren; Kanal- und Overlay-Zugang schützen. |
| Website und Backend | Intent an aktuelles Profil binden, Transaktionsnachweise verifizieren, Settlement aufzeichnen und zulässige Alerts/Historie bereitstellen. |
| Wallet und Netzwerk | Die signierte Transaktion gemäß ausgewählter Chain autorisieren und ausführen. |
| OBS und Kanalplattform | Zulässigen Alert präsentieren und das Programm über eigene Integrationen übertragen. |

Station bleibt die Autorität für separat zugelassene Studio-Arbeiten. Eine Spende, Kanalverbindung oder ein OBS-Token autorisiert keinen neuen Produktionsjob, keine Veröffentlichung, keine Wallet-Ausgabe und keinen Zugriff auf Daten eines anderen Creators.

## 3. Spender-Workflow

1. Gewünschtes Creator-Profil öffnen und dessen Auszahlungsidentität prüfen. Ein Kanal-Anzeigename allein ist kein Nachweis für Wallet-Eigentum.
2. Aktuellen Payment-Intent einholen. Er bindet Request-Identität, Profilversion, Spender, Empfänger, Asset, Betrag, Netzwerk und Nonce.
3. Wallet-Transaktion und Netzwerkkosten vor der Signierung prüfen. Die aktuelle Implementierung akzeptiert Testnet-ETH und das konfigurierte Testnet-USDC; sie aktiviert Mainnet nicht durch Änderung eines Seitenlabels.
4. Ursprünglichen Intent und Transaktions-Hash nach Einreichung aufbewahren. Ein Wallet-Prompt, Hash oder Screenshot allein ist kein verifiziertes Settlement.
5. Verifizierungsstatus verfolgen. Bei ungewissem Ausgang ursprünglichen Transfer vor Autorisierung einer weiteren Zahlung abgleichen.

Ein veraltetes Creator-Profil kann eine Konfliktantwort auslösen, die einen neuen Intent erfordert. Wurde eine frühere Transaktion bereits signiert oder gesendet, ist zuerst diese Transaktion zu untersuchen; ein Ersatz-Intent darf nicht automatisch zu einem zweiten Transfer werden.

## 4. Netzwerk, Assets und Gebührenabrechnung

Das aktuelle Netzwerk ist Base Sepolia, `chainId 84532`. Der konfigurierte USDC-Vertrag ist `0x036CbD53842c5426634e7929541eC2318f3dCF7e`. Dies sind Testnet-Einstellungen. Base dokumentiert den [Chain-Identifier](https://docs.base.org/base-chain/api-reference/ethereum-json-rpc-api/eth_chainId); Circle listet die [USDC-Testnet-Adresse und den Test-Token-Status](https://developers.circle.com/stablecoins/usdc-contract-addresses).

Die Quelle berechnet die Ledger-Allokation in den kleinsten Einheiten des Assets:

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

`creatorAllocation = total − platformFee`

Dies ist eine nominale 1-%-Plattform-Allokation mit Abrundung auf ganze Einheiten. **Die aktuell vorbereitete On-Chain-Transaktion überträgt den vollen Gesamtbetrag an den Creator. Sie sendet keinen separaten 1-%-Anteil an die Plattform und zieht keinen 99/1-Split atomar on-chain ein.** Buchhalterische Allokation und tatsächliche Token-Bewegung müssen getrennt ausgewiesen werden. Ein gespeichertes Treasury-Feld ist kein Nachweis einer Treasury-Zahlung. Netzwerkgebühren sind von dieser Allokation getrennt. Vor einem echten Zahlungsstart erfordern Einzugsmechanismus, Zahler und angezeigte Summen eine akzeptierte, abgeglichene Spezifikation.

## 5. Creator-Setup und OBS

Das vorgesehene Setup lautet: Als Profilinhaber authentifizieren → Auszahlungsprofil verifizieren → tatsächlich unterstützten Kanal verbinden → Creator-scoped Overlay-Zugang erhalten → Präsentation privat testen → vorgesehene Szene aktivieren. Eine Fähigkeit in einer Plattformliste oder eine OAuth-URL begründet keine abgeschlossene Kanalverbindung.

OBS unterstützt eine Webseite als Browser Source. [OBS Browser Source](https://obsproject.com/kb/browser-source). Verwenden Sie die Overlay-URL der abgenommenen Bereitstellung; erfinden Sie keine Produktions-URL aus einem API-Pfad. Das aktuelle Backend umfasst ablaufende, widerrufbare OBS-Tokens. Behandeln Sie eine Overlay-URL, die ein Token enthält, als Credential: Halten Sie sie aus Broadcasts, Screenshots und öffentlichen Repositories fern; ersetzen oder widerrufen Sie offengelegten Zugang.

Zahlungsverifizierung, Alert-Erstellung, Alert-Abruf und Zustellbestätigung sind unterschiedliche Events. Eine Bestätigung beweist nicht, dass eine Person den Alert im Livestream gesehen hat. Das Neuladen einer Szene darf kein zweites Settlement erzeugen. Automatische Sprachausgabe, jede Plattformverbindung und garantierte Live-Sichtbarkeit werden durch die geprüfte Alert-API nicht begründet.

## 6. Backend-Grenzen

| Bestehende API-Familie | Funktion und Grenze |
|---|---|
| `/api/donations/config`, `/api/donations/platforms` | Beschreiben konfigurierte Zahlungseinstellungen und deklarierte Plattformfähigkeiten; kein Nachweis für operative Bereitschaft. |
| `/api/donations/creator/profile` | Liest oder aktualisiert das versionierte Creator-Profil mit zutreffenden Owner-Prüfungen. |
| `/api/donations/intent` | Bereitet die aktuelle Profil-Zahlungsbeschreibung vor; signiert oder broadcastet nicht. |
| `/api/donations/verify` | Ruft Transaktionsnachweise ab, verifiziert Bindung und reicht Settlement beim ausgewählten Store ein. |
| `/api/donations/history`, `/api/donations/alerts` | Liefert autorisierte Creator-Historie oder scoped Alerts. |
| `/api/donations/obs/token`, `/api/donations/obs/revoke`, `/api/donations/alerts/delivered` | Stellt Overlay-Zugang aus/widerruft ihn und bestätigt Alert-Zustellung unter jeweiliger Autorisierung. |

Diese Pfade beschreiben geprüfte Backend-Schnittstellen, nicht das Versprechen, dass jeder Endpoint auf der öffentlichen Website exponiert ist. Die Verifizierung nutzt zwei konfigurierte RPC-Sichten mit Übereinstimmungs- und Bestätigungsprüfungen; tatsächliche Provider-Unabhängigkeit muss für das Deployment nachgewiesen werden. Der Default-Store im geprüften Service ist speicherbasiert, sofern kein persistenter Store bereitgestellt wird. Restart-Durability und Settlement/Outbox-Atomarität erfordern daher Verifizierung des tatsächlich gewählten persistenten Consumers.

## 7. Fehler und Wiederherstellung

Nicht unterstützte Netzwerke/Assets, ungültige Beträge, geänderte Zahlungsfelder sowie nicht übereinstimmende Creator-Versionen oder Empfänger ablehnen. Fehlende Bestätigungen, RPC-Unstimmigkeit, nicht verfügbare Provider und unbekannter Transaktionsausgang müssen explizit bleiben. Die aktuellen Versions-/Empfängerprüfungen können `409` zurückgeben; fehlende RPC-Konfiguration kann die Verifizierung unverfügbar machen.

Die Settlement-Identität bindet Chain und Transaktions-Hash. Die Wiederherstellung muss ursprüngliche Request-/Intent-Identität bewahren und Beleg, Ledger und Alert-Status vor erneuter Ausführung abgleichen. Reorganisationsbehandlung muss früheren Datensatz und dessen Korrektur bewahren. On-Chain-Transfer, lokale Buchhaltung, Overlay-Zugang und Stream-Präsentation dürfen niemals zu einem einzigen Success-Flag zusammengefasst werden.

## 8. Release-Abnahme

Die Abnahme erfordert den tatsächlichen Website/Backend/Persistent-Store/Dual-RPC-Pfad und einen privaten OBS-Test: korrekte Transfer-Bindung; Ablehnung bei falschem Empfänger und veraltetem Profil; Restart-Wiederherstellung; Duplikat-Transaktion und Alert-Behandlung; Ablehnung widerrufener/abgelaufener Tokens; Cross-Creator-Historie-Isolation; RPC-Fehler und Reorganisation; Source-zu-HTML/Download/Repository-Parität in allen fünf Sprachen. Test-Fixtures und ein isolierter Store sind unterstützende Nachweise, kein Beweis für Live-Bereitschaft.

## 9. Revisionsnachweise und zugehörige Dokumente

Geprüft am 16. Oktober 2026: `stream-donations.mjs` SHA-256 `6f60190b4d230fe5c4a1e00532661686af15f824b635246ef32490c402ea664c`; `stream-settlement.mjs` `13f1f99d32af189d9193f1e9b7a3a52c600c04b23bb443b4df9f6b060bf1d246`; API `donations.mjs` `7a7ae513078dbdaae19971bbd67ebbd85a55798f5ad26980d751004ddefb6cf7`. Diese identifizieren geprüfte Bytes, keine deployed Release-Abnahme.

[Donations-Regeln](donations-policy.md) · [Donations-Roadmap](donations-roadmap.md) · [Datenschutz](privacy.md) · [Bedingungen](terms.md) · [Technische Dokumentation](technical.md)