Introduction

INK stands for Inter-agent Networking Kernel, the minimal coordination surface that agents need to discover, authenticate and transact with each other.

Wire version: ink/0.2 is the current defined wire version; senders still emit ink/0.1 by default and only emit ink/0.2 to a receiver that advertises it. The reference library @adastracomputing/ink moves on its own semver independent of the wire version; see Versioning & Compatibility for the current latest and next releases.

INK is an application-layer protocol that enables autonomous coordination between professional AI agents. It formalizes how agents representing human identities discover each other, negotiate professional intents and establish verifiable trust. Identity is key-derived by default: an agentId embeds the agent’s genesis Ed25519 key, so it needs no registry behind it. did:web is the supported alternative, and any system that can publish an Ed25519 signing key under a stable identifier can participate.

Key terms used in this spec

DID (Decentralized Identifier), a globally unique identifier resolvable to key material (e.g. did:web:example.com, did:plc:abc123). INK carries a DID as one admissible principal form. It is not the only one, and INK’s own key-derived principals carry their key inside the identifier rather than resolving one.

AT Protocol (ATP), the open protocol behind Bluesky. A deployment may use it to link an agent to a human owner. That linkage is optional, INK defines no proof over it and it is never what makes a signature valid.

Ed25519, a digital signature algorithm. Every INK agent has an Ed25519 keypair. Signatures prove message authenticity without shared secrets.

ECIES. Elliptic Curve Integrated Encryption Scheme. Used for optional end-to-end encryption of message payloads between agents.

Goals

• Agent autonomy with human oversight, agents coordinate on behalf of their owners within configurable policy boundaries
• Cryptographic trust, every message is Ed25519-signed; sensitive payloads are encrypted
• Tamper-evident audit, hash-chained, signed audit logs enable bilateral dispute resolution
• No mandatory substrate, a keypair and an HTTP endpoint are enough to participate; no registry, directory or network membership is required
• Interoperable, any implementation that satisfies the compliance checklist can participate in the INK network

Network Architecture

INK defines three layers. The diagram shows the default: each agent’s identifier carries the key that roots it, so nothing resolves through a directory. A did:web principal replaces that root with a DID document. Owner linkage sits beside the protocol rather than under it, and an agent that has none is fully conforming.

Layer	What it provides	How
Identity & Binding	A principal that names a signing authority	A key-derived tulpa: or ink: agentId that embeds its own genesis Ed25519 key, or a did:web identity whose DID document roots the key. An optional agentLink record binds an agent to a human AT Protocol DID. See Identity & Binding
Discovery	Endpoint and key resolution	The versioned discovery path, GET <base>/ink/v1/<agentId>/agent.json, is the sole normative discovery surface. The resolution base is derived from the identifier or held in trusted local configuration, never supplied by the counterparty. See Discovery
Coordination	Signed intent, challenge and resolution handshake	HTTPS/REST with Ed25519 auth

Document Conventions

This specification uses the requirement level keywords defined in RFC 2119: MUST, MUST NOT, SHOULD, SHOULD NOT and MAY.

All JSON examples use the wire format (snake_case type fields). See Naming Conventions for the distinction between lexicon IDs and wire types.