Кастодіальний vs некастодіальний MCP: хто тримає ключі агента

Ви доручаєте ШІ-агенту зробити своп на TON. Він викликає потрібний інструмент, і за десять секунд транзакція вже в блокчейні — ви її не підписували, гаманець не відкривали, нічого не підтверджували. Зручно? Так. А тепер той самий агент неправильно розпарсив ваш промпт, переплутав amount і відправив не 5, а 500 GRAM. І теж не спитав. Питання, яке варто поставити до першого свопу, а не після: хто взагалі тримає приватний ключ і хто ставить підпис під транзакцією?

Це і є вододіл між двома моделями MCP-серверів для TON. Розберемо кастодіальний MCP проти некастодіального агент-гаманця предметно — з конфігами, інструментами та чесними ризиками обох сторін.

Кастодіальний MCP чи некастодіальний агент-гаманець: хто тримає ключі та хто підписує

Спершу трохи теорії. MCP (Model Context Protocol) — стандарт, за яким ШІ-агенти (Claude, Cursor, ChatGPT/Codex і будь-який інший MCP-клієнт) викликають зовнішні інструменти. Агент не вміє сам ходити в блокчейн — він викликає MCP-інструмент на кшталт «дай баланс» чи «збери своп», а MCP-сервер виконує роботу. І для блокчейну все впирається в одну технічну деталь: транзакцію треба підписати приватним ключем.

Кастодіальність агента визначається двома речами:

1. Де фізично лежить приватний ключ — на сервері MCP чи в користувача? Той, хто ним володіє, розпоряджається коштами.
2. Хто накладає підпис — сервер сам чи гаманець користувача? Підпис перетворює намір на незворотний рух грошей.

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

Це як різниця між «дати другові свою банківську картку з пін-кодом» і «дати другові заповнену платіжку, яку ти сам підпишеш у банку». В обох випадках друг допомагає, але ризик принципово різний. Жодна з моделей не «правильніша» за іншу у вакуумі — вони дають різний баланс автономії та контролю. Далі — як це виглядає на конкретних продуктах.

Кастодіальна модель: офіційний @ton/mcp і split-key

Офіційний @ton/mcp від TON Foundation — це кастодіальний агент-гаманець. Він тримає operator-ключ і підписує транзакції сам. Працює за моделлю split-key: operator-ключ в агента, owner-ключ у користувача. Тобто агент не всевладний (owner-ключ лишається важелем на боці людини), але в межах своїх повноважень він витрачає кошти без ручного підпису кожної операції.

Що вміє @ton/mcp:

• читання стану мережі та акаунтів;
• відправлення GRAM, жетонів і NFT;
• своп через DEX-агрегатор;
• створення та імпорт агент-гаманців;
• читання NFT і DNS.

Чого не вміє: кросчейн — працює лише всередині TON. Запускається локально, через HTTP або serverless.

Це офіційний пакет Foundation, і в нього є чесні сильні сторони:

• Повна автономія витрат. Агент виконує ланцюжок дій без зупинок на підтвердження — те, що потрібно для по-справжньому автономних сценаріїв (підписки, автоматичні виплати).
• NFT і DNS з коробки.
• Офіційність — підтримка з боку Foundation.

Ціна автономії очевидна: operator-ключ живе в середовищі агента. А агент — це LLM, яку можна обдурити текстом. Хто контролює це середовище та його конфігурацію — той у межах operator-повноважень контролює й підпис.

Некастодіальна модель: TONNode віддає непідписані TonConnect-повідомлення

TONNode — hosted MCP-сервер для TON (сайт tonnode.io) з рівно 16 інструментами. Тут інструменти свопу, кросчейну та гаманця строго некастодіальні: сервер ніколи не підписує і не зберігає кошти та приватні ключі.

Механіка проста. Замість «зроби своп» інструмент build_swap_tx повертає непідписане TonConnect-повідомлення — готову транзакцію, яку підписує гаманець користувача (Tonkeeper, MyTonWallet, будь-який TonConnect-сумісний). Сервер зібрав «платіжку», але підпис ставить власник ключа. Сервер бачить лише публічні дані: адресу, суму, цільовий контракт. Приватного ключа він не торкається в принципі.

Типовий потік свопу виглядає так:

1. get_swap_quote — тверде котирування DEX (GRAM ⇄ жетон, ліквідність STON.fi + DeDust через протокол Omniston).
2. build_swap_tx — непідписана транзакція під це котирування.
3. Гаманець користувача підписує її через TonConnect. Усе.

