TON MCP lưu ký vs không lưu ký: ai giữ khóa của agent

Bạn giao cho một AI agent nhiệm vụ swap trên TON. Nó gọi đúng tool, và mười giây sau giao dịch đã nằm trên blockchain — bạn không ký, không mở ví, không xác nhận gì cả. Tiện chứ? Tiện. Giờ thì cũng chính agent đó parse sai prompt của bạn, nhầm trường amount và gửi đi không phải 5 mà là 500 GRAM. Cũng chẳng hỏi ai. Câu hỏi đáng đặt ra trước cú swap đầu tiên chứ không phải sau: rốt cuộc ai đang giữ khóa riêng và ai đặt chữ ký lên giao dịch?

Đó chính là ranh giới giữa hai mô hình MCP server dành cho TON. Ta sẽ mổ xẻ MCP lưu ký đối đầu ví agent không lưu ký một cách cụ thể — kèm config, tool và rủi ro thật của cả hai phía.

MCP lưu ký hay ví agent không lưu ký: ai giữ khóa và ai ký

Trước hết là phần nền. MCP (Model Context Protocol) là chuẩn để các AI agent (Claude, Cursor, ChatGPT/Codex và mọi MCP client khác) gọi tool bên ngoài. Bản thân agent không tự truy cập blockchain được — nó gọi một MCP tool kiểu "cho tôi số dư" hoặc "dựng giao dịch swap", còn MCP server mới làm phần việc thật. Và với blockchain thì mọi thứ quy về đúng một chi tiết kỹ thuật: giao dịch phải được ký bằng khóa riêng.

Tính lưu ký của một agent được quyết định bởi hai thứ:

1. Khóa riêng nằm ở đâu về mặt vật lý — trên server MCP hay ở phía người dùng? Ai nắm nó thì người đó định đoạt tiền.
2. Ai đặt chữ ký — server tự ký hay ví của người dùng ký? Chữ ký là thứ biến ý định thành dòng tiền không thể đảo ngược.

Nếu khóa và chữ ký đều nằm ở phía dịch vụ/agent — đó là mô hình lưu ký (custodial): agent có thể tự tiêu tiền. Nếu khóa nằm ở người dùng, mỗi giao dịch đều do ví của họ ký, còn server chỉ dựng giao dịch chưa ký — đó là mô hình không lưu ký (non-custodial): server về mặt vật lý không có khả năng tiêu tiền của người khác.

Nó giống khác biệt giữa "đưa cho bạn mình cái thẻ ngân hàng kèm mã PIN" và "đưa cho bạn mình tờ ủy nhiệm chi đã điền sẵn, còn mình thì tự ký ở ngân hàng". Cả hai trường hợp người bạn kia đều giúp được việc, nhưng rủi ro thì khác nhau về bản chất. Không mô hình nào "đúng hơn" mô hình nào trong chân không — chúng đưa ra hai điểm cân bằng khác nhau giữa tính tự chủ và quyền kiểm soát. Tiếp theo, hãy xem điều đó thể hiện ra sao trên các sản phẩm cụ thể.

Mô hình lưu ký: @ton/mcp chính thức và split-key

@ton/mcp chính thức từ TON Foundation là một ví agent lưu ký. Nó giữ operator key và tự ký giao dịch. Cơ chế hoạt động là split-key: operator key nằm ở agent, owner key nằm ở người dùng. Tức là agent không toàn quyền (owner key vẫn là đòn bẩy ở phía con người), nhưng trong phạm vi quyền hạn của mình thì nó tiêu tiền mà không cần ký tay từng thao tác.

@ton/mcp làm được gì:

• đọc trạng thái mạng lưới và tài khoản;
• gửi GRAM, jetton và NFT;
• swap qua DEX aggregator;
• tạo và import ví agent;
• đọc NFT và DNS.

Cái nó không làm được: cross-chain — chỉ chạy trong nội bộ TON. Khởi chạy được ở local, qua HTTP hoặc serverless.

Đây là package chính thức của Foundation, và nó có những điểm mạnh thật sự:

• Tự chủ chi tiêu hoàn toàn. Agent chạy trọn chuỗi hành động mà không phải dừng lại chờ xác nhận — đúng thứ cần cho các kịch bản tự chủ thực sự (thuê bao định kỳ, chi trả tự động).
• NFT và DNS có sẵn ngay từ đầu.
• Vị thế chính thức — được Foundation hỗ trợ.

