An identity, trust, and intent protocol for autonomous economic agents

01 / The Missing Layer

A wallet address is not an identity.

Every agent that transacts today answers "how do I move money" by picking a wallet SDK. Almost none can answer, in a way a counterparty could actually verify: who do you represent? What have you done before, and can I check it myself? Is what you're about to do actually something you're authorized to do, or just something your code happens to be capable of? If I stop trusting you, or you change which model or wallet you run on, does any of that history and authority survive?

Zoom out and the deeper problem isn't any single missing feature — it's fragmentation. An agent's identity lives in a registry. Its authorization lives in a mandate. Its credentials live with an issuer. Its transaction history lives in a marketplace. Each piece can be individually verifiable and still add up to nothing, because nothing ties them back to the same underlying actor.

This is the gap ALMA fills — not by building another payment rail, identity registry, or credential format, but by giving every economic actor a durable identity connecting what it represents, what it's allowed to do, what it has done, and what it wants to do next.

02 / Design Principles

Identity outlives runtime

An agent's identity, delegated authority, and accumulated reputation must survive a change of model, host, wallet, or chain.

Evidence before scores

ALMA stores verifiable, attributable evidence and leaves scoring, if anyone wants it, as something built on top of that evidence — not baked into the protocol.

Protocol, not platform

ALMA specifies shapes, identifiers, and semantics — not who hosts the data or what UI configures it.

Intent, not authorization

ALMA defines how an agent expresses what it wants to do, not whether that expression is allowed.

Custody-agnostic, execution-agnostic

ALMA has no opinion on which wallet, chain, or payment rail eventually moves value.

Own the model, not the infrastructure

Authentication is FIDO/WebAuthn's job. Credential formats are W3C VC's. Commerce authorization is AP2's and Verifiable Intent's. On-chain reputation is ERC-8004's. Where the answer is infrastructure, ALMA references it instead of reinventing it.

03 / The ALMA Model

3.1 — Subjects

Treating Human, Organization, and Agent as instances of the same underlying concept — a Subject — is deliberate: no adjacent standard defines this. DID gives you an identifier, W3C VC gives you a claim, ERC-8004 gives you an agent registry entry — none say Agent X represents Organization Y.

3.2 — Principals and Representation

A Principal is a Subject that can hold economic authority and be represented — almost always a Human or an Organization, though an Agent can itself act as a Principal when it delegates a narrower scope onward. An Agent always represents a Principal; it is never a free-floating actor with authority of its own origin.

3.3 — Identifiers

// alma:<network>:<subject-type>:<local-id>
alma:main:human:8f2a...
alma:main:org:acme-labs
alma:main:agent:treasury-01

network is a namespace, not a blockchain. An identifier, once issued, is never reassigned, even after the Subject it names is retired.

3.4 — Identity vs. Identifier: Controllers and Bindings

A wallet address or an on-chain registry entry names a controller, not a durable actor. A Subject's identifier is stable; the mechanisms that currently control or represent it are controllers and bindings, free to change completely without the identifier changing.

alma:main:agent:treasury-42
  controller: did:key:z6Mk...
  binding:    erc8004:base:291
  binding:    wallet:0xAbCd...
  binding:    endpoint:https://agent.acme.com/a2a

ALMA does not mint keys, resolve DIDs, or replace a wallet's own addressing — it defines the identity abstraction those mechanisms attach to. This is what lets an agent swap its model, host, or wallet provider and still be, provably, the same economic actor.

04 / The Authority Layer

4.1 — Delegation

A Delegation is a directed grant of authority: an issuer grants a subject the right to act within a defined scope.

Delegation {
  issuer:  alma:main:org:acme-labs
  subject: alma:main:agent:treasury-01
  scope:   { capabilities: ["pay", "swap"], constraints: [...] }
  status:  active | revoked | expired
  proof:   { format: "ap2-mandate" | "verifiable-intent" | "w3c-vc" | "alma-native", reference: ... }
}

ALMA defines what a delegation means inside an actor's authority graph — not the cryptographic format used to prove it. The same edge might be backed by a Verifiable Intent credential, an AP2 mandate, a W3C VC, or an ALMA-native signature.

Chained delegation is first-class: an agent holding authority can delegate a strictly narrower slice of it onward — a treasury agent handing a bounded sub-budget to a specialist trading agent.