Сам промпт для агента виглядає буденно:

Дай котирування на своп 10 GRAM в USDT, потім збери транзакцію
свопу для моєї адреси EQ... — я підпишу її сам у гаманці.

Агент викличе get_swap_quote, потім build_swap_tx, а на виході ви отримаєте об'єкт транзакції, а не факт списання.

Навіть створення гаманця некастодіальне. generate_wallet створює гаманець версій v3r2 / v4 / v5r1 / highload_v3 і віддає мнемоніку, ключі та адресу користувачеві — сервер їх не зберігає. Згенерував, забрав сід-фразу собі, сервер про неї «забув».

Докладніше про версії та безпечне зберігання сіда — у розборі генерації TON-гаманця.

DeFAI-ракурс: чому для автономних агентів важливо, де живе приватний ключ

DeFAI — це коли ШІ-агенти самі оперують у DeFi. І тут питання «де живе ключ» перестає бути теорією.

LLM — імовірнісна система. Вона читає дані з блокчейну, з чужих контрактів, з текстів, які їй підсовують. Класична атака — промпт-ін'єкція: в описі жетона або у відповіді стороннього інструмента захована інструкція «переказати всі кошти на адресу X». У кастодіальній моделі, де агент підписує сам, така ін'єкція потенційно призводить до реальної витрати — адже ключ під рукою в того самого агента, якого обдурили. Отруєний контекст, баг у ланцюжку інструментів, скомпрометований хост — будь-який із цих сценаріїв конвертується в підпис, бо середовище саме вміє підписувати.

У некастодіальній моделі атака впирається в стіну: навіть якщо агента переконали зібрати шкідливу транзакцію, build_swap_tx поверне лише непідписане повідомлення. Воно нічого не рухає, поки власник ключа не підпише його у своєму гаманці — а на цьому кроці користувач бачить адресу отримувача і суму. Людина (або окрема політика підписання) залишається останнім рубежем.

Це не означає, що автономія — зло. Це означає, що автономія і контроль ключів — різні осі, і вибирати треба усвідомлено. Більше про некастодіальні свопи для агентів — у матеріалі про агентський своп на TON.

Ризики обох моделей: автономна витрата проти ручного підпису

Чесно про обидві сторони, без перекосу.

Кастодіальна модель (@ton/mcp):

• Плюс: агент справді автономний — платить і оперує сам, ланцюжки операцій ідуть без зупинок.
• Плюс: split-key обмежує агента (owner-ключ на боці користувача) — це не «повний доступ до всього».
• Плюс: офіційність Foundation, зручно для сценаріїв без людини в циклі (підписки, автовиплати, NFT/DNS).
• Ризик: операційний ключ підпису лежить там само, де працює керована текстом LLM — промпт-ін'єкція або галюцинація може призвести до реальної витрати.
• Ризик: помилка агента (неправильний парсинг суми/адреси) виконується без ручного бар'єра.

Некастодіальна модель (TONNode):

• Плюс: приватний ключ ніколи не покидає користувача — сервер фізично не може ані списати, ані вивести.
• Плюс: кожна витрата проходить візуальне підтвердження в гаманці — останній рубіж проти помилки агента та ін'єкції.
• Обмеження: потрібен крок підпису гаманцем — повністю «безлюдний» автопілот 24/7 так не побудувати.
• Обмеження: користувач сам відповідає за збереження мнемоніки, яку віддав generate_wallet (сервер її не зберігає — відновлювати нікому).

Окремо про кросчейн, де ризик-модель найпомітніша. У TONNode TON завжди джерело, обмін іде через атомарний HTLC-ескроу:

• get_crosschain_quote — котирування.
• build_crosschain_swap_tx — непідписана HTLC-ескроу транзакція плюс секрет.
• track_crosschain_swap — фази угоди в обох мережах.
• disclose_crosschain_secret — розкрити секрет для розрахунку після перевірки готовності он-чейн.
• build_crosschain_refund — повернення коштів із завислого ескроу, якщо контрагент не завершив обмін.

Наявність build_crosschain_refund — прямий наслідок некастодіальності: раз ключ і секрет у користувача, у нього ж і важіль повернути свої гроші із застряглої угоди, а не «писати в підтримку». Підтримуються Ethereum, Arbitrum, Base, BNB Chain, Polygon, Avalanche. TRON поки не підтримується.

