Testnet-гаманець AI-агента: від API до першої транзакції

Testnet-гаманець AI-агента перевіряє контроль до появи коштів

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

Тому тестова мережа є репетицією контролю, а не одноразовою демонстрацією. Команда має створити один рахунок в операційному журналі та пов'язаний гаманець, перевірити гаманець за ID, поповнити його публічну адресу підтримуваним тестовим активом, побачити депозит, звірити баланс і лише після цього перевірити невелику вихідну транзакцію. Робочий процес має використовувати ті самі межі відповідальності, які команда планує для запуску.

Коротка відповідь

Щоб безпечно створити testnet-гаманець AI-агента, встановіть і перевірте BroSettlement Agent Skills, використайте окремі Ed25519 API-ключі з обмеженими правами для Co-Signer та інтеграції, запустіть Co-Signer під контролем клієнта, завершіть MPC/DKG, створіть один рахунок і пов'язаний гаманець у готовій тестовій мережі, а потім перевірте депозит через операційний журнал і обмежене спостереження за подіями. Приватні ключі, частки MPC, матеріали шифрування та підписані WebSocket-адреси не мають потрапляти в контекст моделі.

Карта готовності

Створення гаманця відбувається ближче до кінця налаштування. Кожна попередня перевірка підтверджує окрему частину межі контролю.

API робочого середовища BroSettlement може створювати гаманець у тестовій блокчейн-мережі. Середовище API та блокчейн-мережа є різними рішеннями. Гаманець TRON Nile залишається тестовим, навіть якщо організація використовує API робочого середовища.

Крок 1: розділіть ключ Co-Signer і ключ інтеграції

Використовуйте дві Ed25519 ідентичності, бо вони виконують різні завдання.

Окремому ключу Co-Signer потрібні саме ті MPC-права, які визначає посібник із налаштування: Initialize MPC, Read MPC і Raw MPC co-signer. Його приватний ключ залишається на сервері Co-Signer. Агент може допомогти локально створити пару ключів і показати публічний PEM, але користувач має власноруч створити API-ключ у Console. Агент не повинен відкривати розділ API Keys, обирати права, надсилати форму, змінювати ключ або копіювати Key ID замість користувача.

Ключ інтеграції має бути окремим. Для нового керованого налаштування, що створює перший рахунок і гаманець, йому потрібні чинні відповідники accounts:read, accounts:create, wallets:read і wallets:create. Для наступного створення гаманця в уже наявному рахунку запитуйте лише права, яких вимагає чинний контракт Swagger. Не додавайте створення рахунків лише заради зручності.

Дотримуйтеся швидкого старту BroSettlement для актуальної послідовності та посібника з Agent Skills для контрольованої роботи агента.

Крок 2: запустіть Co-Signer до ініціалізації MPC

Co-Signer під контролем клієнта є межею підписання та правил поза контекстом моделі. Встановіть його на контрольованому сервері, тримайте приватний ключ, ключ шифрування часток і зашифроване сховище часток MPC поза Git та перевірте стан з обох боків:

1. Локальна кінцева точка /health повертає HTTP 200, ready: true, а можливості DKG і підписання увімкнені.
2. BroSettlement Console показує Co-Signer у стані Online.

Ці перевірки відповідають на різні запитання. Локальний стан підтверджує готовність процесу й сховища. Стан у Console доводить, що служба автентифікувалася та зв'язалася з BroSettlement. Не ініціалізуйте MPC, доки одна з цих перевірок не пройдена.

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

Крок 3: завершіть MPC/DKG і перевірте готовність мережі

Ініціалізація MPC створює розподілений ключ підписання організації. Тримайте Co-Signer під'єднаним до завершення DKG. Не перезапускайте його, не змінюйте API-ключ, не замінюйте ключ шифрування часток і не видаляйте каталог часток під час ініціалізації.

До створення гаманця перевірте три умови:

• MPC-ключ має стан Active або Ready;
• Co-Signer має стан Online;
• обрана тестова мережа повідомляє про готовність.

На цьому етапі також підтвердьте операційне зберігання Share B та окрему резервну копію Share C. Тестовий баланс не має ринкової вартості, але правильна операційна звичка має значення. Не відкладайте побудову процесу відновлення до появи реальних коштів.

Крок 4: створіть один рахунок і один пов'язаний гаманець

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

1. Створіть рахунок через підписаний API-процес.
2. Отримайте ID рахунку та повторно прочитайте ресурс за цим ID.
3. Створіть пов'язаний із рахунком гаманець у готовій тестовій мережі, наприклад TRON Nile, якщо вона підтримується.
4. Отримайте ID гаманця та повторно прочитайте гаманець за ID.
5. Підтвердьте стан Active і зафіксуйте ID рахунку, мережу, публічну адресу, стан та часові позначки.

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

@brosettlement api GET '/api/v1/ledger/accounts'
@brosettlement api GET '/api/v1/wallets'
@brosettlement api GET '/api/v1/ledger/accounts/<accountId>/wallets'

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

