Phantom shipped an MCP server this month that lets an AI agent operate a Phantom wallet directly. It exposes five tools - get_wallet_addresses, sign_message, sign_transaction, transfer_tokens, buy_token - across Solana, Ethereum, Bitcoin and Sui. By default it simulates a transaction first, returns the expected asset changes, and waits for a confirmation before it broadcasts anything.
This is a genuinely useful piece of infrastructure, and it happens to cover the same four chains we build for. So it's a good moment to be precise about categories, because "an agent can now swap tokens across chains" and "an agent can now settle a cross-chain trade with a stranger" sound identical and are not.
What a wallet MCP actually gives an agent
Strip it to the primitive: a wallet MCP turns an agent into a signer. The agent can look up its addresses, sign a message, sign and send a transaction, move tokens, and buy a token. Every one of those is a first-person action. The agent decides, the agent signs, the agent's asset moves.
That's the missing hand the agent economy needed. For most of the last year, agents could reason about value but couldn't touch it - a human still had to approve each step. A wallet MCP closes that. Combined with a model reasoning over the tools (Phantom's docs show the standard MCP-client pattern), an agent can hold keys and execute on its own. The wallet layer of the stack is filling in.
Where "sign" stops and "settle" begins
Now put two agents on opposite sides of a trade. Agent A has BTC and wants ETH. Agent B has ETH and wants BTC. They don't trust each other. Walk it through with signer tools only:
- Agent A signs and sends its BTC.
- Agent A now waits for Agent B to send ETH.
Step 2 is the whole problem. Nothing in a signer binds Agent B's leg to Agent A's. sign_transaction moves one asset, one direction, and it's irreversible the moment it confirms. A wallet is very good at "push my asset out." It has no opinion about whether anything comes back. Between the two sends there is a window where one party is exposed, and in practice that window is why today's agent trades route through a custodian, a bridge, or an escrow-with-judge - somebody who holds the money while it clears. That somebody is the honeypot.
This isn't a knock on Phantom. A wallet is not supposed to guarantee a counterparty's leg. That's a different layer.
What settlement adds on top of signing
Atomic settlement binds both legs to a single secret. Concretely, a hash-time-locked contract (HTLC):
- Both legs lock to the same hash
H = SHA-256(secret). - Whoever claims one leg must reveal the
secret, which unlocks the other leg. - If nobody claims before the timelock expires, both legs refund.
The property that a signer can't provide falls straight out of that: the trade either completes on both sides or unwinds on both sides. There is no state where Agent A's BTC is gone and Agent B's ETH never arrives. No custodian holds the gap, because there is no gap to hold - the cryptography does the holding. Your money never leaves your wallet until theirs arrives.
So the two tools compose cleanly rather than compete. A wallet MCP is how an agent signs its leg. A settlement protocol is what makes the pair of legs safe between strangers. You want both. One is the hand; the other is the handshake.
The stack view
It's worth zooming out, because Phantom is one more piece landing in a pattern that's now obvious:
- Wallets so an agent can hold keys and sign - Phantom's MCP, MetaMask's agent wallet, Coinbase for Agents.
- Rails so an agent can move value one direction, fast - x402, which has cleared over 160M payments.
- Marketplaces and reputation so an agent knows who to transact with - OKX.AI, ERC-8004 identity.
- Settlement so two agents who don't trust each other can complete a trade - two assets, two directions, no intermediary at the moment of exchange.
The first three are filling in fast, and mostly custodial or intermediated at the exact instant value changes hands. The trust-minimized cross-chain settlement seat is the one still open. That's the seat we're building for: sealed-bid RFQ plus HTLC atomic settlement, exposed to agents as an MCP server, no bridge and no custodian.
Where we actually are, stated plainly: Ethereum mainnet is live end-to-end today. Sui contracts are deployed and CLI-tested, with gateway wiring in progress - not mainnet-live for agents yet. Bitcoin is validated on signet, mainnet pending. "Rails ready, trains coming" - and we'd rather be exact about that than round up.
Why the distinction matters if you're building agents
If you're wiring an autonomous agent to touch value, the practical takeaway is to separate two questions you might otherwise merge: can my agent sign and move its own assets? and what guarantees the other side of a trade with someone I don't trust? A wallet MCP answers the first. It does not answer the second, and no amount of simulation-before-signing changes that, because simulation checks your own transaction, not the counterparty's follow-through. For same-party operations, a signer is the whole answer. For a trade between strangers, you need something that binds both legs.
Docs and the six-tool settlement MCP: https://hashlock.markets/docs?utm_source=devto&utm_medium=article&utm_campaign=2026-07-15-wallet-signer-vs-settlement-layer
The academic version of the argument, with the protocol worked out formally, is in our SSRN paper: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722
Question for the builders: as agents get their own wallets, where do you think the settlement guarantee should live - inside each wallet, or as a shared protocol layer underneath all of them? Curious how you'd draw the line.
Top comments (0)