Vantemio Donations: продукт и техническая документация
Редакция 2026-10-16 · В разработке · Реализация для тестовой сети
1. Назначение и состояние
Vantemio Donations связывает профили авторов, поддержку аудитории и уведомления на стриме. Этот процесс отделён от покупок в Market: перевод поддержки не создаёт заказ товара или ваучер Boson. Передача видео — отдельная медиафункция; транзакции блокчейна не передают прямой видеоэфир.
Изученный код предназначен только для Base Sepolia и содержит профили авторов, подготовку платёжных намерений, проверку квитанций, записи расчёта и очередь уведомлений. Исходники и изолированные проверки не доказывают работоспособность публичного платёжного сервиса, промышленную сохранность данных, подключение реального канала, независимый аудит или доступность mainnet. Оставшиеся условия приёмки описаны в правилах продукта и дорожной карте.
Оплата ПО Vantemio, подписок при их предложении, платных услуг и донатов производится в криптовалюте. Предложение определяет поддерживаемые сети и токены, сумму, комиссии и условия подтверждения. Фиатные платёжные каналы и встроенная конверсия или вывод в фиат не входят в продукт; внешний обмен пользователь выполняет независимо от Vantemio.
2. Участники и ответственность
| Участник | Ответственность |
|---|---|
| Донатор | Проверить автора, сеть, актив, сумму и действие кошелька; сохранить ссылку на транзакцию. |
| Автор или стример | Управлять подтверждённым профилем, кошельком получения и оформлением стрима; защищать доступ к каналу и оверлею. |
| Сайт и backend | Связать намерение с текущим профилем, проверить транзакцию, записать расчёт и выдать разрешённые уведомления и историю. |
| Кошелёк и сеть | Авторизовать и исполнить подписанную транзакцию в выбранной сети. |
| OBS и платформа канала | Показать разрешённое уведомление и передать программу через собственные интеграции. |
Station сохраняет полномочия допуска отдельных задач Studio. Донат, подключение канала или OBS-токен не разрешают новую производственную задачу, публикацию, расход средств или доступ к чужим данным.
3. Путь донатора
- Открыть нужный профиль автора и проверить получателя. Одно отображаемое имя канала не доказывает владение кошельком.
- Получить актуальное платёжное намерение. Оно связывает идентификатор запроса, версию профиля, донатора, получателя, актив, сумму, сеть и nonce.
- До подписи проверить транзакцию и сетевые расходы в кошельке. Текущая реализация принимает тестовые ETH и настроенный тестовый USDC; смена надписи страницы не включает mainnet.
- После отправки сохранить исходное намерение и хеш транзакции. Окно кошелька, хеш или скриншот сами по себе не означают проверенный расчёт.
- Следить за результатом проверки. При неопределённом исходе сверить первоначальный перевод до разрешения следующего платежа.
Устаревший профиль автора может вызвать конфликт с требованием нового намерения. Если предыдущая транзакция уже подписана или отправлена, сначала разбирается именно она; замена намерения не должна автоматически создавать второй перевод.
4. Сеть, активы и учёт комиссии
Текущая сеть — Base Sepolia, chainId 84532. Настроенный контракт USDC: 0x036CbD53842c5426634e7929541eC2318f3dCF7e. Это параметры тестовой сети. Base описывает идентификатор сети; Circle публикует адрес тестового USDC и статус тестовых токенов.
Код рассчитывает распределение в журнале в минимальных единицах актива:
platformFee = floor(total × 100 / 10000)
creatorAllocation = total − platformFee
Номинальная доля платформы — 1%, с округлением вниз целочисленным делением. Текущая подготовленная транзакция переводит всю сумму автору. Она не отправляет отдельный 1% платформе и не выполняет атомарное удержание 99/1 в блокчейне. Учётное распределение и фактическое движение токенов должны показываться отдельно. Поле treasury в записи не доказывает платёж казначейству. Сетевые расходы отделены от этого распределения. До реального платёжного запуска нужно принять и сверить механизм удержания, плательщика и отображаемые итоги.
5. Настройка автора и OBS
Предусмотренный порядок: войти как владелец профиля → проверить профиль получения → подключить фактически поддерживаемый канал → получить ограниченный автором доступ оверлея → проверить показ приватно → включить нужную сцену. Наличие платформы в списке возможностей или OAuth-ссылки не означает завершённое подключение.
OBS поддерживает веб-страницу через Browser Source. Документация OBS. Используется URL оверлея принятого развёртывания; нельзя придумывать промышленный URL из пути API. В текущем backend есть истекающие и отзываемые OBS-токены. URL с токеном является учётным секретом: его нельзя показывать в эфире, на скриншотах и в публичном репозитории; раскрытый доступ заменяется или отзывается.
Проверка платежа, создание уведомления, получение уведомления и подтверждение доставки — разные события. Подтверждение не доказывает, что человек увидел уведомление в прямом эфире. Перезагрузка сцены не должна создавать второй расчёт. Автоматическая озвучка, подключение любой платформы и гарантированный показ не подтверждаются одним изученным API уведомлений.
6. Границы backend
| Существующее семейство API | Функция и граница |
|---|---|
/api/donations/config, /api/donations/platforms | Параметры платежа и заявленные возможности платформ; не доказательство готовности. |
/api/donations/creator/profile | Чтение или обновление версионируемого профиля с применимыми проверками владельца. |
/api/donations/intent | Подготовка описания платежа по текущему профилю без подписи и отправки. |
/api/donations/verify | Получение доказательств транзакции, проверка привязки и передача расчёта выбранному хранилищу. |
/api/donations/history, /api/donations/alerts | Разрешённая история автора или ограниченные уведомления. |
/api/donations/obs/token, /api/donations/obs/revoke, /api/donations/alerts/delivered | Выдача и отзыв доступа оверлея, подтверждение доставки при соответствующей авторизации. |
Пути описывают изученный backend, а не обещают доступность каждого endpoint на публичном сайте. Проверка использует два настроенных RPC-представления с проверками согласованности и подтверждений; реальную независимость поставщиков нужно установить для развёртывания. По умолчанию изученный сервис использует память, если ему не передано постоянное хранилище. Поэтому сохранность после перезапуска и атомарность записи расчёта с уведомлением проверяются на фактически выбранном постоянном потребителе.
7. Ошибки и восстановление
Отклоняются неподдерживаемые сети и активы, неверные суммы, изменённые поля платежа, несовпадение версии профиля или получателя. Недостаток подтверждений, конфликт RPC, недоступные поставщики и неизвестный исход транзакции остаются явными состояниями. Текущие проверки версии и получателя могут вернуть 409; без настроенных RPC проверка может быть недоступна.
Идентичность расчёта связывает сеть и хеш транзакции. Восстановление сохраняет исходный запрос и намерение, сверяя квитанцию, журнал и уведомление до повторного исполнения. Реорганизация должна сохранять прежнюю запись и её исправление. Перевод в сети, локальный учёт, доступ оверлея и показ в эфире нельзя объединять одним флагом успеха.
8. Приёмка выпуска
Нужны фактический путь сайт/backend/постоянное хранилище/два RPC и приватная проверка OBS: корректная привязка перевода; отклонение чужого получателя и устаревшего профиля; восстановление после перезапуска; повтор транзакции и уведомления; отказ отозванного или истёкшего токена; изоляция истории авторов; сбои RPC и реорганизация; совпадение исходников, HTML, загрузок и репозитория на пяти языках. Фикстуры и изолированное хранилище помогают проверке, но не доказывают готовность действующего сервиса.
9. Основание редакции и связанные документы
Изучено 16 октября 2026 года: stream-donations.mjs SHA-256 6f60190b4d230fe5c4a1e00532661686af15f824b635246ef32490c402ea664c; stream-settlement.mjs 13f1f99d32af189d9193f1e9b7a3a52c600c04b23bb443b4df9f6b060bf1d246; API donations.mjs 7a7ae513078dbdaae19971bbd67ebbd85a55798f5ad26980d751004ddefb6cf7. Это идентификаторы изученных байтов, не приёмка развёрнутого выпуска.
Правила Donations · Дорожная карта Donations · Приватность · Условия · Техническая документация