Як агент може оплачувати послуги та виконувати завдання через Solana

Головне твердження

AI-агент оплачує послуги та виконує завдання через Solana, керуючи гаманцем програмним шляхом — без графічного інтерфейсу та ручних підтверджень. Агент конструює транзакцію, підписує її через механізм програмно-похідних адрес (PDA) або делегований авторитет, і відправляє у мережу через RPC-вузол. Усе, що людина робить у гаманці кліками, агент робить кодом.

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

Практичний бік механізму

Нижче — три типові сценарії, що охоплюють більшість практичних завдань.

Сценарій 1. Оплата зовнішньої послуги (API, модель, дані)

Агенту потрібно отримати дані або обчислення від стороннього сервісу, який приймає оплату в SOL або токенах на Solana.

Хід дій: агент формує транзакцію переказу на адресу провайдера, підписує її (через PDA або ключ, до якого має доступ), відправляє через RPC і чекає підтвердження. Після підтвердження — викликає API провайдера з підтвердженням оплати.

Критерій перевірки: чи передбачений у сервісі механізм прив’язки транзакції до конкретного запиту (наприклад, memo-поле або оф-чейн реєстр). Без цього агент не зможе довести, що саме він оплатив.

Сценарій 2. Виконання завдання на ланцюжку (обмін, стейкінг, переказ)

Агент виконує дію безпосередньо в смарт-контрактах Solana — наприклад, обмінює токени через DEX або переводить активи між акаунтами.

Хід дій: агент через CPI (cross-program invocation) викликає потрібну програму, формує інструкцію з правильними параметрами, підписує і відправляє транзакцію. У складних випадках — будує багатокрокову транзакцію, де кілька інструкцій виконуються атомарно.

Критерій перевірки: чи підтримує цільова програма виклик через CPI у потрібній конфігурації. Деякі програми обмежують caller-адреси або вимагають специфічних акаунтів у транзакції.

Сценарій 3. Оплата за виконання завдання іншому агенту

Агент A наймає агента B для підзавдання і платить йому на ланцюжку.

Хід дій: агент A відправляє транзакцію переказу на PDA агента B. Агент B моніторить свій акаунт (через підписку на події або періодичні запити), фіксує надходження і розпочинає роботу.

Критерій перевірки: чи є у агента B чіткий протокол зв’язку «оплата → початок роботи». Без цього є ризик, що агент B не дізнається про платіж або розпочне роботу без оплати.

Сценарій	Де відбувається оплата	Ключова технічна умова
Зовнішній сервіс	On-chain переказ + off-chain API	Прив’язка платежу до запиту
Завдання на ланцюжку	Повністю on-chain	Підтримка CPI цільовою програмою
Оплата іншому агенту	On-chain переказ між PDA	Протокол зв’язку між агентами

Кому потрібне це пояснення

Розробникам агентних систем — це базовий інструментальний шар. Без можливості платити та виконувати транзакції агент залишається лише консультантом, який генерує тексти, але не діє.

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

Бізнесам, які інтегрують AI у фінансові потоки — наприклад, агент закуповує дані, платить за обчислення і розподіляє винагороду, не чекаючи на людське підтвердження кожної операції.

Кому це не потрібно зараз: користувачам, які взаємодіють з Solana через гаманець вручну і не мають завдань, що повторюються часто enough для автоматизації. Якщо ви робите переказ раз на тиждень — агент не дає переваг, але додає складність. Більше про те, чи потрібен агенту блокчейн взагалі — у матеріалі Навіщо AI-агенту блокчейн і де без нього можна обійтися.

Слабкі місця підходу

Дозволи без меж

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

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

Немає зворотного зв’язку після оплати

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

Критерій перевірки: чи має агент протокол верифікації «оплата → результат» з таймаутом і повторною спробою або поверненням коштів.

MEV та фронтранінг

Якщо агент виконує великі обміни на DEX, транзакція може бути помічена й використана іншими учасниками для фронтранінгу. Агент отримає гірший курс, ніж очікував.

Критерій перевірки: чи використовує агент механізми захисту від MEV (Jito-маршрутизацію, контроль slippage, ліміти виконання та інші механізми, доречні для конкретного протоколу). Для великих операцій важливо окремо перевірити, які гарантії реально дає обраний маршрут і що він не захищає.

Залежність від RPC-вузла

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

Критерій перевірки: чи має агент фолбек-список RPC-вузлів і механізм визначення, що транзакція не була включена в блок.

Неможливість відкату

Більшість транзакцій у Solana фінальні після підтвердження. Якщо агент помилився — повернути кошти можна лише якщо одержувач погодиться. Агент не має юридичної особистості, тому «попросити назад» не вийде.

Критерій перевірки: чи передбачена в архітектурі можливість тестових транзакцій на devnet перед виконанням на mainnet.

Що має підтвердити висновок

Перш ніж запускати агента з реальними коштами, перевірте таке:

• Модель підпису. Хто підписує транзакцію — PDA (без приватного ключа, але з обмеженими можливостями) чи повний ключ (ризик втрати всього балансу)? PDA безпечніший, але не підходить для всіх типів транзакцій.
• Обсяг дозволів. Чи обмежений агент конкретними токенами, сумами та цільовими програмами? Чи може він випадково витратити те, що не мав би?
• Протокол зв’язку. Як агент дізнається, що оплата прийнята? Як дізнається, що послуга надана? Чи є таймаути та обробка помилок?
• Тестування на devnet. Чи пройшов повний цикл «оплата → виконання → верифікація» на тестовій мережі перед mainnet?
• Моніторинг. Чи є зовнішній спостерігач, який фіксує всі транзакції агента і може сповістити про аномалії?

Якщо ви на етапі вибору архітектури для агента, корисно переглянути загальний огляд AI-агенти й agentic economy на Solana. Якщо вас цікавить, як довести, що агент — саме той, за кого себе видає, перейдіть до матеріалу про ідентичність і репутацію AI-агента. Загальний каталог працюючих продуктів — у розділі Продукти Solana: що працює для людей.

Редакція солана.укр