A crypto-native team pays people constantly and almost never on a schedule. Two agencies, six KOLs, a security researcher who found something real, a contractor covering one sprint, a market maker and conference sponsorship agreed in a Telegram thread on a Tuesday.

Every one of those payments leaves the same address, and that address is labelled. Anyone can read the monthly KOL budget, price the agency retainer, count how many contractors came and went, and estimate the runway from the outflow. Competitors do this. So does the person about to negotiate with you, which is how a contractor finds out what the last contractor was paid. The wallet is not the problem. What the wallet publishes is.

Introducing Hinkal MCP

Hinkal MCP is a server that exposes Hinkal's private payments as tools to an AI client, over the Model Context Protocol, the open standard for connecting assistants to external systems. In practice that means the user says what should happen, the assistant calls the tool, and the payment settles. There is no dashboard to follow, no external wallet to connect, and no integration work.‍

A payout, start to finish. Fund the wallet provided through the MCP, then pay three vendors 42,000, 31,500 and 18,000 USDC in one instruction. Each of them receives the full amount at the address they already use, and the payout carries no on-chain link back to the wallet that sent it. Whether they were paid together, separately, or at all is not readable from the chain.

The real value sits in the side that makes the actual payment. A KOL is never going to install a shielded wallet to receive a payment, and an agency is not going to open a new account to invoice you. They do not have to. Payment goes out to the ordinary address they gave you, and nothing about Hinkal ever reaches them.

What can the MCP do

- Hold a confidential balance and pay nobody yet: deposit, from your public balance
- Pay one outside address, or a list of them: private_send, from your public balance
- Pay one outside address out of money you shielded earlier: withdraw, from your shielded balance
- Pay another Hinkal user: private_transfer, from your shielded balance
- Fund someone else's shielded balance: deposit_for_other, from your public balance

‍Most payouts use private_send, and it does not need a deposit first. It takes your public balance, routes it through the shielded pool, and schedules a separate payout to each recipient. Nothing on-chain connects the money going in to the money coming out, and each payout can be polled until it settles. deposit parks funds in your own confidential balance, where they sit until you transfer or withdraw them, and it costs gas with no Hinkal fee. Shield your payout budget first and private_send cannot reach it, because it is looking at a balance you just emptied.

Both routes to an outside address break the link, so the choice is about where the money is sitting when you decide to pay. withdraw pays one address out of a balance you shielded earlier, and the withdrawal address is visible but is not linked back to your deposit. private_transfer moves value between two Hinkal users with no on-chain trace of the sender, the recipient, or the amount. Alongside those, the server exposes ordinary public wallet actions, balance reads across every supported chain, and a live enclave attestation. The full tool reference is in the docs.

Fees are charged on top of the payment, not taken out of it. Recipients receive the full amount, which means the balance you pay from has to cover the amount plus the fee. Funding exactly what you intend to pay is the first mistake most people make.‍

MCP and Compliance 

Every transaction that spends shielded funds carries a zero-knowledge proof that those funds are not linked to a blacklisted address, checked against the current Chainalysis blacklist. That covers every private_send payout. The check runs inside the contract rather than as a review afterwards.‍

Setup

Two lines, and there is nothing to connect:

npm i -g @hinkal/mcp

claude mcp add hinkal -- hinkal-mcp

Claude Desktop, Cursor and Codex each take the same server through their own configuration file, documented in the quickstart. Node 18 or later and no other configuration required. A wallet is created on first use and it starts empty. Send it the token you intend to pay with along with the chain's native gas token before your first payment, and export the wallet key to back it up.

Who is the MCP for?

• A small team paying real people out of a hot wallet. The created wallet becomes the spending account while maintaining your company’s privacy.
• Several people on one team who all need to pay. Hinkal Prime, built for permissioned multi-user access, batch payouts and a review queue before anything executes. The MCP creates one wallet per machine and offers no way to share it.
• A treasury on a Safe or a multisig. Hinkal Pay or Hinkal Prime, where your own wallet signs and deposits directly.
• Embedding confidential payments into your own product. The SDK or the API.

The MCP is how the workflow gets demonstrated and how a small team runs it. It is not the production answer for an organisation with a real treasury, and pitching it that way wastes everyone's afternoon.

Get started ->

‍