Resource · 2.1 in the design proposal

Identity (ADI)

Provision and inspect Accumulate Digital Identifiers — the human-readable, self-owned identity every other resource in this node nests underneath.

6 operations 5 MVP candidates 1 Phase 2+ (ID05)

What an ADI is, and why it's the resource everything else nests under

Most L1 chains treat a cryptographic keypair as the address. Accumulate inverts that: the base unit is an Accumulate Digital Identifier (ADI) — a human-readable, URL-shaped identity such as acc://redwagon.acme. Per the protocol docs, each ADI "functions as an independent chain" with its own state and its own set of typed sub-accounts (token accounts, data accounts, key books) nested under its URL — e.g. acc://redwagon.acme/tokens. This is the "chain-of-chains" design covered in 004.References/AboutAccumulate.md §1: rather than one shared global ledger, every ADI is effectively its own mini-blockchain, periodically anchored into the wider network.

An ADI must be created on-chain, funded by ACME-converted credits, and is secured by a Key Book from the moment it exists (see the Key Management resource for what that structure looks like). Sub-identities can nest further — acc://company.acme/accounting/payroll — which is exactly the shape ID02 and ID05 below are for.

Operations

Code	Operation	Maps to	Why a workflow author wants it	Priority
ID01	Create Identity	`TxBody.CreateIdentity()`	Provision a new ADI as part of an onboarding/setup workflow	MVP
ID02	Create Identity (Inherited authority)	`TxBody.CreateIdentityInherited()`	Create a sub-identity that inherits its parent's key book — common for an org sub-unit	MVP
ID03	Query Identity / Account Info	V2 `query`	Read an ADI's current state before branching workflow logic	MVP ★
ID04	Query ADI Directory (list sub-accounts)	V2 `query-directory`	Enumerate an ADI's token/data/key-book sub-accounts, e.g. to discover what already exists	MVP
ID05	Provision ADI Hierarchy	`Acme.Net.Sdk.Provisioning.HierarchyProvisioner`	One call to stand up a multi-level ADI tree (org identity + department sub-identities, each with its own key config) instead of manually looping ID01/ID02 + KM01/KM02. Idempotent — safe to retry after a partial failure without creating duplicates	Phase 2
ID06	Get Identity Transaction History	V2 `query-tx-history` scoped to the ADI's `acc://` URL	List transactions against this specific identity — resource-scoped history, parity with how the Ethereum node scopes history under Account rather than only as a generic Transactions resource op	MVP

Settled 2026-07-02 — ID05 is a dedicated operation

The project owner decided HierarchyProvisioner gets its own operation ID rather than being modeled purely as a workflow author composing ID01/ID02 + KM01/KM02 themselves. It stays Phase 2, not because the decision is soft, but because it needs a tree-shaped input schema (parent/children plus per-level key config) — genuinely more design work than the flat, single-level settings the MVP operations above use.

How it works — provisioning a multi-level identity tree

ID05 — HierarchyProvisioner, one idempotent call

flowchart TD
  W["Workflow: onboard a new org unit"] --> N["AccumulateNodeExecutor
ID05 Provision ADI Hierarchy"]
  N --> HP["HierarchyProvisioner
(Acme.Net.Sdk.Provisioning)"]
  HP --> P["acc://company.acme
(parent ADI, ID01)"]
  P --> C1["acc://company.acme/accounting
(ID02, inherits parent key book)"]
  P --> C2["acc://company.acme/payroll
(ID02, inherits parent key book)"]
  C1 --> K1["Key Page config
(KM01/KM02 per level)"]
  C2 --> K2["Key Page config
(KM01/KM02 per level)"]
  HP -. "retry after partial failure is safe — no duplicate sub-identities" .-> HP

ADI URL / account model — what nests under an identity

graph TD
  ADI["acc://redwagon.acme
(the ADI itself)"]
  ADI --> KB["Key Book
secures the ADI from creation"]
  ADI --> TOK["acc://redwagon.acme/tokens
Token Account"]
  ADI --> DAT["acc://redwagon.acme/data
Data Account"]
  ADI --> SUB["acc://redwagon.acme/accounting
Sub-identity (ID02)"]
  SUB --> SUBKB["inherits parent Key Book
(no separate authority unless overridden)"]

Business use case — organizational identity provisioning

From 001.BusinessIdeas/README.md §2.4

Onboarding workflows — a new business unit, vendor, or customer — often end with "someone manually sets up their account/credentials in system X." An ADI can be one of those provisioned artifacts: ID01 creates the new identity, ID02 adds inheriting sub-identities for department structure, KM01/KM02 set up its key authority, ID05 does the whole tree in one idempotent call, and ID03/ID04 confirm the provisioning actually succeeded before the workflow proceeds.

Flagged honestly in the source document: this is plausible and maps cleanly to real operations, but "a vendor/customer wants a self-sovereign on-chain identity as part of BizFirst onboarding" is a claim about customer demand the business-ideas document explicitly says it cannot verify — not asserted as proven.

Open questions affecting this resource

Open · read-only credential mode

Should the node support a no-signing-key, query-only credential mode? If resolved, ID03/ID04/ID06 (pure reads) could run without provisioning a signing key at all — directly relevant to Identity since its two read operations don't inherently need one. See the Query / Explorer page for the fuller discussion.
Open · V2 vs. V3 targeting

ID03/ID04/ID06's V2 method names (query, query-directory, query-tx-history) were verified directly against protocol source; V3's exact method-name parity was not independently confirmed. Needs confirmation at implementation time.