Cái giá của tự chủ thì rõ ràng: operator key sống ngay trong môi trường của agent. Mà agent là một LLM — thứ có thể bị lừa bằng văn bản. Ai kiểm soát được môi trường đó và cấu hình của nó thì cũng kiểm soát luôn chữ ký, trong giới hạn quyền của operator.

Mô hình không lưu ký: TONNode trả về message TonConnect chưa ký

TONNode là MCP server hosted dành cho TON (website tonnode.io) với đúng 16 tool. Ở đây các tool swap, cross-chain và ví đều hoàn toàn không lưu ký: server không bao giờ ký và không lưu tiền lẫn khóa riêng.

Cơ chế rất đơn giản. Thay vì "hãy swap giúp tôi", tool build_swap_tx trả về một message TonConnect chưa ký — một giao dịch đã sẵn sàng, và ví của người dùng (Tonkeeper, MyTonWallet, bất kỳ ví tương thích TonConnect nào) mới là bên đặt chữ ký. Server dựng xong "tờ ủy nhiệm chi", còn chữ ký thì do chính người giữ khóa đặt. Server chỉ thấy dữ liệu công khai: địa chỉ, số tiền, contract đích. Còn khóa riêng thì về nguyên tắc server không hề chạm tới.

Luồng swap điển hình trông như sau:

1. get_swap_quote — báo giá chắc chắn từ DEX (GRAM ⇄ jetton, thanh khoản STON.fi + DeDust qua giao thức Omniston).
2. build_swap_tx — giao dịch chưa ký ứng với báo giá đó.
3. Ví của người dùng ký nó qua TonConnect. Hết.

Prompt cho agent lúc này nghe hết sức bình thường:

Cho tôi báo giá swap 10 GRAM sang USDT, rồi dựng giao dịch
swap cho địa chỉ EQ... của tôi — tôi sẽ tự ký trong ví.

Agent sẽ gọi get_swap_quote, sau đó build_swap_tx, và đầu ra bạn nhận được là một object giao dịch, chứ không phải một khoản tiền đã bị trừ.

Ngay cả việc tạo ví cũng không lưu ký. generate_wallet tạo ví các phiên bản v3r2 / v4 / v5r1 / highload_v3 rồi trả mnemonic, khóa và địa chỉ về cho người dùng — server không lưu chúng. Tạo xong, bạn cầm seed phrase về mình, còn server thì "quên" nó đi.

Chi tiết hơn về các phiên bản ví và cách lưu seed an toàn — trong bài phân tích tạo ví TON.

Góc nhìn DeFAI: vì sao với agent tự chủ, chuyện khóa riêng nằm ở đâu lại quan trọng

DeFAI là khi các AI agent tự mình thao tác trong DeFi. Và ở đây, câu hỏi "khóa nằm ở đâu" không còn là chuyện lý thuyết nữa.

LLM là một hệ thống xác suất. Nó đọc dữ liệu từ blockchain, từ contract của người khác, từ những đoạn văn bản được nhét vào cho nó. Đòn tấn công kinh điển là prompt injection: trong phần mô tả một jetton hoặc trong phản hồi của một tool bên thứ ba có giấu chỉ dẫn "chuyển toàn bộ tiền sang địa chỉ X". Ở mô hình lưu ký, nơi agent tự ký, một injection như vậy hoàn toàn có thể dẫn thẳng tới một khoản chi thật — vì khóa nằm ngay trong tầm tay của chính cái agent vừa bị lừa. Context bị đầu độc, một bug trong chuỗi tool, một host bị chiếm quyền — bất kỳ kịch bản nào trong số đó cũng có thể kết thúc bằng một chữ ký, đơn giản vì chính môi trường đó có khả năng ký.

Ở mô hình không lưu ký, đòn tấn công vấp phải một bức tường: kể cả khi agent bị thuyết phục dựng một giao dịch độc hại, build_swap_tx cũng chỉ trả về một message chưa ký. Nó không làm dịch chuyển thứ gì cho tới khi người giữ khóa ký nó trong ví của mình — mà ở bước đó, người dùng nhìn thấy địa chỉ người nhận và số tiền. Con người (hoặc một chính sách ký riêng biệt) vẫn là chốt chặn cuối cùng.

