Phantom은 이번 달에 AI 에이전트가 Phantom 지갑을 직접 운영할 수 있게 해주는 MCP 서버를 출시했습니다. 이 서버는 Solana, Ethereum, Bitcoin 및 Sui 전반에 걸쳐 get_wallet_addresses, sign_message, sign_transaction, transfer_tokens, buy_token의 다섯 가지 도구를 노출합니다. 기본적으로 트랜잭션을 먼저 시뮬레이션하고 예상되는 자산 변경 사항을 반환한 다음, 무언가를 브로드캐스트하기 전에 확인을 기다립니다.

이것은 정말 유용한 인프라 조각이며, 우리가 구축하는 네 개의 체인을 모두 다루고 있다는 우연의 일치가 있습니다. 따라서 카테고리에 대해 정확하게 아는 좋은 시기입니다. 왜냐하면 '에이전트가 이제 체인 간 토큰을 스왑할 수 있다'와 '에이전트가 이제 낯선 사람과 크로스체인 거래를 정산할 수 있다'는 들으면 동일하지만 실제로는 그렇지 않기 때문입니다.

지갑 MCP가 에이전트에게 실제로 제공하는 것

원시적인 수준으로 단순화하면, 지갑 MCP는 에이전트를 서명자(signer)로 만듭니다. 에이전트는 자신의 주소를 조회하고, 메시지에 서명하며, 트랜잭션에 서명하고 전송하고, 토큰을 이동시키고, 토큰을 구매할 수 있습니다. 이 모든 것이 1인칭 행동입니다. 에이전트가 결정하고, 에이전트가 서명하고, 에이전트의 자산이 움직입니다.

이것은 에이전트 경제가 필요로 했던 빠진 손(missing hand)이었습니다. 지난 한 해 동안 대부분의 경우, 에이전트는 가치에 대해 추론할 수는 있었지만 그것을 만질 수는 없었고—여전히 인간이 각 단계를 승인해야 했습니다. 지갑 MCP는 이 간극을 메웁니다. 도구에 대한 모델의 추론(Phantom의 문서는 표준 MCP-client 패턴을 보여줍니다)과 결합하여, 에이전트는 키를 보유하고 자체적으로 실행할 수 있습니다. 스택의 지갑 레이어가 채워지고 있는 것입니다.

'서명'이 멈추고 '정산'이 시작되는 곳

이제 거래의 양쪽에 두 명의 에이전트를 배치해 봅시다. Agent A는 BTC를 가지고 있고 ETH를 원합니다. Agent B는 ETH를 가지고 있고 BTC를 원합니다. 그들은 서로를 신뢰하지 않습니다. 서명자 도구만을 사용하여 과정을 설명해 보겠습니다:

1. Agent A가 서명하고 자신의 BTC를 전송합니다.
2. Agent A는 이제 Agent B가 ETH를 보내주기를 기다립니다.

2단계가 바로 전체 문제입니다. 서명자(signer)는 Agent B의 부분과 Agent A의 부분을 연결해 주지 못합니다. sign_transaction은 하나의 자산을 한 방향으로 이동시키며, 일단 확정되면 되돌릴 수 없습니다. 지갑은 '내 자산을 밀어내는 것'에 매우 능숙합니다. 반대편에서 무언가가 돌아올지에 대해서는 아무런 의견이 없습니다. 두 번의 전송 사이에는 한쪽 당사자가 노출되는 시간 창(window)이 존재하며, 실제로 이 시간 창 때문에 오늘날의 에이전트 거래 경로는 수탁자(custodian), 브릿지(bridge), 또는 심판을 거치는 에스크로(escrow-with-judge)를 통해 이루어집니다. 그 '누군가'가 바로 허니팟(honeypot)입니다.

이는 Phantom에 대한 비난이 아닙니다. 지갑은 거래 상대방의 부분을 보장하도록 설계되지 않았습니다. 그것은 다른 레이어의 문제입니다.

서명 위에 추가되는 정산 기능

원자성 정산(Atomic settlement)은 양쪽 부분(both legs)을 단일 비밀에 묶습니다. 구체적으로, 해시 시간 잠금 계약(Hash-Time-Locked Contract, HTLC)이 있습니다:

