x/veidregistry — VEID Registry module
The x/veidregistry module indexes identity state: which accounts hold
verification records, which scopes those records comprise, and how protocol
actions with an explicit identity requirement can resolve that state.
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.
What it does
Section titled “What it does”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.
Protocol actions that explicitly require an identity proof can query the registry rather than the machinery that produces the state. The registry does not impose a universal VEID gate on marketplace participation; any offer-specific requirement must be disclosed to users. Because records are kept addressable separately, scoring machinery can change without disturbing the identity lookup interface.
Why it exists
Section titled “Why it exists”An action with an explicit identity requirement needs a fast, canonical answer to “what proof has this account presented?”. The registry provides identity state for those scoped checks without making VEID a prerequisite for every marketplace action.
Primary objects
Section titled “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. |
Core flow
Section titled “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.
Messages
Section titled “Messages”| Message | Purpose |
|---|---|
MsgUpsertVerifierVersion | Creates or updates a verifier version in the registry. |
MsgApproveVerifierVersion | Approves a queued verifier version. |
MsgCancelVerifierVersion | Cancels a pending verifier version. |
MsgRetireVerifierVersion | Retires a verifier version from active use. |
MsgReportValidatorReadiness | Reports a validator’s readiness for verification duties. |
MsgUpdateVerifierRegParams | Updates verifier registry parameters. |
MsgUpdateParams | Governance-only update of module parameters. |
Queries
Section titled “Queries”| Query | Purpose |
|---|---|
Verifier / Verifiers | One registered verifier, or the full set. |
ActiveVerifier | The verifier version currently active. |
QueuedVerifiers | Verifier versions queued for activation. |
EligibleVerifiers | Verifier versions eligible for use. |
ValidatorReadiness | Readiness reports filed by validators. |
Params | Current module parameters. |
Module interactions
Section titled “Module interactions”| Module | How they interact |
|---|---|
| x/veid | Consensus-committed scores and scope outcomes are recorded into the registry. |
| x/market | Supported offer-specific checks can resolve VEID proofs; no universal marketplace gate is implied. |
| x/provider | Provider registration checks registry state before admitting operators. |
| x/roles | Role assignments can be conditioned on registry-verified identity. |
Related documentation
Section titled “Related documentation”- VEID Overview — the identity layer this registry serves.
- Enrollment — where verified scopes originate.
- On-Chain Module Map — all 27 modules at a glance.
Why split the registry from scoring?
Section titled “Why split the registry from scoring?”So verification workflows can evolve without breaking the stable record interface used by protocol actions that explicitly require identity proofs.
What does an identity record contain?
Section titled “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?
Section titled “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. See the x/veid module.