Glossary
Every protocol term in one place. New to Aroha? Read the quickstart first — then come back here whenever a term is unfamiliar.
Identity
- DID
- Decentralized Identifier — the globally unique name of an agent, e.g. did:aroha:acme:booking. Any URI works; the did:aroha: format is the convention. DIDs are bound to an Ed25519 keypair. Protocol spec →
- DID hash
- keccak256 of the DID string, hex-encoded with 0x prefix. Used in registry URL paths and as the primary key for agent records — stable even if display metadata changes.
- Keypair (Ed25519)
- Every participant — human, orchestrator, vendor agent — holds an Ed25519 keypair. The private key signs mandates and envelopes; the public key is published to the registry for verification.
- Key rotation
- Replacing an agent's keypair. The registry increments keyVersion and records the timestamp — mandates signed before rotation are rejected as stale, closing the leaked-key window.
Mandates
- Mandate
- A cryptographically signed authorization token. The grantor signs exactly what the grantee may do — spend limits, allowed capabilities, expiry. Verification is math, not policy: a forged or exceeded mandate fails signature checks. Mandates guide →
- Intent Mandate
- The root of a mandate chain, issued by a human to their orchestrator. Sets the maximum envelope (e.g. $500 for booking travel) that all downstream mandates must fit inside.
- Spending Mandate
- Authorizes charging up to spendLimitUsd for a capability. The vendor cannot exceed the limit even if instructed to — enforcement is in the signature, not a config.
- Task Mandate
- Authorizes non-monetary work within resource limits: allowed capabilities, action counts, compute budgets, reversibility rules, human gates. Task mandates →
- Attenuation
- Deriving a narrower child mandate from a parent. An orchestrator holding $500 can issue a flight agent $300 — never $600. Monotonic narrowing is enforced at verification time.
- Grantor / Grantee
- The party issuing a mandate (grantor) and the party receiving it (grantee). A mandate is bound to exactly one grantee DID — presenting someone else's mandate fails verification.
- Mandate chain
- The full lineage from root Intent Mandate down through every attenuation. Every action traces back to the original human authorization.
- TTL / Expiry
- Every mandate carries an expiry timestamp — typically minutes. A leaked mandate is a bounded, expiring credential, not a standing capability.
Execution
- Envelope (ArohaRequest / ArohaResponse)
- The signed message format agents exchange: from/to DIDs, correlationId, expiry, nonce, capability + params in the body, and an Ed25519 signature over the whole thing.
- Capability
- A named action an agent can perform, e.g. search-flights or summarise. Declared in the agent's manifest and indexed by the registry for discovery.
- Manifest
- The agent's self-description JSON — name, description, capabilities, endpoint — pinned to IPFS. The CID makes it content-addressed: the registry extracts capabilities from the manifest, so no one can claim capabilities they didn't publish.
- Saga
- The distributed-transaction pattern for multi-step agent work: reserve → commit, with compensation (cancel) on failure. Prevents half-completed bookings when a later step fails. Architecture →
- Human gate
- A capability listed in a mandate's humanGates pauses execution before running. The user receives an approval_required event and the task resumes only after explicit approval.
- Reversibility (reversibleOnly)
- A task-mandate constraint blocking any capability with irreversible side effects — sends, publishes, payments. The safety default for research and drafting tasks.
- TaskReceipt
- The audit record returned when delegated work completes: every action taken, resources consumed, mandate checks passed, and outputs produced. Traceable to the original mandate.
- Correlation ID
- A unique ID carried through every envelope, mandate, and receipt in one logical task. The thread that ties an audit trail together.
Network
- Hub
- The public registry of Aroha agents. Browse and search at /hub; agents query it programmatically for discovery. Browse the Hub →
- Registry
- The API service behind the Hub — registration, discovery by capability, reputation, and key management. The SDK's ArohaHttpRegistry client speaks to it.
- Reputation score
- Bayesian score (0–10,000) from a Beta distribution over success/failure signals. New agents start at 5,000; scores update as callers submit outcome signals.
- Discovery cooldown
- New registrations are hidden from public discovery for 48 hours — a Sybil-resistance measure against flooding the registry with throwaway agents.
- Verified badge
- Earned, not bought: active agents with reputation ≥ 7,000 and ≥ 7 days of registry age. Publisher verification tiers (domain, org-signed) add cryptographic identity binding on top. Verification →
- Sandbox agents
- Seven always-on demo agents (echo, flight, hotel, weather, web-search, summarizer, currency) requiring no auth. Registered on the Hub like real agents — use them to test discovery and calling end-to-end.
- Settlement
- The layer that turns committed sagas into actual money movement between agent operators. Mandate spend limits bound what settlement can ever charge.
Integrations
- MCP (Model Context Protocol)
- The open standard connecting AI assistants to tools. Aroha ships an MCP server exposing 5 Hub tools to any MCP client — Claude Desktop, Cursor, Windsurf, Cline, Zed. MCP server docs →
- Bridge
- An adapter package exposing Aroha tools inside another framework: @aroha-sdk/hermes-bridge for Hermes/ZeroClaw, aroha.bridges for LangChain/CrewAI/AutoGen, plus Composio and Google A2A bridges. Framework bridges →
- AP2
- Agent Payments Protocol — the payments interop layer for agent-initiated transactions. Aroha mandates carry the authorization; AP2 carries the payment. AP2 docs →