Điều đó không có nghĩa tự chủ là xấu. Nó có nghĩa là tự chủ và quyền kiểm soát khóa là hai trục khác nhau, và cần chọn một cách có ý thức. Thêm về swap không lưu ký cho agent — trong bài viết về swap bằng agent trên TON.

Rủi ro của cả hai mô hình: chi tiêu tự chủ đối đầu chữ ký thủ công

Nói thẳng về cả hai phía, không thiên vị bên nào.

Mô hình lưu ký (@ton/mcp):

• Điểm cộng: agent thực sự tự chủ — tự trả tiền và tự thao tác, chuỗi hành động chạy liền mạch không ngắt quãng.
• Điểm cộng: split-key giới hạn agent (owner key ở phía người dùng) — đây không phải kiểu "toàn quyền với mọi thứ".
• Điểm cộng: vị thế chính thức của Foundation, tiện cho những kịch bản không có người trong vòng lặp (thuê bao định kỳ, chi trả tự động, NFT/DNS).
• Rủi ro: khóa ký vận hành nằm đúng chỗ mà một LLM điều khiển bằng văn bản đang chạy — prompt injection hoặc ảo giác có thể dẫn tới một khoản chi thật.
• Rủi ro: sai sót của agent (parse nhầm số tiền/địa chỉ) được thực thi mà không có rào chắn thủ công nào.

Mô hình không lưu ký (TONNode):

• Điểm cộng: khóa riêng không bao giờ rời khỏi người dùng — server về mặt vật lý không thể trừ tiền cũng không thể rút tiền đi.
• Điểm cộng: mỗi khoản chi đều đi qua bước xác nhận trực quan trong ví — chốt chặn cuối cùng trước sai sót của agent và trước injection.
• Giới hạn: luôn cần một bước ký bằng ví — muốn dựng autopilot 24/7 hoàn toàn "không người" thì cách này không làm được.
• Giới hạn: người dùng tự chịu trách nhiệm giữ mnemonic mà generate_wallet đã trả về (server không lưu nó — không có ai để khôi phục hộ).

Nói riêng về cross-chain, nơi mô hình rủi ro lộ ra rõ nhất. Ở TONNode, TON luôn là nguồn, còn việc trao đổi đi qua HTLC escrow nguyên tử:

• get_crosschain_quote — báo giá.
• build_crosschain_swap_tx — giao dịch HTLC escrow chưa ký kèm secret.
• track_crosschain_swap — các pha của giao dịch trên cả hai mạng.
• disclose_crosschain_secret — tiết lộ secret để thanh toán sau khi kiểm tra trạng thái sẵn sàng on-chain.
• build_crosschain_refund — hoàn tiền từ escrow bị treo, nếu đối tác không hoàn tất việc trao đổi.

Sự tồn tại của build_crosschain_refund là hệ quả trực tiếp của tính không lưu ký: một khi khóa và secret nằm ở người dùng, thì đòn bẩy để lấy lại tiền của mình từ một giao dịch bị kẹt cũng nằm ở chính họ, chứ không phải "viết thư cho bộ phận hỗ trợ". Các mạng được hỗ trợ: Ethereum, Arbitrum, Base, BNB Chain, Polygon, Avalanche. TRON hiện chưa được hỗ trợ.

So sánh thẳng thắn: khi nào nên chọn cách tiếp cận nào

Tiêu chí	@ton/mcp (lưu ký)	TONNode (không lưu ký)
Ai giữ khóa	operator key ở agent	khóa riêng ở người dùng
Ai ký	server/agent tự ký	ví của người dùng
Chi tiêu tự chủ	có	không (cần chữ ký)
Cross-chain	không, chỉ TON	có, HTLC (TON là nguồn)
NFT / DNS	có	không (nằm trong roadmap)
Hình thức	local / HTTP / serverless	local + tùy chọn hosted
Trạng thái	package chính thức của Foundation	bên thứ ba, open-source (MIT)

Lựa chọn trong thực tế:

Hãy chọn @ton/mcp lưu ký, nếu:

• bạn cần agent tự chủ thật sự — nó phải tự tiêu tiền, không có người trong vòng lặp;
• NFT và DNS trên TON là quan trọng với bạn;
• vị thế chính thức của Foundation là quan trọng với bạn;
• mọi thứ diễn ra trong nội bộ TON — không cần cross-chain, còn rủi ro vận hành của operator key thì bạn chấp nhận một cách có ý thức.

