BroSettlement · Coming soon

Інфраструктура гаманців на етапі підготовки до запуску

Ця публічна сторінка описує поточний staging-контракт і production-модель BroSettlement, яку ми готуємо. Доступ до production API, підтримувані мережі, активи й ліміти ще не доступні.

Обговорити ранній доступПереглянути демо sandbox
Операції з USDT / USDC запланованіCo-Signer у середовищі клієнта запланованийEd25519 у staging-контрактіProduction-покриття ще визначається

Безпека не має відкриватися лише після обсягу

Молоді команди часто просять довести місячний обсяг до того, як їм дадуть нормальну безпеку гаманців, справедливі умови або швидкий онбординг. Це перевернута логіка: інфраструктура потрібна саме для того, щоб створити цей обсяг.

Податок на чесність стартапу

Якщо засновник чесно каже: ми запускаємося й ще не знаємо обсяг, ринок часто відповідає гіршими умовами, довгим sales-процесом або проханням повернутися пізніше.

Перші депозити вже потребують контролю

Коли команда тільки тестує крипто-депозити, виведення й баланси гравців, їй уже потрібні безпечне підписання, зрозумілі правила виплат і журнал для звірки.

Приймання платежів — це ще не вся інфраструктура

Платіжний шлюз може допомогти прийняти крипто. BroSettlement потрібен командам, яким важливо керувати гаманцями, балансами, виведеннями, звіркою та подіями розрахунків.

Запланований стек. Визначений до запуску.

Заплановані вбудовані гаманці

Production-модель передбачає створення MPC-гаманців через DKG для гравців, мерчантів, користувачів або акаунтів.

Заплановане відправлення в мережі

Відправлення підписаних транзакцій є частиною запланованої production-моделі. Мережі й активи підтвердимо до відкриття доступу.

Запланований операційний журнал

Запланований журнал має підтримувати звірку, аудиторський слід і операції з балансами клієнтів.

Запланований Co-Signer у середовищі клієнта

Запланована модель підписання розміщує Co-Signer у середовищі клієнта з контрольованими клієнтом часткою ключа й політикою підписання.

Заплановані засоби контролю API

Staging-контракт описує запити з підписом Ed25519; IP-вайтліст, nonce-перевірки й доступ на рівні організації заплановані для production.

Порогове підписання. Архітектура до запуску.

Запланований процес підписання використовує поріг 2-з-3: для створення підпису потрібні дві визначені частки. Однієї частки недостатньо для підписання.

  • Заплановане DKG + MPC підписання 2-з-3Запропонована модель розподіляє три частки й потребує дві для створення підпису
  • Ed25519 у staging-контрактіПідписання запитів описано в поточній staging-документації
  • Запланований RBAC із 5 ролямиВласник, адміністратор, оператор, переглядач, сервісний доступ
  • Запланована перевірка nonceУнікальні nonce мають допомагати відхиляти повторно надіслані підписані запити
  • Запланований IP-вайтліст для кожного API-ключаМає обмежувати використання API-ключа налаштованими мережевими джерелами
Запланована модель підписання MPC-CMPMPC · 2/3
Запланований гаманецьзапропонований поріг 2/3
K1Co-Signer клієнта · заплановано
K2Підписувач BroSettlement · заплановано
K3Резервна частка · заплановано
Запланований основний шлях використовує K1 + K2; K3 залишається окремою резервною часткою

Co-Signer у середовищі клієнта. Заплановано для production.

Запланований Co-Signer має працювати в середовищі клієнта, зберігати частку клієнта й звертатися до системи клієнта для перевірки політик. Для основного шляху підписання потрібні і частка клієнта, і платформна частка BroSettlement.

Запланований Co-Signer

Запланована модель BroSettlement додає Co-Signer у середовищі клієнта до production-шляху підписання; остаточну поведінку й доступність підтвердимо до запуску.

Заплановане позиціонування

Деякі платформи гаманців повністю утримують компонент підписання у власній інфраструктурі.

Доступ до коду запланований

Доступність коду й умови його перевірки підтвердимо до раннього доступу

Контейнерне розгортання заплановане

Передбачені середовища розгортання включають хмару клієнта, on-premises і приватний VPC

Частка B під керуванням клієнта

Клієнт має керувати часткою B; для основного підписання також потрібна платформна частка BroSettlement

Перевірка політик запланована

Запланований callback може перевіряти налаштовані ліміти, увімкнені мережі й пороги схвалення перед підписанням

Від запиту клієнта до запланованого відправлення в мережу. Визначено до запуску.

