Skip to content

x/veidregistry — VEID Registry module

The x/veidregistry module is the ledger’s index of identity state: which accounts hold 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.

The module maintains the record-of-record interface for identity state. It records consensus-committed scores and scope outcomes produced by the scoring engine, binds each account to its verification outcomes and verified scopes, and exposes that state for lookup.

Every identity gate on the chain resolves through it: marketplace identity gates, provider registration checks, and role conditions all query the registry rather than the machinery that produces the state. Because long-lived records are kept addressable separately, scoring machinery can change underneath without disturbing the address of truth.

Every identity-gated action on the chain — registering a provider, creating a deployment, casting an identity-weighted vote — needs a fast, canonical answer to “what is this account’s verified identity state?”. The registry is that answer, kept apart from the machinery that produces it.

ConceptDefinition
Identity recordThe canonical on-chain record binding an account to its verification outcomes.
Scope registrationThe registry entry tracking which identity scopes an account has verified.
  1. Commit — Scores commit. Consensus-committed scores and scope outcomes are recorded from the scoring engine.
  2. Register — Records bind accounts. The canonical record ties each account to its verification outcomes and verified scopes.
  3. Resolve — Modules query. Marketplace gates, registration checks, and role conditions resolve identity state through the registry.
  4. Endure — Records outlive workflows. Long-lived identity state stays addressable as scoring machinery evolves underneath.
MessagePurpose
MsgUpsertVerifierVersionCreates or updates a verifier version in the registry.
MsgApproveVerifierVersionApproves a queued verifier version.
MsgCancelVerifierVersionCancels a pending verifier version.
MsgRetireVerifierVersionRetires a verifier version from active use.
MsgReportValidatorReadinessReports a validator’s readiness for verification duties.
MsgUpdateVerifierRegParamsUpdates verifier registry parameters.
MsgUpdateParamsGovernance-only update of module parameters.
QueryPurpose
Verifier / VerifiersOne registered verifier, or the full set.
ActiveVerifierThe verifier version currently active.
QueuedVerifiersVerifier versions queued for activation.
EligibleVerifiersVerifier versions eligible for use.
ValidatorReadinessReadiness reports filed by validators.
ParamsCurrent module parameters.
ModuleHow they interact
x/veidConsensus-committed scores and scope outcomes are recorded into the registry.
x/marketMarketplace identity gates resolve accounts through the registry.
x/providerProvider registration checks registry state before admitting operators.
x/rolesRole assignments can be conditioned on registry-verified identity.

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.

The binding between an account and its verification outcomes, plus which identity scopes it has verified — the facts gated actions need, nothing more.

Provider registration, deployment creation, marketplace participation gates, and identity-conditioned role grants — anything that must answer what an account’s verified state is. See the x/veid module.