Skip to content

x/config — Config module

The x/config module holds chain-level configuration as governed state. Its highest-stakes entry is the approved-client list: the set of client interfaces permitted to submit identity data into VEID. Validators verify that identity submissions originate from an approved client and carry the user’s signature before scoring them.

Other operational parameters live here too, so that “how the chain is configured” is always a queryable, proposal-governed fact rather than an operator convention.

The module stores configuration values as ordinary chain state, readable by anyone and changeable only through governance. The approved-client list is the centerpiece: clients are registered, updated, suspended, reactivated, and revoked as on-chain records, and enforcement reads that list at submission time.

Two queries support the check directly — ValidateClientSignature and ValidateClientVersion — so validators can confirm a submission’s origin and signature before any identity data is scored. Because the list and the parameters sit in state, “what is the chain configured to do” is answered by a query, not by inspecting an operator’s files.

The security of the identity pipeline depends on the integrity of capture software. Governing the approved-client list on-chain puts that trust decision where it belongs — with the network’s stakeholders, under public proposal and vote — instead of with any single party.

ConceptDefinition
Approved clientA governance-vetted client interface permitted to submit identity data.
Governed parameterA configuration value changeable only by on-chain proposal and vote.
  1. Propose — A change is proposed. Adding an approved client or adjusting a parameter opens a public governance proposal.
  2. Vote — Stakeholders decide. The network’s stakeholders vote — the trust decision sits with them, not with any single party.
  3. Store — Config lands in state. The approved list and parameters become queryable chain state that enforcement reads.
  4. Enforce — Validator checks apply. Identity submissions failing the approved-client and signature checks are rejected before scoring.
MessagePurpose
MsgRegisterApprovedClientRegister a new approved client on the governance list.
MsgUpdateApprovedClientUpdate the record of an already registered approved client.
MsgSuspendApprovedClientSuspend an approved client, halting its standing.
MsgReactivateApprovedClientReactivate a previously suspended approved client.
MsgRevokeApprovedClientRevoke an approved client from the list.
MsgUpdateParamsGovernance-only update of module parameters.
QueryPurpose
ApprovedClientA single registered approved client.
ApprovedClientsThe full approved-client list.
ApprovedClientsByStatusApproved clients filtered by lifecycle status.
ValidateClientSignatureCheck that a submission carries a valid client signature.
ValidateClientVersionCheck a submitted client version against validation.
ParamsCurrent module parameters.
ModuleHow they interact
x/veidIdentity submissions are accepted only from approved clients.
x/rolesConfiguration changes require authorized roles and governance.
x/issuancepolicyEconomic policy parameters live alongside operational config.

The set of client interfaces permitted to submit identity data into VEID — a governance-vetted list, because the security of the identity pipeline depends on the integrity of capture software.

It puts the trust decision where it belongs — with the network’s stakeholders, under public proposal and vote — rather than with any single party distributing capture apps. See the x/veid module.

Operational parameters across the chain, so configuration is always a queryable, proposal-governed fact — role-authorized and, where required, MFA-protected. See the Governance guide.