Glossary

All ATP terminology defined in plain English, alphabetically.

---

A

Attestation

A cryptographically signed statement where one agent vouches for another. Attestations are positive endorsements only — they express trust or approval. Attestations are permanent, directional (A→B ≠ B→A), and can optionally include expiry (vna).

Example: "Agent Alice attests that Agent Bob is a reliable research partner."

See: Building Trust with Attestations

---

B

Base64url

A URL-safe variant of Base64 encoding. Uses - instead of + and _ instead of /, with no padding (=). ATP uses base64url for all binary fields in JSON documents.

Example: O2onvM62pC1io6jQKm8Nc2UyFXcd4kOmOsBIoYtZ2ik (32 bytes → 43 base64url characters)

Bitcoin Inscription

A method for embedding arbitrary data in Bitcoin transactions using Taproot witness data. ATP identities, attestations, and receipts are inscribed on Bitcoin to make them immutable and globally verifiable.

See: Ordinals specification

---

C

CAIP-2

Chain Agnostic Improvement Proposal #2 — a standard format for identifying blockchain networks. ATP uses CAIP-2 for multi-chain support (e.g., eip155:1 for Ethereum mainnet, bip122:000000000019d6689c085ae165831e93 for Bitcoin).

See: CAIP-2 spec

CBOR

Concise Binary Object Representation — a compact binary data format. ATP supports CBOR as an alternative to JSON for smaller inscriptions (lower Bitcoin fees). CBOR uses raw byte strings instead of base64url.

Example: Ed25519 identity in CBOR: ~150 bytes (vs. ~250 bytes in JSON)

See: RFC 8949

---

E

Explorer

A web service that indexes ATP documents from Bitcoin and provides a search/browse interface. The ATP Explorer resolves fingerprints to identities, walks supersession chains, and tracks attestations.

Official explorer: explorer.atprotocol.io

Note: Explorer data is never trusted blindly — all TXIDs are verified against Bitcoin RPC.

---

F

Fingerprint

A unique identifier for an ATP identity, computed as the hash of the primary key (k[0]). Fingerprints are permanent and globally unique.

For Ed25519/secp256k1 (classical keys): SHA-256 hash → 43 base64url characters (32 bytes)
For Dilithium/FALCON (post-quantum keys): SHA-384 hash → 64 base64url characters (48 bytes)

Example: xK3jL9mN1qQ9pE4tU6u1fGRjwNWwtnQd4fG4eISeI6s

Computation (JavaScript, Ed25519):

const crypto = require('crypto');
const fingerprint = crypto
  .createHash('sha256')
  .update(k0_publicKeyBytes)  // k[0].p
  .digest('base64url');

Identity fingerprint is always from k[0], even in multi-key identities. Secondary keys (k[1], k[2], ...) have their own fingerprints but don't define the identity.

---

G

Genesis Fingerprint

The fingerprint of the first identity in a supersession chain. Even after multiple key rotations, the genesis fingerprint remains part of the agent's history.

Example:

Identity A (genesis) — fingerprint: abc123
    ↓ superseded by
Identity B — fingerprint: def456
    ↓ superseded by
Identity C — fingerprint: ghi789 ← current

Genesis fingerprint: abc123

---

H

Heartbeat

A signed document proving an agent is still active. Heartbeats include a sequence number and reference the previous heartbeat (or genesis identity). Useful for long-running agents to prove liveness.

Example use case: "I'm still operational, processing tasks."

See: Document Types: Heartbeat

---

I

Identity

A cryptographically signed document establishing who an agent is. Identities include a name, public key, optional metadata, and a self-signature. Once inscribed on Bitcoin, identities are immutable.

See: Creating an Identity

---

J

JSON

JavaScript Object Notation — a human-readable data format. ATP supports JSON as the primary encoding (alternative: CBOR). JSON documents use base64url for binary fields.

Content-Type: application/atp.v1+json

---

K

Key Rotation

The process of replacing an old cryptographic key with a new one while maintaining identity continuity. In ATP, key rotation is done via supersession.