Hãy chọn TONNode không lưu ký, nếu:

• bạn muốn khóa riêng và chữ ký ở lại phía mình, còn mỗi khoản chi đều được ký thủ công;
• bạn cần cross-chain: TON luôn là nguồn, HTLC escrow nguyên tử, kèm cơ chế hoàn tiền từ giao dịch bị treo;
• bạn cần tùy chọn hosted với băng thông được đảm bảo và key riêng;
• bạn muốn một package open-source (MIT) chạy trên ADNL gốc.

Khác biệt là sòng phẳng, không bóp méo: @ton/mcp — lưu ký và chỉ TON; TONNode — không lưu ký, có cross-chain và có tùy chọn hosted. Đối chiếu tính năng chi tiết — trong bài phân tích riêng TONNode đối đầu TON MCP chính thức hoặc trên trang so sánh với MCP chính thức.

Một lưu ý nhỏ về hạ tầng. Nếu chạy dưới tải thật mà bạn dùng lightserver công khai hoặc HTTP API công khai (toncenter, tonapi.io), hãy nhớ tới những giới hạn có thật: khi vượt ngưỡng bạn sẽ nhận HTTP 429 "Too Many Requests" (không có key thì vào khoảng 1 request mỗi giây), còn lightserver công khai thì hay trả về "not ready" hoặc timeout ADNL. Không hề có "lỗi 228" kiểu meme nào trong API cả — đó là chuyện truyền miệng trong cộng đồng, không phải mã phản hồi.

Cách thử MCP không lưu ký chỉ trong vài phút

Cách nhanh nhất để cảm nhận khác biệt là chạy local rồi đưa cho agent một prompt đơn giản. Config công khai với trọn bộ tool đọc dữ liệu, miễn phí và không cần thẻ:

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

Sau đó cứ nhờ agent bằng ngôn ngữ tự nhiên — trên config miễn phí này toàn bộ nhóm tool đọc dữ liệu đều mở:

Cho tôi xem số dư GRAM của địa chỉ EQ..., xem metadata của USDT
và cho một báo giá chắc chắn để swap 10 GRAM sang USDT.

Agent sẽ gọi get_balance, get_jetton_info và get_swap_quote — rồi trả về dữ liệu mà không tiêu gì cả. Không chữ ký, không dịch chuyển tiền: đọc thì vẫn chỉ là đọc.

Package @tonnode/mcp là open source (MIT), chạy theo giao thức ADNL gốc của TON, không có lớp trung gian HTTP. Khi cần tới nhóm tool dựng giao dịch (swap, cross-chain, tạo ví), bạn sẽ dùng trọn bộ 16 tool trên endpoint hosted, với key riêng và băng thông được đảm bảo:

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

Với key hosted, bạn có thể giao cho agent một kịch bản không lưu ký đầy đủ:

Tạo một ví TON mới phiên bản v5r1 và cho tôi xem địa chỉ.
Sau đó dựng swap 10 USDT sang GRAM và trả về giao dịch chưa ký.

Agent sẽ gọi generate_wallet, sau đó get_swap_quote và build_swap_tx — rồi trả về cho bạn một message chưa ký. Chú ý: ở thời điểm này chưa có gì bị tiêu cả. Chữ ký là một bước riêng, có ý thức, do chính bạn thực hiện. Đó chính là tính không lưu ký trong thực tế.

Trên mọi gói cước đều có đủ 16 tool — bạn chỉ trả tiền cho băng thông. Key Hobby miễn phí (60 request/phút, vĩnh viễn, không cần thẻ) được cấp ngay sau khi đăng nhập.

Hướng dẫn chung về việc kết nối MCP với TON — trong hướng dẫn MCP cho TON.

---

Cái khóa có thể tiêu tiền của bạn thì không nên nằm cạnh một mô hình có thể bị lừa chỉ bằng một đoạn văn bản. Nếu với kịch bản của bạn, chi tiêu tự chủ mới là thứ quan trọng hơn — @ton/mcp lưu ký giải quyết đúng bài toán đó một cách sòng phẳng. Còn nếu điều quan trọng hơn là chữ ký phải ở lại phía bạn — hãy bắt đầu với TONNode không lưu ký và tự quyết định xem ranh giới tin cậy nên đặt ở đâu.

Thử MCP không lưu ký miễn phí — nhận key Hobby: tonnode.io/dashboard?plan=hobby