Reference
What it does
The veidregistry module is the ledger's index of identity state: which accounts have verified records, which scopes those records comprise, and how identity state is looked up by the modules that enforce identity gates.
Splitting the registry from the scoring engine keeps long-lived identity records cleanly separated from the verification workflow — scoring logic can evolve while the record-of-record interface other modules depend on stays stable.
Why it exists: A protocol action that explicitly requires an identity proof needs a canonical way to resolve the requested claim. The registry provides identity state for those scoped checks without making VEID a prerequisite for every marketplace action.
State
Primary objects
| Concept | Definition |
|---|---|
Identity record | The canonical on-chain record binding an account to its verification outcomes. |
Scope registration | The registry entry tracking which identity scopes an account has verified. |
Messages
Messages & queries
Message and query surfaces are documented at implementation level in the module docs ↗ and the source ↗. The objects above are the state those messages create and transition.
Connections
Module interactions
-
x/veidConsensus-committed scores and scope outcomes are recorded into the registry. -
x/marketWhen a supported offer requests VEID, the registry can resolve the relevant proof; it does not impose a universal marketplace gate. -
x/providerProvider registration checks registry state before admitting operators. -
x/rolesRole assignments can be conditioned on registry-verified identity.
Flows
Core flow
- Commit — Scores commit. Consensus-committed scores and scope outcomes are recorded from the scoring engine.
- Register — Records bind accounts. The canonical record ties each account to its verification outcomes and verified scopes.
- Resolve — Modules query. Marketplace gates, registration checks, and role conditions resolve identity state through the registry.
- Endure — Records outlive workflows. Long-lived identity state stays addressable as scoring machinery evolves underneath.
Questions
Asked about x/veidregistry
Why split the registry from scoring?
So verification workflows can evolve without breaking the stable record interface that every gated module depends on — production machinery changes, the address of truth doesn't.
What does an identity record contain?
The binding between an account and its verification outcomes, plus which identity scopes it has verified — the facts gated actions need, nothing more.
Which actions check the registry?
Provider registration, deployment creation, marketplace participation gates, and identity-conditioned role grants — anything that must answer what an account's verified state is.
Related