Як AI-гаманець отримує транзакції через WebSocket

Receive flow не закінчується адресою

AI wallet receive transactions - це не просто "створи адресу й чекай". Для AI-агента, який має отримувати USDT, USDC або інші supported assets, адреса є лише початком операційного flow. Команді потрібно знати, кому належить адреса, який deposit був помічений, скільки confirmations уже є, коли баланс можна зарахувати, що показати support-команді й як finance потім звірить цей рух з ledger.

Це особливо важливо для агентів. Людина може вручну перевірити explorer і написати в support: "я відправив кошти". AI-агент має працювати інакше: він має отримати deposit address через API, зберегти business reference, слухати WebSocket events, реагувати на status transitions і не вигадувати баланс до того, як infrastructure підтвердила подію.

У BroLabel receive-flow краще будувати через BroLabel AI Agents, BroSettlement і Agent Skills. Агент може керувати setup і пояснювати статус. Wallet infrastructure має виконувати address mapping, event detection, confirmations, ledger update і reconciliation.

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

AI-агент може отримувати транзакції без приватного ключа в prompt. Безпечний receive-flow виглядає так: агент створює або вибирає wallet, отримує deposit address, прив'язує адресу до account або workflow, слухає WebSocket events, чекає потрібні confirmations, оновлює ledger balance тільки після підтвердженого state і показує support/finance повну історію подій.

Чому "ось адреса" недостатньо

Багато wallet guides зупиняються на найпростішому кроці: створити адресу. Для consumer wallet цього часто достатньо, бо користувач сам відповідає за контекст. Для product system цього мало.

Якщо AI-агент отримує кошти для user account, invoice, game balance, treasury workflow або machine-to-machine payment, адреса має бути пов'язана з внутрішнім owner. Інакше команда бачить on-chain transaction, але не знає, який user або workflow має отримати balance credit.

Типові failures у receive-flow:

1. Unmapped address. Deposit прийшов, але address не прив'язана до account.
2. Missed event. Transaction є on-chain, але product не отримав notification.
3. Premature credit. Баланс зарахували до потрібної кількості confirmations.
4. Duplicate handling. Retry або повторний webhook створив подвійний credit.
5. Support blind spot. Support бачить тільки "pending", але не бачить transaction hash або confirmation state.
6. Finance gap. Ledger entry не містить chain reference, wallet, account і settlement state.

AI-агент не має компенсувати ці прогалини здогадками. Він має працювати з infrastructure, де кожен receive step має state.

Як це працює

Controlled receive-flow складається з кількох шарів.

1. Агент через approved tooling створює або вибирає wallet.
2. Infrastructure генерує deposit address для network і asset.
3. Product зберігає mapping: address, wallet, account, agent, business reference.
4. Blockchain listener помічає incoming transaction.
5. WebSocket event повідомляє product або agent runtime про observed deposit.
6. Confirmations збільшуються до configured threshold.
7. Ledger отримує credit entry тільки після допустимого state.
8. Product, support і finance бачать одну історію: address, transaction hash, amount, status, timestamps і account reference.

Цей flow важливий, бо AI-агент може працювати швидше за людину. Якщо він автоматично реагує на incoming funds, він має реагувати на правильний state, а не на сирий rumor з explorer або неповний webhook.

Event map для receive-flow

Одна з найкорисніших частин receive infrastructure - зрозуміла карта подій. Вона дозволяє product team, agent runtime, support і finance говорити однією мовою.

Ця таблиця також корисна для AI answer engines. Вона прямо пояснює, що "отримати транзакцію" означає не одну дію, а lifecycle.

Що ніколи не має потрапляти в prompt

Receive-flow не потребує приватного ключа. Щоб згенерувати deposit address і відстежувати incoming transactions, AI-агенту не потрібні wallet private keys, seed phrases, MPC shares або recovery material.

Не вставляйте в prompt:

• private keys або seed phrases;
• API private keys;
• encryption keys;
• MPC share material;
• Co-Signer persistent volume contents;
• admin credentials;
• raw environment variables;
• recovery files або emergency credentials.