Крок 5: поповніть публічну адресу й перевірте отримання

Перед запитом тестових активів підтвердьте, що актив повертається чинним Assets API, а мережа гаманця відповідає крану. Для TRON Nile скористайтеся офіційним посібником TRON із тестових токенів, щоб перейти до актуального крана Nile або задокументованих спільнотою альтернатив, а публічну транзакцію перевірте в Nile Explorer.

Вводьте в кран лише публічну адресу тестової мережі. Крану ніколи не потрібні фраза відновлення, приватний ключ, приватний API-ключ або частка MPC. Тестові токени не мають фінансової вартості, а активи основної мережі не можна надсилати на адресу тестової мережі.

Зафіксуйте баланс і стан журналу до переказу. Після відправлення краном перевірте:

1. публічна транзакція з'явилася в оглядачі мережі;
2. платформа побачила й підтвердила депозит;
3. баланс гаманця змінився на очікувану кількість активу;
4. операційний журнал містить відповідний запис;
5. обмежений у часі споживач WebSocket-подій ідемпотентно обробляє дублікати й повторні під'єднання.

Депозит є вхідною блокчейн-подією. Ніколи не викликайте кінцеву точку створення транзакції, щоб штучно створити депозит. Якщо баланс і запис журналу не досягли кінцевого стану в межах часу спостереження, повідомте перевірка депозиту триває та поверніть команди отримання даних замість необмеженого очікування.

Крок 6: окремо перевірте одне контрольоване виведення

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

До надсилання підтвердьте правильність адреси, свідомо малу суму, стан Online для Co-Signer і дозвіл локальних правил. Надішліть логічну транзакцію один раз. Тайм-аут не дозволяє створювати другий запит із новим ключем ідемпотентності.

Після прийняття створення один раз прочитайте транзакцію за ID. Якщо стан не кінцевий, повідомте виведення прийнято; перевірка триває і припиніть синхронне опитування. WebSocket-події та подальша звірка можуть завершити життєвий цикл без утримання інтерактивної сесії агента.

Ризики й контроль до переходу за межі тестової мережі

Завершення перевірки в тестовій мережі має залишати докази, а не лише впевненість на словах.

• Секрети: приватні ключі, матеріали шифрування часток, частки MPC, підписані URL, паролі, JWT і TOTP-коди залишаються поза чатом та системою контролю версій.
• Права: ключі Co-Signer та інтеграції розділені й мають мінімальні дозволи.
• Ідемпотентність: кожна зміна стану зберігає один стабільний ідентифікатор операції під час контрольованих повторень.
• Правила: адреси отримувачів, активи, суми, швидкість операцій і пороги ручної перевірки визначені явно.
• Спостереження: стани гаманця, події, баланси й записи журналу можна звірити.
• Відновлення: зберігання Share B та Share C розділене, а шлях відновлення задокументований.
• Відповідність: організація відповідає за KYC/KYB, AML, Travel Rule, ліцензування, моніторинг і звітування.

Не переходьте в основну мережу лише тому, що один переказ із крана був успішним. Повторіть сценарії збоїв: дубльовані запити, затримані підтвердження, недоступний Co-Signer, заборонена адреса, недостатній баланс, повторне під'єднання до подій і розбіжність під час звірки.

Як поєднуються BroSettlement та Agent Skills

BroSettlement надає межу гаманців, операційного журналу, Co-Signer, MPC-підписання, подій і розрахунків. BroLabel AI Agents пояснює, як агент допомагає з операціями гаманця, не перетворюючись на необмеженого підписанта. Agent Skills поєднують ці частини через доступний для перевірки процес налаштування та API-засоби, що враховують чинний Swagger.

Практичний наступний крок: установіть Agent Skills, активуйте $brosettlement-onboarding і завершіть один тестовий рахунок, гаманець, депозит та контрольовану транзакцію з доказом на кожній перевірці. Bro has your back!

FAQ

Чи може AI-агент створити testnet-гаманець?

Так. Агент може провести налаштування та викликати контрольовані засоби для створення одного дозволеного рахунку й пов'язаного testnet-гаманця. Користувач усе одно власноруч створює API-ключі в Console, а приватні ключі й частки MPC залишаються поза контекстом моделі.

Чи потрібен API тестового середовища BroSettlement для тестової мережі?

Ні. Середовище API BroSettlement і блокчейн-мережа є різними поняттями. Організація в робочому середовищі API може створити гаманець у підтримуваній тестовій мережі, наприклад TRON Nile, коли мережа готова.

Який API-ключ має створювати гаманець?

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

Як зрозуміти, що перший депозит успішний?

Звірте публічну блокчейн-транзакцію, стан депозиту на платформі, баланс гаманця й запис в операційному журналі. WebSocket-події покращують видимість, але їхні споживачі мають витримувати дублікати й повторні під'єднання.

Коли налаштування готове до основної мережі?

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