Vantemio Donations: product and technical documentation
Revision 2026-10-16 · In development · Testnet implementation
1. Purpose and status
Vantemio Donations connects creator profiles, audience support and stream alerts. This is a separate product flow from Market purchases: a support transfer does not create a product order or a Boson voucher. Video distribution is a separate media function; blockchain transactions do not carry a live video stream.
The inspected code targets Base Sepolia only, with creator profiles, prepared payment intents, receipt verification, settlement records and an alert outbox. Source implementation and isolated checks do not establish a working public payment service, production persistence, live channel integration, an independent audit or mainnet availability. The product rules and roadmap describe the remaining acceptance boundaries.
Vantemio software, subscriptions when offered, paid services and donations use cryptocurrency payments. The offer specifies supported networks and tokens, amount, fees and confirmation conditions. Fiat payment rails and integrated conversion or withdrawal to fiat are outside this product; a user’s external exchange is independent of Vantemio.
2. Participants and responsibility
| Participant | Responsibility |
|---|---|
| Donor | Review creator, network, asset, amount and wallet action; retain the transaction reference. |
| Creator or streamer | Control the authorized profile, payout wallet and stream presentation; protect channel and overlay access. |
| Website and backend | Bind the intent to the current profile, verify transaction evidence, record settlement and expose permitted alerts/history. |
| Wallet and network | Authorize and execute the signed transaction according to the selected chain. |
| OBS and channel platform | Present the permitted alert and transmit the programme through their own integrations. |
Station remains the authority for any separately admitted Studio work. A donation, channel connection or OBS token does not authorize a new production job, publication, wallet spend or access to another creator's data.
3. Donor workflow
- Open the intended creator profile and check its payout identity. A channel display name alone is not proof of wallet ownership.
- Obtain the current payment intent. It binds request identity, profile version, donor, recipient, asset, amount, network and nonce.
- Review the wallet transaction and network cost before signing. The current implementation accepts testnet ETH and the configured testnet USDC; it does not enable mainnet by changing a page label.
- Retain the original intent and transaction hash after submission. A wallet prompt, hash or screenshot alone is not verified settlement.
- Follow verification status. If the outcome is uncertain, reconcile the original transfer before authorizing another payment.
An outdated creator profile can cause a conflict response requiring a new intent. If an earlier transaction was already signed or sent, investigate that transaction first; a replacement intent must not become an automatic second transfer.
4. Network, assets and fee accounting
The current network is Base Sepolia, chainId 84532. The configured USDC contract is 0x036CbD53842c5426634e7929541eC2318f3dCF7e. These are testnet settings. Base documents the chain identifier; Circle lists the USDC testnet address and test-token status.
The source computes the ledger allocation in the asset's smallest units:
platformFee = floor(total × 100 / 10000)
creatorAllocation = total − platformFee
This is a nominal 1% platform allocation with integer rounding down. The current prepared on-chain transaction transfers the full total to the creator. It does not send a separate 1% to the platform or atomically collect a 99/1 split on-chain. The accounting allocation and actual token movement must be shown separately. A stored treasury field is not proof of a treasury payment. Network fees are separate from this allocation. Before real payment launch, the collection mechanism, payer and displayed totals require an accepted, reconciled specification.
5. Creator setup and OBS
The intended setup is: authenticate as the profile owner → verify the payout profile → connect an actually supported channel → obtain creator-scoped overlay access → test presentation privately → enable the intended scene. A capability in a platform list or an OAuth URL does not establish a completed channel connection.
OBS supports a web page as a Browser Source. OBS Browser Source. Use the overlay URL supplied by the accepted deployment; do not invent a production URL from an API path. The current backend includes expiring, revocable OBS tokens. Treat an overlay URL containing a token as a credential: keep it out of broadcasts, screenshots and public repositories; replace or revoke exposed access.
Payment verification, alert creation, alert retrieval and delivery acknowledgement are different events. An acknowledgement does not prove that a person saw the alert on a live stream. Reloading a scene must not create a second settlement. Automatic speech, every platform connection and guaranteed live visibility are not established by the inspected alert API.
6. Backend boundaries
| Existing API family | Function and boundary |
|---|---|
/api/donations/config, /api/donations/platforms | Describe configured payment settings and declared platform capabilities; not proof of operational readiness. |
/api/donations/creator/profile | Read or update the versioned creator profile with applicable owner checks. |
/api/donations/intent | Prepare the current-profile payment description; does not sign or broadcast. |
/api/donations/verify | Fetch transaction evidence, verify binding and submit settlement to the selected store. |
/api/donations/history, /api/donations/alerts | Return authorized creator history or scoped alerts. |
/api/donations/obs/token, /api/donations/obs/revoke, /api/donations/alerts/delivered | Issue/revoke overlay access and acknowledge alert delivery under the applicable authorization. |
These paths describe inspected backend interfaces, not a promise that every endpoint is exposed on the public website. Verification uses two configured RPC views with agreement and confirmation checks; actual provider independence must be established for the deployment. The default store in the inspected service is memory-based unless a persistent store is supplied. Restart durability and settlement/outbox atomicity therefore require verification of the actual selected persistent consumer.
7. Failure and recovery
Reject unsupported networks/assets, invalid amounts, changed payment fields and mismatched creator versions or recipients. Missing confirmations, RPC disagreement, unavailable providers and an unknown transaction outcome must remain explicit. The current version/recipient checks can return 409; missing RPC configuration can make verification unavailable.
The settlement identity binds chain and transaction hash. Recovery must preserve original request/intent identity and reconcile receipt, ledger and alert state before any repeat execution. Reorganization handling must preserve the earlier record and its correction. On-chain transfer, local accounting, overlay access and stream presentation must never be collapsed into a single success flag.
8. Release acceptance
Acceptance requires the actual website/backend/persistent-store/dual-RPC path and a private OBS test: correct transfer binding; wrong recipient and stale profile rejection; restart recovery; duplicate transaction and alert handling; revoked/expired token rejection; cross-creator history isolation; RPC failure and reorganization; source-to-HTML/download/repository parity on all five languages. Test fixtures and an isolated store are supporting evidence, not proof of live readiness.
9. Revision evidence and related documents
Inspected on 16 October 2026: stream-donations.mjs SHA-256 6f60190b4d230fe5c4a1e00532661686af15f824b635246ef32490c402ea664c; stream-settlement.mjs 13f1f99d32af189d9193f1e9b7a3a52c600c04b23bb443b4df9f6b060bf1d246; API donations.mjs 7a7ae513078dbdaae19971bbd67ebbd85a55798f5ad26980d751004ddefb6cf7. These identify reviewed bytes, not deployed release acceptance.
Donations rules · Donations roadmap · Privacy · Terms · Technical documentation