INK Protocol

Choose your starting point

I'm implementing INK Start with the wire format, signing base and authentication. Then walk through the handshake and run the test vectors against your build.

I'm integrating with an INK agent Read Discovery & Transport plus the Agent Card schema. That's everything a client needs to send its first signed intent.

I'm auditing INK security Threat model below, then the Authentication, Encryption and Replay-Protection specs. The implementation lives in the GitHub repo.

I'm comparing INK to other protocols Design Principles compares INK to AT Protocol, UCAN, ACP and message-bus alternatives. INK assumes DIDs for identity and is transport-agnostic.

I want to test my sender against a live receiver Send a signed envelope to the public test endpoint at ink-echo.tulpa.network and read back a JSON acknowledgement. A 200 means your bytes are on the canonical wire.

Library

github.com/Ad-Astra-Computing/ink

The MIT-licensed TypeScript library, conformance test vectors, threat model and full spec. Open source under Ad Astra Computing. This is the canonical implementation — the same code that runs in production.

View the repository → · npm package · Contributing

Send messages across services

INK is cross-platform by design. Any compatible service that publishes a DID and exposes an /ink/v1/... endpoint can accept signed INK envelopes from agents running on other platforms.

tulpa.network is one current example of an accepting endpoint. Its receive side resolves inbound senders against published Agent Cards and applies operator-level and per-user acceptance policies. The same protocol surface can be implemented by other operators.

Core primitives

DID-Based Identity

Agents derive authority from AT Protocol DID documents. Ed25519 signing keys and X25519 encryption keys are published via agentLink records.

Signed Messages

Every INK message is Ed25519-signed over protocol version, method, path, recipient DID, JCS-canonical body and timestamp. No shared secrets.

ECIES Encryption

Ephemeral X25519 key agreement, HKDF-SHA256 derivation, AES-256-GCM. Forward secrecy per message. Outer envelope stays plaintext for routing.

Hash-Chained Audit

Per-agent append-only logs with monotonic sequence numbers, SHA-256 chain linkage and Ed25519 signatures. Fork and gap detection built in.

Message Receipts

Signed disposition acknowledgments (received, delivered, acted, rejected, expired). Receipts are full INK messages with replay protection.

Authorization Chains

Multi-hop delegation with permission attenuation. Max 5 hops, short-lived tokens (1–4h default), UCAN-inspired capability model.

Protocol overview

INK is an application-layer protocol that lets AI agents representing human identities (DIDs) discover each other, negotiate professional intents and establish verifiable trust without a central broker. It is built on the AT Protocol for identity, but is transport-agnostic for everything else.

Invariants

All INK implementations MUST satisfy:

• Signatures are mandatory. Every message carries an Ed25519 signature over a deterministic base string. Unsigned messages MUST be rejected.
• Replay protection is mandatory. Every message carries a nonce and timestamp. Duplicate nonces within the 5-minute window MUST be rejected.
• Identity is DID-bound. Agent authority derives from an agentLink record in the owner’s AT Protocol repo, verified via the PDS commit signature.
• Audit is append-only. Each agent’s audit log is hash-chained with monotonic sequence numbers. Forks (same sequence, different hash) are detectable.
• Encryption uses ephemeral keys. ECIES payloads use per-message ephemeral X25519 keys. The agent’s long-term encryption key is the static recipient key only.
• Human authority is preserved. Agents operate within configurable autonomy policies. The escalated_to_human resolution outcome exists for this reason.

Threat model

INK assumes a network adversary that can intercept, replay or forge messages on the wire and may operate at scale (botnets, coordinated spam). It assumes the underlying identity system (AT Protocol DID resolution) is trustworthy. Compromise of an agent’s long-term private key is out of scope. Recovery there is the identity system’s job, not INK’s.

Threat	Mitigation
Message forgery	Ed25519 signatures with DID-bound keys
Replay attack	Nonce + timestamp window (5 min past, 30s future)
Recipient confusion	Recipient DID bound into signature base
Eavesdropping	ECIES encryption with forward secrecy
Audit tampering	Hash-chained logs with sequence numbers; bilateral exchange detects divergence
Split-view audit	Third-party Merkle witness services
Privilege escalation	Authorization chains enforce permission attenuation per hop
Stale delegation	Short-lived tokens (1–4h), expiration checked per message

State transitions

Diagrams use a consistent color language. Blue = AT Protocol / identity layer · Purple = INK coordination · Green = audit / receipts · Gray = local storage / app state.

At a glance

Protocol versionink/0.1 + 0.2

StatusDraft

SigningEd25519

EncryptionX25519 + AES-256-GCM

CanonicalizationJCS (RFC 8785)

Identitydid:web, did:plc, did:key

Replay window5 min past, 30 s future

Max delegation depth5 hops