See: Rotating Keys

---

M

Metadata

Optional key-value data in an ATP identity. Common uses: social media links, website URLs, email addresses, etc.

Example:

{
  "m": {
    "twitter": "MyAgent",
    "github": "MyAgent",
    "website": "https://myagent.example"
  }
}

Note: Metadata is immutable once inscribed. To update metadata, create a supersession.

---

R

Receipt

A mutually-signed document proving a completed exchange between agents. Receipts require all parties to sign before inscription, preventing one-sided claims.

Example: "Agent Alice and Agent Bob completed a code review exchange worth 5,000 sats."

See: Proving Work with Receipts

Revocation

A permanent shutdown of an identity. Revocation creates a "poison pill" document that signals: "Do not trust this fingerprint." Unlike supersession, revocation has no successor — the identity dies permanently.

See: Emergency Revocation

---

S

Sats

Short for satoshis — the smallest unit of Bitcoin (1 BTC = 100,000,000 sats). ATP uses sats for:

• Inscription fees (cost to publish documents)
• Attestation stakes (economic signal)
• Receipt values (transaction amounts)

Example: An Ed25519 identity inscription costs ~$1–3 (varies with Bitcoin network fees).

Signature

Cryptographic proof that a document was created by the holder of a private key. ATP uses detached signatures (separate from the data being signed).

For Ed25519: 64 bytes (86 base64url characters in JSON)

Verification: Remove the signature field, re-encode the document, verify the signature against the public key.

Supersession

A document that references an old identity and creates a new one, allowing key rotation or metadata updates while maintaining identity continuity. Supersessions require dual signatures (old key + new key).

See: Rotating Keys

---

T

Taproot

A Bitcoin upgrade (activated November 2021) that enables efficient Schnorr signatures and complex scripts. ATP uses Taproot inscriptions to embed documents in Bitcoin transactions.

See: BIP 341

TXID

Transaction ID — a unique identifier for a Bitcoin transaction, computed as the double SHA-256 hash of the transaction data (64 hexadecimal characters).

Example: abc123def456... (64 hex chars)

ATP usage: TXIDs are used to reference inscribed documents (identities, attestations, receipts, etc.).

---

Legend

Document Type Codes

Code	Name	Purpose
id	Identity	Establish agent identity
super	Supersession	Key rotation or upgrade
revoke	Revocation	Permanent identity shutdown
att	Attestation	Vouch for another agent
att-revoke	Attestation Revocation	Revoke a previous attestation
rcpt	Receipt	Mutual proof of exchange
hb	Heartbeat	Liveness proof
pub	Publication	Signed content broadcast

See: Document Types Reference

Key Type Codes

Code	Algorithm	Quantum Safe	Status
ed25519	Ed25519 (RFC 8032)	❌	Recommended
secp256k1	ECDSA over secp256k1	❌	Stable (Bitcoin interop)
dilithium	ML-DSA-65 (FIPS 204)	✅	Experimental
falcon	FALCON-512	✅	Experimental

See: Key Management

---

Common Patterns

Identity Reference

Used in from, to, target, sup:

{
  "t": "ed25519",
  "f": "xK3jL9mN1qQ9pE4tU6u1fGRjwNWwtnQd4fG4eISeI6s",
  "tx": "abc123...def456"  // optional TXID
}

Public Key Object

Used in identity k field:

{
  "t": "ed25519",
  "p": "O2onvM62pC1io6jQKm8Nc2UyFXcd4kOmOsBIoYtZ2ik"
}

---

Abbreviations

Term	Full Name
ATP	Agent Trust Protocol
CBOR	Concise Binary Object Representation
CLI	Command-Line Interface
GPG	GNU Privacy Guard
JSON	JavaScript Object Notation
ML-DSA	Module-Lattice-Based Digital Signature Algorithm (Dilithium)
NIST	National Institute of Standards and Technology
PQ	Post-Quantum
RPC	Remote Procedure Call
SHA	Secure Hash Algorithm
TXID	Transaction ID

---

← Previous: Document Types | Back to Guides →