Чесне порівняння: коли який підхід обирати

Критерій	@ton/mcp (кастодіальний)	TONNode (некастодіальний)
Хто тримає ключ	operator-ключ в агента	приватний ключ у користувача
Хто підписує	сервер/агент сам	гаманець користувача
Автономна витрата	так	ні (потрібен підпис)
Кросчейн	ні, лише TON	так, HTLC (TON — джерело)
NFT / DNS	так	ні (у роадмапі)
Формат	локально / HTTP / serverless	локально + hosted-опція
Статус	офіційний пакет Foundation	сторонній open-source (MIT)

Практичний вибір:

Беріть кастодіальний @ton/mcp, якщо:

• потрібна справжня автономія агента — він має витрачати сам, без людини в циклі;
• важливі NFT і DNS у TON;
• важливий офіційний статус Foundation;
• усе відбувається всередині TON — кросчейн не потрібен, а операційні ризики operator-ключа ви усвідомлено приймаєте.

Беріть некастодіальний TONNode, якщо:

• хочете, щоб приватний ключ і підпис залишалися у вас, а кожна витрата підписувалася вручну;
• потрібен кросчейн: TON завжди джерело, атомарний HTLC-ескроу, з поверненням із застряглої угоди;
• потрібна hosted-опція з гарантованою пропускною здатністю і власним ключем;
• хочете open-source пакет (MIT) на нативному ADNL.

Різниця чесна й без пересмикувань: @ton/mcp — кастодіальний і лише TON; TONNode — некастодіальний, з кросчейном і hosted-опцією. Розгорнуте зіставлення функцій — в окремому розборі TONNode проти офіційного TON MCP або на сторінці порівняння з офіційним MCP.

Невелика ремарка про інфраструктуру. Якщо під навантаженням ви використовуєте публічні лайтсервери або публічні HTTP-API (toncenter, tonapi.io), пам'ятайте про реальні ліміти: у разі перевищення прилітає HTTP 429 «Too Many Requests» (без ключа — близько 1 запиту на секунду), а публічні лайтсервери часто відповідають «not ready» або ADNL-таймаутом. Жодних мемних «помилок 228» в API немає — це фольклор ком'юніті, а не код відповіді.

Як спробувати некастодіальний MCP за пару хвилин

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

{
  "mcpServers": {
    "ton": {
      "command": "npx",
      "args": ["-y", "@tonnode/mcp"]
    }
  }
}

Далі попросіть агента людською мовою — з цим безкоштовним конфігом відкритий увесь набір читання:

Покажи баланс адреси EQ... у GRAM, подивись метадані USDT
і дай тверде котирування на своп 10 GRAM в USDT.

Агент викличе get_balance, get_jetton_info і get_swap_quote — і поверне дані, нічого не витрачаючи. Ані підпису, ані руху коштів: читання є читання.

Пакет @tonnode/mcp — open source (MIT), працює за нативним ADNL-протоколом TON, без HTTP-прошарків. Коли знадобляться інструменти, що збирають транзакції (своп, кросчейн, генерація гаманця), — це вже всі 16 інструментів на hosted-ендпоінті, з власним ключем і гарантованою пропускною здатністю:

{
  "mcpServers": {
    "ton": {
      "type": "http",
      "url": "https://mcp.tonnode.io/mcp",
      "headers": { "Authorization": "Bearer tn_live_…" }
    }
  }
}

На hosted-ключі агенту можна дати вже повноцінний некастодіальний сценарій:

Створи новий TON-гаманець версії v5r1 і покажи адресу.
Потім збери своп 10 USDT у GRAM і поверни непідписану транзакцію.

Агент викличе generate_wallet, потім get_swap_quote і build_swap_tx — і поверне вам непідписане повідомлення. Зверніть увагу: на цьому етапі нічого не витрачено. Підпис — ваш окремий, усвідомлений крок. Це і є некастодіальність на практиці.

На всіх тарифах доступні всі 16 інструментів — платите лише за пропускну здатність. Безкоштовний ключ Hobby (60 запитів/хв, назавжди, без картки) видається одразу після входу.

Загальний гайд із підключення MCP до TON — у посібнику з MCP для TON.

---

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

Спробувати некастодіальний MCP безкоштовно — отримати ключ Hobby: tonnode.io/dashboard?plan=hobby