Ця схема описує запланований production-шлях для створення гаманців, намірів транзакцій, засобів контролю API, записів у журналі, порогового підписання, відправлення в мережі й оновлення подій. Це не чинний production-процес.

  1. 01

    Staging-контракт описує API-запити з підписом Ed25519; production-вайтліст і перевірка nonce заплановані

  2. 02

    Запланований операційний журнал має записувати намір транзакції до початку підписання

  3. 03

    Запланований Co-Signer у середовищі клієнта має перевіряти політику й повертати рішення про схвалення

  4. 04

    Запропонований MPC-шлях потребує частки клієнта й платформної частки для створення підпису

  5. 05

    Заплановане відправлення в мережі й WebSocket-оновлення залежать від покриття та поведінки подій, які підтвердимо до запуску

Як рухається підписана транзакція

Потік побудований так, щоб API, перевірка політик, підписання, операційний журнал і трансляція в мережу залишалися розділеними, але працювали синхронно.

  1. 01API-шлюз
  2. 02MPC-підписувач
  3. 03Незмінний журнал
  4. 04Blockchain-шлюз
Потік транзакції01 — 04

Середовище партнера

01
API-клієнт створює намірВаш бекенд надсилає підписаний API-запит для гаманця або наміру транзакції.
POST /transactions
02
Callback перевіряє політики перед підписаннямПартнерський Co-Signer звертається до вашого обробника callback, щоб перевірити, чи дозволена ця операція.
tx_sign_request

Шлюзи BroSettlement

03
API-шлюзEd25519IP-вайтлістNonce
04
MPC-підписувачПорогове підписання створює фінальний підписK1 + K2 створюють валідний для мережі підпис без реконструкції приватного ключа.
K1 + K2

Основні сервіси

05
Незмінний журналСтворює операційний запис для депозитів, виведень, переказів, звірки й аудиту.
06
Blockchain-шлюзВідправлення й події закривають циклБлокчейн-шлюз відправляє транзакцію в мережу, операційний журнал оновлюється, а WebSocket доставляє події життєвого циклу.
WS /events
API-шлюз · MPC-підписувач · Незмінний журнал · Blockchain-шлюз

Створено для продуктів із вбудованими гаманцями

iGaming і бетинг

TRON/USDT-гаманці для кожного гравця без кастодіального PSP

  • TRC20 USDT депозитна адреса для кожного акаунта гравця
  • Події deposit.observed і deposit.confirmed
  • Політика оператора перед підписанням виплати
  • Журнал тільки з додаванням записів для звірки балансу гравця
Замовити демо
Основний сценарійTRON / USDT
Модель гаманцяНа гравця
ЗалежністьБез PSP

Гаманці для гравців iGaming

Сценарій для бетинг-оператора, якому потрібні USDT-депозити й виплати без передачі логіки гаманців закритому платіжному провайдеру.

Ситуація

Оператор хоче давати кожному гравцю окрему депозитну адресу, бачити вхідні кошти до фінального підтвердження та самостійно вирішувати, коли зараховувати баланс.

Роль BroSettlement

BroSettlement створює вбудовані гаманці через API, відстежує події в мережі, проводить виплати через Co-Signer і записує кожен рух коштів в операційний журнал.

Операційний результат

Продуктова команда зберігає власний кабінет гравця, правила бонусів і політики виплат, а фінансова команда отримує прозору звірку депозитів, балансів і виведень.

BroSettlementПодії життєвого циклу
01

Створення гаманця гравця

API повертає окрему TRON/TRC20 USDT депозитну адресу для акаунта гравця.

02

Відстеження депозитів

Події повідомляють, коли кошти помічені й підтверджені в мережі.

03

Зарахування за політикою

Оператор вирішує, коли зарахувати баланс гравця.

04

Підтвердження виплати

Co-Signer перевіряє політики оператора перед MPC-підписанням.

deposit.observeddeposit.confirmedwithdrawal.signedwithdrawal.confirmed
01

Швидкий депозитний UX

Показуйте вхідні кошти до фінального підтвердження, а зарахування робіть за політикою.

02

Чиста звірка

Операційний журнал пов’язує баланси гравців із рухом коштів у мережі.

03

Контрольовані виплати

Політики оператора й підтвердження Co-Signer виконуються до підписання.

04

Незалежний стек

Без залежності від кастодіального платіжного провайдера для інфраструктури гаманців.

Staging-контракт інтеграції до відкриття production-доступу.

  • Поточний довідник: опублікований staging Swagger-контракт та API-документація
  • Staging-контракт автентифікації: запити з підписом Ed25519
  • Запланована production-поверхня: Co-Signer у середовищі клієнта й callback політик
  • Заплановані production-засоби контролю: WebSocket-події, IP-вайтліст, перевірка nonce й остаточні умови доступу
Переглянути демо sandbox Відкрити документацію
brosettlement-staging.txt
# Поточний staging Swagger-контракт
REST https://brosettlement-staging-api.brolabel.io/api/v1
Автентифікація, описана в контракті: Ed25519
Доступ: цей сайт його не надає