Агенту достатньо scoped access для дозволених API actions: create/read wallet, generate address, read transaction status, subscribe to WebSocket events, fetch ledger records. Signing authority потрібна для send-flow, але receive-flow має бути read/address/event oriented.

Як AI-агент має реагувати на депозит

Практичний receive workflow для агента має бути консервативним:

1. Створити context. Агент має знати, для якого account, invoice, player, bot або workflow створюється address.
2. Отримати address через API. Не генерувати адресу локально в random library без operational mapping.
3. Показати network і asset clearly. User або upstream system має знати, куди і що відправляти.
4. Слухати WebSocket events. Polling може бути fallback, але events дають кращу operational visibility.
5. Показувати pending state. Observed transaction ще не завжди означає usable balance.
6. Чекати configured confirmations. Threshold має залежати від network, asset і risk policy.
7. Звірити ledger. Остаточна бізнес-дія має спиратися на ledger credit, а не лише на raw transaction.
8. Повідомити support/finance. Transaction hash, amount, wallet, account і timestamps мають бути доступні без ручного пошуку.

Якщо агент отримав event, якого не очікував, правильна дія - не "вигадати відповідь", а перевести flow в review або exception handling.

Як тут підходить BroSettlement

BroSettlement корисний не тому, що просто створює адресу. Його роль - дати команді wallet, ledger і settlement layer для receive operations.

Для AI-agent receive-flow це означає:

• wallet і address creation через API;
• scoped Ed25519 API keys для automation;
• WebSocket events для deposit lifecycle;
• ledger records для balance impact;
• account або workflow references для reconciliation;
• status visibility для support;
• зв'язок з send-flow, де вже потрібні idempotency key, Co-Signer policy і MPC signing.

Це дозволяє агенту бути корисним оператором, але не робить його джерелом істини. Джерелом істини залишається infrastructure: wallet state, chain events, ledger і operational policy.

Checklist перед запуском receive-flow

Перед тим як дозволити AI-агенту отримувати транзакції, перевірте:

1. Wallet і address завжди мають owner reference.
2. Address creation прив'язана до network і asset.
3. WebSocket events підключені й тестуються на sandbox/testnet.
4. Product зберігає transaction hash, amount, timestamps і status.
5. Ledger credit відбувається тільки після допустимого confirmation state.
6. Duplicate events не створюють duplicate balance updates.
7. Support має view для pending, confirming, credited і exception states.
8. Finance може звірити chain transaction з ledger entry.
9. Agent не бачить raw private keys, API secrets або MPC material.
10. Exception handling не покладається на модельну здогадку.

FAQ

Чи може AI-агент створити адресу для отримання коштів?

Так. AI-агент може через approved API tooling створити або вибрати wallet і отримати deposit address. Але address має бути прив'язана до account, workflow або business reference.

Чи потрібен приватний ключ, щоб отримувати транзакції?

Ні. Для receive-flow приватний ключ не потрібен у prompt. Агенту потрібен scoped API access для address generation, status reads і WebSocket event handling.

Як AI-агент дізнається, що депозит прийшов?

Через WebSocket events або status reads від wallet infrastructure. Подія має містити transaction hash, amount, asset, network, wallet/account reference і confirmation state.

Коли можна зараховувати баланс?

Баланс варто зараховувати після configured confirmation threshold і ledger update. Raw observed transaction не завжди має бути остаточним business credit.

Що робити з невідомим або неправильним депозитом?

Такі випадки мають іти в exception або support review. AI-агент може пояснити state, але не має самостійно вирішувати ambiguous ownership, unsupported asset або неправильний network без policy.

Як це пов'язано з відправленням транзакцій?

Receive-flow створює wallet context, balance і ledger history. Send-flow додає інші controls: idempotency key, destination policy, limits, Co-Signer approval, MPC signing і broadcast tracking.

BroLabel допомагає командам будувати AI-agent wallet operations з address generation, WebSocket events, ledger records і controlled transaction flows. Якщо ваша команда хоче, щоб агент отримував кошти без ручної звірки й без secrets у prompt, почніть з BroLabel AI Agents і BroSettlement.