4.2 — Credentials

A Credential is a verifiable claim about a Subject. ALMA does not define a new credential format — a credential's proof MAY be a W3C Verifiable Credential (the default), an SD-JWT-based credential, or another independently verifiable format. ALMA defines how that evidence relates to an economic Subject:

CredentialEvidence {
  subject:  alma:main:org:acme-labs
  issuer:   alma:main:org:kyb-verifier
  type:     "kyb_verified"
  claim:    { tier: "institutional" }
  format:   "w3c-vc" | "sd-jwt" | "erc8004" | "alma-native"
  artifact: ...
}

05 / The Trust Layer

5.1 — The Relationship Graph

Economic actors own, represent, delegate to, operate, transact with, and are hired by one another:

owns · represents · delegates · operates · member_of · hired · paid · transacted_with

Human    --owns-->      Organization
Organization --delegates--> Agent A
Agent A  --hired-->     Agent B
Agent B  --operated_by--> Organization B
Agent A  --paid-->      Agent B

Every hired, paid, and transacted_with edge must trace back to a concrete piece of evidence — nothing is asserted without something that happened to justify it.

5.2 — Reputation as Evidence

ALMA deliberately does not define a reputation score. It defines ReputationEvidence, kept as two separate streams per Subject:

ALMA doesn't compete with a chain-native registry like ERC-8004 — it consumes one as a single evidence source among several, normalized into the same model as a completed economic action or a marketplace outcome.

06 / The Intent Layer

An agent's economic intent is inseparable from identity and trust.

6.1 — What Intent Is

An EconomicIntent is ALMA's canonical semantic representation of a desired economic action — deliberately not frozen as a wire format, since commerce-authorization protocols are moving fast in exactly this space.

EconomicIntent {
  actor:               alma:main:agent:treasury-01
  principal:           alma:main:org:acme-labs
  authorityReference:  del_9f3a...
  capability:          "pay"
  parameters:          { amount: "10", asset: "USDC", to: alma:main:agent:research-02 }
  representation:      { format: "ap2-mandate" | "verifiable-intent" | "alma-native", reference: ... }
}

6.2 — Where ALMA Stops

ALMA defines the shape and attribution of an intent — not whether it's permitted, and not how it executes.

An EconomicIntent is a well-formed question. ALMA does not answer it.

07 / Revocation & Lifecycle

Every grant — a Delegation, a Credential — has an explicit revoked state, and revocation is:

• Immediate — rejected the next time it's checked, no tolerated propagation delay.
• Attributed — who revoked it, when, and optionally why.
• Non-retroactive — history reflects what was true at the time.

08 / Interoperability

Sharper by asking one question of every adjacent standard: does it describe the economic actor, or solve infrastructure ALMA would otherwise reinvent?

Owns outright: Subject, Principal, the relationship graph, delegation semantics, the reputation-evidence ontology, and the canonical EconomicIntent shape. Stays out of: checkout/payment semantics, custody, on-chain execution, and a universal reputation score.

09 / Privacy

An ALMA identifier is not, by itself, personally identifying — it reveals a subject type and a namespace, nothing more. Display metadata, the relationship graph, and credential claims are separately access-scoped.

10 / Governance & Versioning

The protocol versions independently as alma/v1, alma/v2, decoupled from any implementation's release cycle. A version change requires a written rationale and a migration path.

A proposal to expand ALMA's scope must pass §02's test — own the model, not the infrastructure — before a version bump is considered.

11 / The Minimum Viable Protocol

A first, implementable version needs, in order:

1. Identifiers and Subjects — immutable once issued, with a controller/binding list from day one.
2. Delegation — single-level grants first, with a pluggable proof reference.
3. The relationship graph, limited at first to owns, represents, delegates, transacted_with.
4. ReputationEvidence as an append-only record — no scoring from day one.
5. EconomicIntent as ALMA's canonical semantic object — native representation first, resolvers for AP2/VI as natural follow-ons.
6. Revocation — immediate and non-retroactive from the start.

12 / Conclusion

Agents are going to keep getting better at doing economically meaningful things. The open question is whether the systems around them can say, honestly and verifiably, who did it, on whose authority, and whether it was actually what they intended.

ALMA turns fragmented identity, authority, and economic evidence into a persistent economic actor — as a protocol, not as a proprietary feature of whichever platform an agent happens to be using this month.