# Hashlock-Tech/hashlock-mcp [Health: Active]

**Category:** 💰 Finance & Fintech  
**Repository:** https://github.com/Hashlock-Tech/hashlock-mcp  
**GitHub Stars:** 0  
**npm Downloads (last month):** 1329  
**Views:** 1  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/hashlock-tech-hashlock-mcp

## Description
Cross-chain OTC trading via sealed-bid RFQ + HTLC atomic settlement. Six tools for AI agents to swap ETH, BTC, and SUI without bridges, custodians, or information leakage. Hosted at hashlock.markets/mcp or local stdio via @hashlock-tech/mcp.

## Tools
Capabilities this server exposes over MCP:

- **list_assets** — Asset registry: every tradeable asset with its chain, symbol and decimals. Reference assets in other tools as "SYMBOL@chain" (e.g. "USDT@ethereum", "BTC@bitcoin").
- **list_open_rfqs** — Browse the public RFQ board (open requests you can respond to with a price). Optional filters.
- **get_rfq** — Details of one RFQ / private order by id.
- **create_rfq** — 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_rfq** — Cancel your own RFQ / private order (before a deal is agreed).
- **respond_to_rfq** — 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.
- **negotiate** — 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.
- **my_rfqs** — Your own RFQs / private orders and their statuses.
- **my_deals** — Your deal threads (negotiations + agreed deals) with current/pending prices.
- **deal_status** — 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_settlement_address** — 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.
- **get_deal_secret** — 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.
- **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.
- **whoami** — 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.
- **fund_leg** — 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.
- **refund_leg** — 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.
- **claim_leg** — 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.

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `npx` (confidence: high):

```json
"mcpServers": {
  "hashlock-mcp": {
    "command": "npx",
    "args": ["-y","@hashlock-tech/mcp"],
    "env": {
      "HASHLOCK_API_URL": ""
    }
  }
}
```

**Requires environment variables:** `HASHLOCK_API_URL` — the values above are empty placeholders; fill in real credentials before running (see the repository for what each one is for).

## Documentation

## What Hashlock-Tech/hashlock-mcp does

Hashlock-Tech/hashlock-mcp connects MCP clients to Hashlock Markets, a platform for cross-chain OTC orders. It supports sealed request-for-quote workflows: an agent can inspect supported assets, view public requests, publish a public RFQ or private fixed-price order, receive quotes, and negotiate within a deal thread.

Once both parties agree on the other side’s price, the platform creates an HTLC swap. The settlement model is designed so each leg is either claimed or refunded after its timelock. The service does not hold trading funds or wallet keys. Swap preimages are generated locally in the stdio package, and only their SHA-256 hashlocks are sent to the service.

## How it works

The package can run locally over stdio or remotely at `https://hashlock.markets/mcp` using Streamable HTTP. Local mode uses the agent’s configured wallet keys for authentication and, when enabled, for on-chain settlement. Remote mode uses wallet authorization and supplies unsigned funding, claim, or refund transactions for signing outside the service.

A typical workflow is:

1. Inspect the asset registry and open RFQs.
2. Create an order or respond to an existing request with a price.
3. Negotiate, accept the other party’s price, and create the deal.
4. Set receive and refund addresses for the relevant chains.
5. Monitor funding, timelocks, and transaction hashes.
6. Retrieve the local deal secret when both legs are funded, then claim or report an out-of-band claim.

Supported mainnet networks include Bitcoin, Ethereum, Base, Robinhood Chain, TRON, and Solana.

## Setup and configuration

Install and launch the npm package with an API base URL:

```bash
HASHLOCK_API_URL=https://hashlock.markets/api npx -y @hashlock-tech/mcp
```

`HASHLOCK_API_URL` is required. With no wallet key or token, the server still supports read-only asset and RFQ browsing. Autonomous local settlement can use `HASHLOCK_EVM_KEY`, `HASHLOCK_TRON_KEY`, `HASHLOCK_BTC_KEY`, or `HASHLOCK_SOLANA_KEY`; `HASHLOCK_TOKEN` provides a ready JWT instead of signing in with a key.

Optional settings cover application share links, EVM and TRON RPC access, and the local secrets file. Use a dedicated wallet containing only the funds intended for trading.

## Tools and capabilities

The MCP interface includes tools for:

- Listing assets and open RFQs, retrieving individual RFQs, and identifying the authenticated account.
- Creating, cancelling, responding to, and negotiating RFQs and private orders.
- Reading deal threads, negotiation history, HTLC state, funding progress, timelocks, and transaction hashes.
- Setting settlement addresses and retrieving the locally stored deal preimage after both swap legs are funded.
- Reporting claims made outside the server.
- Funding, claiming, or refunding a swap leg autonomously in local mode for EVM, TRON, Bitcoin, and Solana.

## Limitations and notes

Remote mode does not sign transactions, store wallet keys, or store the swap preimage. Solana transactions are composed by the service and signed by the agent using the bytes returned to it. Solana wallet ownership may need to be proven before posting, quoting, accepting, or using `whoami` for an order involving Solana.

Accepting a negotiation must name the price being accepted, and an outdated price is refused. A counteroffer or the caller’s own quote counts as that party’s acceptance, so agents should accept the other side’s quoted price. Local signing depends on correctly configured chain keys, settlement addresses, and RPC settings.

_Full upstream README: https://allmcps.com/mcp/hashlock-tech-hashlock-mcp/readme_