# Vantemio Donations roadmap

Revision 2026-10-16 · Acceptance stages · In development

## 1. Observed baseline

The [technical paper](donations.md) identifies the inspected source revision: Base Sepolia intents, current creator/profile binding, receipt checks, a settlement-store interface, creator-scoped history and revocable OBS access. These mechanisms are source-observed. Their presence is not acceptance of a deployed public service. The inspected default store uses memory unless a persistent store is injected.

Progress is recorded by accepted behavior and evidence. The stages below do not announce launch dates or imply that an earlier stage has passed.

## 2. Persistent backend and recovery

Complete the actual website/server/persistent-store/dual-RPC path. Demonstrate unique transaction claims, one accepted settlement and alert identity, restart recovery, stale-profile rejection and cross-creator isolation. Reconcile unavailable providers, conflicting receipts, reorganizations and interrupted writes without repeating the transfer or discarding history.

Acceptance record: selected source/configuration revision, actual storage and RPC setup, original request and transaction references, observed outcomes and unresolved limits. An in-memory fixture is supporting evidence only.

## 3. Creator, donor and stream integration

Connect current-profile checkout, clear pending/failed/unknown states and safe handling of `409` profile conflicts. Verify ownership and actual channel authorization separately from a platform capability declaration. Finish the deployed overlay page and conduct a private OBS run covering retrieval, display, acknowledgement, scene reload, token expiry and revocation.

Acceptance record: the actual supported channel/permissions, creator isolation, donor/creator UI outcome and evidence distinguishing payment confirmation from alert visibility. A channel logo, OAuth URL or backend alert record does not complete this stage.

## 4. Reconciled economics and public documentation

Resolve the intended collection mechanism before real payment launch. The current source transfers the full total to the creator while allocating 1% in the ledger; this is not an atomic on-chain 99/1 payment. Verify displayed amount, allocation, actual movement, any treasury collection and separate network fees against the accepted implementation.

Publish matching [rules](donations-policy.md), technical paper and roadmap in EN/RU/ES/PT/FR. Check the actual site pages, document downloads, archive and scoped public/private repository copies against one accepted source revision. Translation completeness and a successful build do not prove live publication.

## 5. Production acceptance and expansion

Before production payment availability, establish the approved network/asset/recipient configuration, operational access controls, persistence/recovery, resource-bounded capacity results, monitoring and incident procedures. Independent security review and applicable legal/operational readiness require their own records; no audit or jurisdiction is invented by this roadmap.

Additional networks, assets, channel platforms, voice alerts and broader live-media functions are later capabilities. Each needs actual provider permission, source integration and acceptance. Capacity targets remain requirements until measured on the intended runtime. A testnet result does not authorize or demonstrate mainnet operation.

[Technical paper](donations.md) · [Donations rules](donations-policy.md) · [Project roadmap](roadmap.md)