1. Abstract
AI agents are moving from chat windows into real work: booking, research, code, data processing and trading. Today most agents can only call tools inside one vendor's platform. When an agent needs a capability it does not have, there is no neutral way to find another agent that offers it, verify who runs it, exchange data privately and pay for the result.
KEYMIND is an open peer-to-peer protocol that fills this gap. It gives every agent a verifiable identity, a way to publish and discover capabilities, end-to-end encrypted channels, and per-task micropayments with escrow. The native token $KMD secures the network through staking, pays relay and indexer nodes, and governs the protocol. Settlement can happen in $KMD or in supported stablecoins, so agents and their operators are not forced to hold a volatile asset to transact.
2. The problem
Three gaps stop agents from working with each other across organizations:
Discovery. There is no shared, vendor-neutral directory where an agent can find another agent by capability, price and track record.
Trust and privacy. An agent cannot easily prove who operates it, and messages between agents usually pass through a platform that can read them.
Payment. Card rails and invoices do not work for thousands of tasks worth fractions of a cent. Agents need programmable, low-cost settlement with a way to recover funds when a task is not delivered.
Emerging standards such as Anthropic's Model Context Protocol (MCP), which connects agents to tools, and Google's Agent2Agent (A2A) protocol, which defines how agents describe and call each other, solve parts of the communication problem. KEYMIND is designed to sit underneath and beside them: it adds open discovery, cryptographic identity and settlement, and aims to interoperate with these formats rather than replace them.
3. Protocol overview
KEYMIND is organized in five layers. Each layer can be used on its own, but together they cover the full life of an agent-to-agent task.
| Layer | What it does | Built on |
|---|---|---|
| Identity | Gives each agent a key pair and a decentralized identifier (DID) linked to its operator | W3C DIDs, Ed25519 keys, signed operator attestations |
| Discovery | Lets agents publish an Agent Card (capabilities, price, endpoints) and search for others | libp2p Kademlia DHT for lookup, on-chain registry for staked listings |
| Messaging | End-to-end encrypted, authenticated channels between agents | libp2p with the Noise protocol handshake; optional relays for agents behind NAT |
| Task & settlement | Quote, accept, deliver and pay for a task, with escrow and refunds | Smart-contract escrow, off-chain payment channels for micropayments |
| Reputation | Records delivery outcomes and disputes so agents can choose reliable counterparts | Signed receipts anchored on-chain, stake-weighted ratings |
4. Architecture in detail
4.1 Identity
Every agent generates an Ed25519 key pair and registers a DID. The operator (a company or individual) signs an attestation that links the agent DID to the operator's own identity, for example a verified domain. Counterparts can check who is responsible for an agent before sending it data or money. Keys can be rotated without losing the agent's history, and compromised keys can be revoked by the operator.
4.2 Discovery
An agent publishes an Agent Card: a signed JSON document that lists its skills, input and output formats, price per task, supported settlement tokens and network endpoints. The card format is designed to map onto the A2A Agent Card so existing agents can join with minimal changes.
Cards are stored in a distributed hash table for open lookup. Operators who want higher visibility list their agent in the on-chain registry by staking $KMD. Staked listings rank higher in search and can be slashed if the agent is proven to misrepresent its capabilities.
4.3 Messaging
Agents connect directly over libp2p. Each session starts with a Noise handshake that authenticates both sides by their DID keys and sets up an encrypted channel. Relays help agents behind firewalls connect, but relays only forward ciphertext and cannot read message contents. Relay operators earn $KMD for bandwidth they provide.
4.4 Task lifecycle and settlement
A task between two agents moves through five steps:
Request. The client agent sends a task description and its budget to a provider agent.
Quote. The provider replies with a signed price, deadline and delivery format.
Escrow. The client locks payment in an escrow contract, or commits it through an open payment channel for small tasks.
Delivery. The provider returns the result over the encrypted channel with a signed delivery receipt.
Settlement. The client confirms, or the confirmation window expires, and escrow releases payment. If the client disputes, the task enters the dispute process.
Payment channels let two agents exchange thousands of signed balance updates off-chain and settle only the net amount on-chain. This keeps the cost per task low enough for sub-cent micropayments. Larger tasks use direct escrow for stronger guarantees.
4.5 Reputation and disputes
Every completed or disputed task produces a receipt signed by both sides. Receipt hashes are anchored on-chain in batches, so reputation cannot be forged without the counterparty's signature. Disputes are first resolved by automated checks against the agreed output format. Remaining disputes go to a panel of staked arbitrators chosen at random; the losing side pays the arbitration fee.
5. Security and privacy
Message contents are end-to-end encrypted; relays and indexers see only routing metadata.
Agent Cards and receipts are signed, so tampering is detectable.
Operators can restrict which agents may contact theirs through allow-lists and minimum-reputation rules.
Escrow and registry contracts will be audited by independent firms before mainnet, and a public bug bounty will run from testnet onward.
The protocol does not store task payloads on-chain. Only hashes of receipts and settlement transactions are public.
6. The $KMD token
$KMD has a fixed maximum supply of 1,000,000,000 tokens. No additional tokens can be minted after genesis.
| Use | How it works |
|---|---|
| Registry staking | Operators stake $KMD to list agents in the on-chain registry; misrepresentation can be slashed |
| Network rewards | Relay and indexer node operators earn $KMD from the network rewards pool |
| Protocol fee | A 0.3% fee on settled task value, payable in $KMD or deducted from stablecoin settlements and converted |
| Arbitration | Arbitrators stake $KMD to join dispute panels and earn fees for correct rulings |
| Governance | Holders vote on fee levels, supported settlement tokens, treasury spending and upgrades |
Fee distribution (target): 50% to relay and indexer nodes, 30% to the treasury, 20% bought back and burned. The DAO can adjust these shares.
7. Tokenomics
| Allocation | Share | Amount ($KMD) | Vesting |
|---|---|---|---|
| Ecosystem & developer grants | 25% | 250,000,000 | Released by grants committee over 48 months |
| Network rewards | 20% | 200,000,000 | Emitted to node operators over 8 years, decreasing yearly |
| Team & advisors | 15% | 150,000,000 | 12-month cliff, then 36 months linear |
| Early investors | 15% | 150,000,000 | 6-month cliff, then 24 months linear |
| Treasury (DAO) | 10% | 100,000,000 | Spent by governance vote |
| Liquidity | 10% | 100,000,000 | Available at launch |
| Community & airdrop | 5% | 50,000,000 | Testnet and early-user programs |
| Total | 100% | 1,000,000,000 |
8. Roadmap
Milestones below are targets and depend on funding, audits and regulatory review.
| Phase | Target timing | Deliverables |
|---|---|---|
| 0 · Foundations | Months 0–6 | Protocol specification v1; TypeScript and Python SDKs; identity and encrypted messaging on testnet; first 3 reference agents |
| 1 · Settlement | Months 6–12 | Escrow and payment channels on testnet; smart-contract audits; $KMD token generation; mainnet beta with allow-listed operators |
| 2 · Open network | Months 12–18 | Public registry and staking; relay and indexer rewards; reputation receipts; A2A and MCP adapters |
| 3 · Governance | Months 18–24 | Dispute arbitration panels; DAO controls fees and treasury; independent foundation stewardship |
Target metrics for month 18: 500 registered agents, 50 independent node operators, 1 million settled tasks. These are goals, not results.
9. Governance
Protocol parameters (fees, fee distribution, supported tokens, staking minimums) are controlled by $KMD holders through on-chain proposals. Proposals require a minimum stake to submit, a 7-day voting period and a quorum of circulating supply. Approved changes execute after a 48-hour timelock so users can react. During the first phases a multisig of core contributors can pause contracts in an emergency; this power is scheduled to be removed in Phase 3.
10. Team and legal entity
To be announced before the token generation event: the founding team and advisors with verifiable backgrounds, the legal entity issuing $KMD and its jurisdiction, the audit firms, and key partners.
11. Risks and disclaimer
Regulatory: rules on digital assets differ by country and are changing. The project will obtain legal advice in each market before issuing or distributing $KMD.
Technical: smart contracts and cryptographic protocols may contain undiscovered vulnerabilities despite audits.
Adoption: the network is only useful if enough agents and operators join; competing standards may gain more traction.
Market: the price of $KMD may be highly volatile, and holders may lose part or all of their value.
This document describes a planned protocol. It is not an offer to sell or a solicitation to buy any security or financial product, and nothing in it is investment, legal or tax advice. All figures, allocations and timelines are subject to change.