# Заплановані production-поверхні
Co-Signer · WebSocket · IP-вайтліст · перевірка nonce

Створено для команд, яким потрібен контроль

Позиція BroSettlement

Вбудована MPC-інфраструктура гаманців для стейблкоїнів та iGaming.

Для команд, які розглядають Fireblocks, Dfns, Utila, Blockdaemon або Safeheron, BroSettlement дає фокусовану DKG/MPC-інфраструктуру гаманців і глибше закриває стейблкоїн-сценарії: відправлення у 10 блокчейнів, моніторинг депозитів, звірку в операційному журналі та WebSocket-події.

DKG + некастодіальний MPCВбудовані гаманціSelf-hosted Co-SignerВідправлення у 10 мережЖурнал + WebSocket

Fireblocks

Глибока enterprise custody-платформа. BroSettlement вужчий і швидший для вбудованих стейблкоїн-гаманців, iGaming-депозитів, виплат, операційного журналу та WebSocket-сценаріїв.

Enterprise custody · Широка платформа

Dfns / Utila

Сильна інфраструктура гаманців і інструменти для політик. BroSettlement додає вертикальний стейблкоїн-стек: DKG/MPC, відправлення у 10 мереж, створення вбудованих гаманців, операційний журнал і події.

Інфраструктура гаманців · Контроль політик

Blockdaemon / Safeheron

Інституційне керування ключами та інфраструктура зберігання активів. BroSettlement цілиться в команди, яким потрібен MPC-шар плюс операції зі стейблкоїн-гаманцями, журналом і подіями.

Інституційний MPC · Custody-інфраструктура

BroSettlement

API-first вбудовані гаманці з DKG, некастодіальним MPC, Co-Signer, відправленням у 10 мереж, WebSocket-подіями та операційним журналом як джерелом правди.

Стейблкоїни · iGaming

Затверджені тарифи на старті.

Доступ у робочому режимі ще не запущено. Нижче наведено затверджені тарифи, які діятимуть після запуску; щодо sandbox або раннього доступу зверніться до команди BroLabel.

Безкоштовний

$0

Лише тестова мережа

  • 10 гаманців
  • 1 користувач · 1 API-ключ
  • Доступ до демо-консолі

Starter

$299/mo

$1M обсягу · 100 гаманців

  • 5 мереж · основні мережі
  • 3 API-ключі · 5 користувачів
  • Підтримка спільноти
  • 0.20% за перевищення ліміту
Рекомендований на старті

Business

$999/mo

$15M обсягу · 5,000 гаманців

  • 10 мереж · основні мережі
  • 10 API-ключів · 25 користувачів
  • Підтримка через email
  • 0.12% за перевищення ліміту

Scale

$3,499/mo

$30M обсягу · 15,000 гаманців

  • Розширений набір мереж
  • 50 API-ключів · 100 користувачів
  • Пріоритетна підтримка
  • 0.07% за перевищення ліміту

Enterprise

Індивідуально

Безліміт для всього

  • Індивідуальне покриття мереж
  • Безлімітні гаманці й користувачі
  • Виділена підтримка
  • Індивідуальні умови перевищення ліміту

Шлях від демо до раннього доступу

  1. Крок 1

    Демо sandbox сьогодні

    Інтерактивна консоль із симульованими гаманцями, транзакціями, WebSocket-подіями та іншими демонстраційними даними. API-операції недоступні.

  2. Крок 2

    Підготуйте інтеграцію

    Ознайомтеся з REST API, схемами транзакцій, подіями WebSocket та моделлю Co-Signer у документації.

  3. Крок 3

    Погодьте план запуску

    Запросіть ранній доступ, перевірте технічні вимоги та узгодьте етапи переходу в робочий режим із командою BroLabel.

BroSettlement лежить в основі всього.

BroWallet і BroCard можуть залишатися продуктами поверх BroSettlement. Водночас BroSettlement можна вбудувати напряму як інфраструктуру вбудованих гаманців для B2B-команд, яким потрібні DKG, MPC-підписання, відправлення в блокчейни, операційний журнал і WebSocket-події.

  • 01

    BroSettlement як DKG/MPC та інфраструктура вбудованих гаманців

  • 02

    BroWallet і BroCard як продуктові шари поверх ядра

  • 03

    Або власний продукт клієнта поверх API BroSettlement

BroSettlementлежить в основі всього.
01DKG + MPC
02Вбудовані гаманці
03Незмінний журнал
04Відправлення у 10 мереж
BroSettlementDKG + MPC · Незмінний журнал

Готові запустити вбудовані гаманці?

DKG, некастодіальний MPC, відправлення у 10 блокчейнів, Co-Signer у вашому середовищі, операційний журнал і API з готовим sandbox для стейблкоїн- та iGaming-продуктів.

Замовити демо Переглянути демо sandbox