• 양쪽 부분이 동일한 해시 H = SHA-256(secret)에 잠깁니다.
• 어느 쪽이든 한 부분을 청구하려면 secret을 공개해야 하며, 이는 다른 부분을 잠금 해제합니다.
• 시간 제한(timelock) 만료 전에 아무도 청구하지 않으면 양쪽 부분이 환불됩니다.

서명자가 제공할 수 없는 속성이 바로 여기서 나옵니다. 거래는 양쪽 모두에서 완료되거나, 아니면 양쪽 모두에서 취소됩니다. Agent A의 BTC가 사라지고 Agent B의 ETH가 도착하지 않는 상태는 존재하지 않습니다. 왜냐하면 간극(gap)을 붙잡아 둘 수 있는 수탁자가 없기 때문입니다. - 암호학이 '붙잡아 두는' 역할을 합니다. 당신의 돈은 상대방의 돈이 도착할 때까지 절대 지갑에서 나가지 않습니다.

따라서 이 두 도구는 경쟁하기보다는 깔끔하게 결합됩니다. 지갑 MCP는 에이전트가 자신의 부분을 _서명_하는 방식입니다. 정산 프로토콜은 낯선 사람들 사이에서 _부분 쌍(pair of legs)_을 안전하게 만드는 것입니다. 당신은 둘 다를 원합니다. 하나는 손이고, 다른 하나는 악수입니다.

스택 관점

좀 더 넓게 시야를 가져가는 것이 중요합니다. 왜냐하면 Phantom은 이제 명확해진 패턴에 놓이는 또 하나의 조각이기 때문입니다:

• 지갑(Wallets): 에이전트가 키를 보유하고 서명할 수 있도록 합니다 - Phantom의 MCP, MetaMask의 에이전트 지갑, Coinbase for Agents.
• 레일(Rails): 에이전트가 한 방향으로 가치를 빠르게 이동시킬 수 있도록 합니다 - 1억 6천만 건 이상의 결제를 처리한 x402.
• 마켓플레이스와 평판(Marketplaces and reputation): 에이전트가 누구와 거래할지 알 수 있도록 합니다 - OKX.AI, ERC-8004 아이덴티티.
• 정산(Settlement): 서로 신뢰하지 않는 두 에이전트가 _거래_를 완료할 수 있도록 합니다 - 두 개의 자산, 두 방향, 교환 순간에 중개자가 없습니다.

앞의 세 가지는 빠르게 채워지고 있으며, 대부분 가치가 손을 거치는 정확한 순간에 커스터디얼(custodial)하거나 중개되는 형태입니다. 신뢰 최소화된 크로스체인 정산 좌석이 아직 열려 있는 부분입니다. 이것이 바로 우리가 구축하고 있는 영역입니다: 봉인 입찰 RFQ(sealed-bid RFQ)와 HTLC 원자성 정산을 결합하여, 브릿지나 커스터디언 없이 에이전트에게 MCP 서버로 노출하는 방식입니다.

현재 상황을 명확하게 말씀드리겠습니다. 이더리움 메인넷은 오늘 엔드투엔드로 라이브 상태입니다. Sui 컨트랙트는 배포되어 CLI 테스트가 진행 중이며, 게이트웨이 와이어링 작업이 진행되고 있지만 아직 에이전트를 위한 메인넷 라이브 상태는 아닙니다. 비트코인은 시그네트(signet)에서 검증되었고, 메인넷은 대기 중입니다.

Docs 및 6가지 도구 정산 MCP: [https://hashlock.markets/docs?utm_source=devto&utm_medium=article&utm_campaign=2026-07-15-wallet-signer-vs-settlement-layer]

프로토콜을 공식적으로 정리한 학술적 버전의 논증은 저희 SSRN 논문에서 확인할 수 있습니다: [https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722]

빌더들에게 질문합니다: 에이전트들이 자체 지갑을 갖게 된다면, 정산 보증은 어디에 위치해야 한다고 생각하십니까? 각 지갑 내부인가요, 아니면 그 아래 모든 것을 아우르는 공유 프로토콜 레이어여야 할까요? 여러분이라면 어디를 경계로 설정할지 궁금합니다.