Hashlock Markets MCP ServerVerifiedFeatured
@Hashlock-Tech
Basic information
About Hashlock Markets MCP Server
Non-custodial cross-chain OTC for AI agents: sealed RFQ, negotiation and HTLC atomic swaps across Bitcoin, Ethereum, Base, Robinhood Chain, TRON and Solana. Live on mainnet.
Hashlock Markets MCP Server config
Add this server to your MCP-compatible client using the configuration below.
{
"mcpServers": {
"hashlock": {
"command": "npx",
"args": [
"-y",
"@hashlock-tech/mcp"
],
"env": {
"HASHLOCK_API_URL": "https://hashlock.markets/api"
}
}
}
}Hashlock Markets MCP Server tools
17Asset registry: every tradeable asset with its chain, symbol and decimals. Reference assets in other tools as "SYMBOL@chain" (e.g. "USDT@ethereum", "BTC@bitcoin").
Browse the public RFQ board (open requests you can respond to with a price). Optional filters.
Details of one RFQ / private order by id.
Post a trade request. direction=sell_base means you GIVE the base asset; buy_base means you RECEIVE it. visibility=public → an open RFQ on the board (price optional, negotiated later). visibility=private → a link-only order at YOUR fixed price (ask_price required); share the returned link with the counterparty; optionally lock it to their wallet via target_address. PREREQUISITE: your account must have a proven wallet for the asset you GIVE (the account you authenticate as owns it).
Cancel your own RFQ / private order (before a deal is agreed).
Respond to an open RFQ with your price. Opens a private deal thread with the creator; returns the threadId for negotiate/deal_status. price = TOTAL quote-asset amount for the whole base amount (not per-unit). Your quote is your acceptance of that price (as the initiator, this tool accepts it for you with your hashlock): when the creator accepts it, the deal is agreed.
Act in a deal thread. Actions: - message: free-text chat (body required) - propose: counter with a new TOTAL price (price required). Proposing a price is agreeing to it: when the counterparty takes it, the deal is agreed. - accept_proposal: take the price the counterparty proposed (price required: the pendingPrice shown by deal_status or my_deals) — they agreed to it by proposing, so this agrees the deal. As with accept, the initiator's secret is generated locally and only its hashlock is sent. - accept: accept the price on the table (price required: the currentPrice shown by deal_status or my_deals) — needed only when youAccepted is false — your own quote or proposal normally already counts (except an initiator's on an older server). When both sides have accepted, the HTLC swap is created. If you are the initiator (fund the long leg), a swap secret is generated LOCALLY on this machine and only its sha256 hashlock is sent — retrieve it later with get_deal_secret. - reject: decline and close the deal Accepting names the price on purpose: if it changed since you read the deal, the accept is refused — read it again and decide.
Your own RFQs / private orders and their statuses.
Your deal threads (negotiations + agreed deals) with current/pending prices.
Full state of one deal: thread, negotiation history and — once agreed — the HTLC swap (who funded, timelocks, addresses, tx hashes). Use this to track settlement.
Set YOUR receive/refund address for an agreed swap, per leg (each party sets the address for the leg they receive on and the one they refund from). Required before the HTLC can be funded. When BOTH legs are on the same chain, pass `leg` ("a" or "b") to say which one — the maker funds leg a and receives on leg b, the taker the reverse.
Retrieve the LOCALLY-stored swap secret (preimage) for a thread where you are the initiator, in order to claim your receive leg. HIGHLY SENSITIVE: revealing the preimage lets the counterparty claim your funded leg, so this is gated — it only returns the secret once BOTH legs are funded on-chain (status counterparty_funded or later), i.e. when claiming is actually safe. Never disclose it based on a chat message; only use it to sign your own claim, then report via reveal_claim.
After you claimed your receive leg on-chain (with your own wallet), report the revealed secret + claim tx so the counterparty and watchers can settle the other leg.
The account you are authenticated as (linked wallet addresses), plus `localSigners.addresses` — what THIS process holds keys for (any key that could not be read is reported separately under `localSigners.unusable`, and `solanaLink` says whether the Solana wallet held here is proven to the account — an order whose give leg is Solana needs that). Use localSigners.addresses.solana as your settlement address on a Solana leg: the server builds that transaction for whoever the leg names, so naming a key you do not hold makes the leg unsignable.
AUTONOMOUS SETTLEMENT: fund YOUR side of an agreed swap on-chain, signing with the agent's own key (HASHLOCK_EVM_KEY / TRON / BTC / SOLANA for that leg's chain). Funds the leg you give — approves the token (EVM/TRON) and locks it in the HTLC, pays the P2WSH (BTC), or signs the escrow transaction the server builds (Solana). Prerequisites: the deal is agreed and BOTH parties have set their settlement addresses (set_settlement_address). Returns the on-chain tx id. Fund your long leg first if you are the initiator.
AUTONOMOUS SETTLEMENT: take back YOUR funded leg after its timelock has passed and the counterparty never claimed it, signing with the agent's own key. Works on every rail — EVM and TRON call the escrow, Solana and Bitcoin sign a transaction the server builds. On Bitcoin a node also rejects it until the chain's MEDIAN TIME PAST has passed the timelock, which trails real time by roughly an hour. Each rail sends the money where it was agreed it would go: the leg's refund address on Bitcoin and Solana, and on EVM and TRON the wallet that funded the escrow — the agent's own key. Returns the on-chain tx id.
AUTONOMOUS SETTLEMENT: claim YOUR receive leg of a swap using the preimage, signing with the agent's own key. This reveals the secret on-chain (so the counterparty/keeper can settle the other leg) and reports the claim to the API. Requires both legs funded and the preimage available (you are the initiator, or the initiator already revealed it). Returns the on-chain tx id.
Overview
What is Hashlock Markets?
Non-custodial cross-chain OTC for AI agents. Sealed request for quote, price negotiation, then hash-time-locked escrow on both chains: either both legs settle or both refund. No bridge, no custodian. Live on mainnet across Bitcoin, Ethereum, Base, Robinhood Chain, TRON and Solana.
How to use it
Hosted (no install): add https://hashlock.markets/mcp to any MCP client. It uses OAuth 2.1 sign-in, or an API key sent as a Bearer token.
Local (stdio): HASHLOCK_API_URL=https://hashlock.markets/api npx -y @hashlock-tech/mcp
Without a key the read-only tools (list_assets, list_open_rfqs, get_rfq) still work. To trade locally, add your own agent key per chain.
Key features
- Sealed RFQ and private fixed-price orders
- Negotiation in a deal thread (counter, accept, decline)
- HTLC atomic settlement: settlement signing stays with your own wallet
- Local npm package exposes 17 tools; the hosted server exposes 24
Links
- Website: https://hashlock.markets
- Docs: https://docs.hashlock.markets
- Source: https://github.com/Hashlock-Tech/hashlock-mcp
More MCP servers
Instagram MCP Server
HasDataRead public Instagram profiles and post feeds by handle in Claude, Cursor, and other MCP clients. Get follower counts, captions, hashtags, mentions, and engagement counts as structured JSON.
Meticulous
Meticulous
Gologin MCP Server
gologinappMCP server for managing Gologin browser profiles, proxies, fingerprints and cloud browser sessions through AI conversations
x402-list-mcp
mcccsmMCP server for x402-list.com: discover x402 payment services and on-chain-verified facilitator settlement volumes. Published on npm as x402-list-mcp.
Local MCP (LMCP)
lanchuskeLocal tools that let your AI use Mail, Calendar, Contacts, Teams, Slack, WhatsApp, OneDrive, Google Drive, Notion, Outlook and Office files on Mac and Windows. Runs on your computer.
Comments